As I'll be discussing on Tuesday, Virgo evolved out of a relatively mature project whose aim was to make it easy for enterprise applications and enterprise application developers to adopt OSGi. The goal was to make the transition to OSGi incremental. Essentially you can start with a standard WAR file and deploy it to Virgo as-is. Then you can incrementally refactor the WAR file into an application comprising multiple OSGi bundles while continuing to use familiar technologies such as Spring, Hibernate, JPA, etc. We based Virgo on Tomcat suitably embedded into OSGi, again to provide familiarity for enterprise developers as well as systems administrators.
In parallel with the evolution of Virgo, the OSGi Alliance Enterprise Expert Group, being discussed on Tuesday, produced a series of enterprise specifications again with the goal of enabling enterprise applications to be migrate straightforwardly to OSGi. The reference implementations of these specifications became today's Eclipse Gemini project:
- Gemini Blueprint - an OSGi standard dependency injection container which also supports the popular Spring and Spring DM namespaces
- Gemini Web - support for servlets in the form of OSGi standard Web Application Bundles (WABs) or standard WAR files
- Gemini JPA - support for JPA persistence in OSGi
- Gemini DBAccess - modularised JDBC drivers for use in OSGi
- Gemini Management - JMX management for OSGi
- Gemini Naming - support for JNDI naming in OSGi
Until recently, integrating the Gemini projects into Virgo has been a fairly specialised skill. As we'll see in a workshop on Thursday, things are now really starting to come together and Gemini Blueprint, Gemini Web, and various other Gemini components can now be deployed and used in Virgo. We'll also be touching on how to manage and configure WABs in Virgo as part of a workshop later this morning.
So much for the past. What about the future? The primary goal of Virgo 3.0 is better integration with other EclipseRT technologies such as Equinox, Jetty, and p2. This will provide richer function and greater choice for enterprise applications as they migrate to OSGi. We'll be hearing about how Virgo and EclipseRT technologies work together on Wednesday. The recently released third milestone of this release shows the progress towards the goal of better integration with EclipseRT:
- Virgo now uses Equinox Configuration Admin and Event Admin services instead of their Apache equivalents.
- Virgo has moved to the new framework hooks model for isolation in Equinox which is part of the OSGi 4.3 standard soon to be issued for public review.
- Virgo now provides two web servers: Virgo Tomcat Server, which continues to be based on Gemini Web, and Virgo Jetty Server. Some exciting technology for modularising the view portion of web applications is also emerging into the Virgo mainstream as we'll hear on Wednesday.
- p2 support in Virgo is also making good progress although this is currently in prototype form.
Development tooling is also entering an exciting new phase which will greatly help applications migrate to enterprise OSGi:
- The Libra project, which will be presented on Wednesday, is providing development tooling for building WABs and will ship in the Eclipse Indigo release train later this year.
- The Virgo development tooling has entered the Eclipse IP process and will soon emerge in the Virgo project. Over time, the standards-based features of the Virgo tooling will be factored out and migrated into Libra.
- OSGi runtime launchers are also being contributed to Libra. I would hope to see a Virgo launcher for Libra emerge so that Libra can start to take over from the Virgo tooling for many aspects of enterprise OSGi application development.
If you're attending EclipesCon, come and hear the talks, join in the workshops and BoFs and help to shape incremental OSGi in the Virgo, Gemini, and Libra projects.
Hi Glyn-
ReplyDeleteThanks for this update on the changing landscape of enterprise OSGi development.
One concern I have is this: with the efforts being made to make it easier (or really just make it possible) for "traditional" enterprise Java development to transition to an OSGi deployment model, I worry that we're adding big layers of complexity to the already significant list of things that a developer may need to understand to use OSGi. I'm not sure that is a winning strategy for OSGi, at least not without additional efforts to make sure to improve the simpler OSGi stack story, and promote a non-JEE development strategy as well.
Years ago I turned to an OSGi development strategy specifically as a way of escaping the crazy, clunky, crufty, and downright odd stuff going on with JEE development. I really don't want to have anything at all to do with JNDI, WAR files, and all the rest of those specs. I really don't think most of those actually help the enterprises that adopt them, and I feel like OSGi, on the other hand, really does have a concrete value in designing software.
At my company, we adopted Spring DM (not DM Server), which has been, in balance, a big win for us, due to improved ability to manage service-dependency code, as well as giving us more flexible dependency injection (we use the javaconfig stuff). For a while Spring DM has seemed to be in limbo, and it hasn't been very clear when it would be safe to transition to Gemini Blueprint.
But I guess my point is that even adding Spring DM/blueprint to "raw" OSGi is a significant increase in what a developer has to learn about to make use of an OSGi stack. So I find myself wishing that more effort would be put into getting the lower-level OSGi house in order, before adding on all the other stuff to try to court the enterprise developers who may not be that interested in showing up anyhow.
-Dave
Hi Dave
ReplyDeleteDoubtless some people prefer a revolutionary approach.
The evolutionary, incremental approach maximises reuse of existing skills and code, which I think appeals to more conservative developers, system administrators, etc.
You point out an interesting trade-off in introducing Spring DM or Blueprint. With those technologies, you need to write a lot less low-level code and you get the usual dependency injection benefits such as looser coupling and easier unit testing. But yes, there is a cost in understanding the XML syntax. However I've not heard anyone really argue that the costs outweigh the benefits, if that's what you are saying.
I'm most interested in your wish to get the lower-level OSGi house in order. What do you think the critical problems are?
Regards,
Glyn