Virgo 3.0 (Maya) Release Candidate 1
The first Release Candidate of Virgo 3.0 (Maya) is available for download. See the release notes for details.
RC1 finally brings the snaps framework for modular web applications out of prototype status. The separate snaps download includes a completely new Virgo Snaps User Guide and a comprehensive sample application. The User Guide describes how to install snaps on top of Virgo Tomcat Server and uses the sample application to verify the installation and step through all the major features of snaps.
RC1 of Virgo Tomcat Server embeds Gemini Web 2.0 RC1 which now comes with new documentation in the form of a User Guide plus a minimal Programmer Guide.
We encourage users to take RC1 for a spin and provide feedback via bugzilla or the Virgo forum. Unless critical bugs are found, we'll be focussing on the documentation until 3.0 is released, probably towards the end of August.
2 comments:
I am working on architecting an application for my company. I have chosen Spring Framework, Spring Web Services, Eclipse for the GUI and OSGI for modularity. What is the best container to leverage for OSGI for the backend? My initial thought is to just use Tomcat along with SpringDM but it seems I should focus on leveraging Blueprint. My architect team has finally come around to using Tomcat but I have tried to convince them to also look at Virgo. I don't want to go to far down the Tomcat/Spring DM path if Virgo/Blueprint is the better choice. Any thoughts?
Tomcat with Spring DM on the back end implies developing WAR files with OSGi and Spring DM embedded in each WAR. If you run more than one application on a server, you will be running one OSGi container and Spring DM extender per application, which will increase the server footprint and cause you to have to administer multiple OSGi containers. As your application grows, you'll only have basic OSGi diagnostics, e.g. for resolution failures. Also your development environment is likely to be not as simple as it would be just to develop a normal WAR file for Tomcat.
Compare this with Virgo running Spring DM. Here there is optimal footprint and a single OSGi framework to administer. The diagnostics are more advanced and better integrated. Also, the runtime comes pre-integrated with Tomcat embedded in an OSGi container running Spring DM. Virgo also provides a clean architectural and runtime separation between its kernel and the "user region" where applications run, which provides a more stable and robust runtime.
Virgo also makes the back end architecture similar to that of the front end, which should help if you want to share skills between front and back end or develop common infrastructure across the two.
Also, consider what would happen if in the future you decided to change the protocol used to connect the front and back ends. Tomcat only supports HTTP/HTTPS whereas Virgo Tomcat Server supports those protocols but you can keep the same architecture and use the Virgo kernel without Tomcat to enable you to switch e.g. to messaging protocol.
Quite separately, you could choose to use Blueprint instead of Spring DM, either inside Tomcat or in Virgo. The advantage of Blueprint over Spring DM is that it is an OSGi standard and there is a choice of implementations (Gemini Blueprint or Apache Aries Blueprint). A small disadvantage in the Virgo environment is that Blueprint does not come pre-integrated in Virgo and so you have to set up Gemini Blueprint yourself (this will improve in a future Virgo release). Blueprint is not quite as mature as Spring DM and it lacks certain features such as Configuration Admin support and custom namespace handlers, both of which Spring DM has, although you can get these features if you are willing to use non-standard features of Apache Aries Blueprint (although I wouldn't recommend running this implementation of Blueprint in Virgo).
I hope that gives you some more things to consider.
Post a Comment