Geertjan is a DZone Zone Leader and has posted 468 posts at DZone. You can read more from them at their website. View Full User Profile

What's GlassFish Doing With OSGi?

05.02.2008
| 10831 views |
  • submit to reddit
OSGi has certainly seen a lot of engagement in the weeks leading up to JavaOne 2008. Jerome Dochez, the GlassFish architect and a Principal Engineer at Sun, tells us about how it fits in with GlassFish.

Hi Jerome, what've you been up to recently?

I have been very busy in the last 18 months planning and implementing GlassFish V3, which will be the next major release of our application server. My tasks usually involve technical design of the product, implementing its core parts, and sharing the vision of an integrated yet extensible application server.

GlassFish has been undergoing a lot of development. Can you quickly hit the high points for us?

Yes GlassFish v3 is indeed breaking from previous versions by adding support for the following features:

  • Modularity. GlassFish v3 is now based on an OSGi R4 compliant runtime (Apache Felix by default) and it is delivered as a set of OSGi bundles. Modularity is important for the application server, since it allows quick consumption of libraries and reusable components developed by the community. Also, the rapid growth of the technologies made traditional application servers slow to start and react to user's actions, due to an overwhelming set of features started by default. In V3, we only start the services that users use, so this is how we can start the basic runtime under 1 second on most modern laptops, while starting a web application is around 3 seconds for the first initialization, a few milliseconds at redeployment.
  • Extensibility. Although a modular application server should be easily extensible, it takes a dedicated effort to build software that can be extended. In V3, we support adding configuration, administrative commands, admin console elements and of course application containers (like Grails or Rails). The extensibility will allow customers to tailor Glassfish V3 to their exact needs with a set of containers they work with, while removing the fat they don't use.
  • Embeddability. We are dedicating special efforts to make our application server embeddable. For instance, no need to provide a domain.xml (configuration file for GlassFish), because configuration can be specified through a simple set of APIs. We also make no assumption about file layouts, module subsystem, and so on, which makes GlassFish V3 the easiest extensible application server to embed.

And now... OSGi too! What's the background?

Well, we started with our own module subsystem, HK2, which I designed to allow for a certain independence with the underlying module subsystem. So, for instance, we now support running in three modes: OSGi mode (which is the default), HK2 mode, or a non modular mode, where we load all the JARs in a single class loader, which is interesting for embedability, and we can switch between these modes without changing a line of code.

We wanted to have OSGi support, because it's clearly the leading solution for modules, and it is important for GlassFish to be able to consume OSGi services directly. We also offer the OSGi services and APIs to modules and applications running in v3 so that applications do not have to necessarily constrain themselves to the traditional Java EE modules (WAR, EAR, etc..) but can leverage OSGi as a programming model too.

What are the benefits of OSGi for GlassFish?

Too early to say exactly, but clearly we like the features of the module description and package dependencies mechanism. As a tool to implement a modular application, OSGi is quite complete and the benefits of providing such facilities to applications will soon allow new converged applications, consisting of Java EE, OSGi and random libraries, to be widely used.

What about JSR-277?

JSR 277 is becoming more friendly to OSGi as well. My role as an influencer would be to continue pushing the best integration possible between the technologies. I really believe that a good module subsystem should be implemented at the JVM level. I understand that OSGi has to work within the boundaries of the JDK features that had it has access to, but I think there is plenty of opportunity to bring the communities together and provide users with a solid compatible set of features that will preserve their investments.

Can we hear more about all this at JavaOne?

Yes. There will be a short demo during Bob Brewin's keynote on Tuesday afternoon. After that, at 4.40, there is a session on GlassFish V3 where we will demonstrate its extensibility and embeddability. That same day, in the evening, (if I am still alive) there a BOF where we encourage attendees to come and share informal discussions around GlassFish.

My email is jerome.dochez@sun.com, anyone attending JavaOne is welcome to request a meeting with me, I will be there all week and am more than happy to spend time with interested parties.

AttachmentSize
jerome.jpg7.79 KB
Published at DZone with permission of its author, Geertjan Wielenga.