With the recent announcement of GlassFish v3 “Prelude”, Sun's OSGi-based Java EE 6 server, the use of OSGi across the enterprise has grown to encompass almost all of the back-end servers. A recent press release by the OSGi alliance listed the vendors and the technology that uses OSGi:
- IBM's WebSphere
- Oracle's Weblogic
- Paramus' Infiniflow Service Fabric
- ProSyst's ModuleFusion
- Red Hat's JBoss
- SpringSource's SpringSource Application Platform
- Sun Microsystem's GlassFish Enterprise Server
Peter Kriens noted that Jonas, arguably the first OSGi-based JEE server, was not mentioned on the list because it is not an OSGi member. He also noted that SAP NetWeaver is moving towards OSGi in the future as well.
As previously covered by InfoQ, the main reason these systems are moving to OSGi is to enable greater modularity. This allows a system to be decomposed into more manageable (and testable) units, whilst at the same time providing greater re-use of the component libraries. At the moment, the big players (IBM, Oracle) are using OSGi internally and not exposing that directly to users of the application, but others (SpringSource) are building on the fact that the container itself, and not just the applications, are open to extension.
Projects built with Maven are also similarly componentised, leading some to wonder what OSGi adds on top of the modularisation aspect. There's two key differences between Maven's modularisation and OSGi's runtime:
- Maven's dependencies are on specific artifacts; OSGi can import Java packages from arbitrary artifacts discovered at runtime
- Maven's build-time nature means that it does not imply a level of runtime dynamic behaviour
Application servers like SpringSource's DM Server take advantage of OSGi's dynamic nature when deploying Spring beans inside an OSGi container, allowing services to be stopped and restarted at runtime. The Spring Dynamic Module framework handles the wiring and runtime under the covers transparently.
Open-source projects are also moving to OSGi. Spurred on by the Apache Felix OSGi server, other Apache projects are generating OSGi metadata in their builds or moving completely, like Apache Tuscany's recent move. For those open-source projects that don't create metadata at the source, a number of OSGi bundle repositories (SpringSource Enterprise Bundle Repository, OBR, Eclipse Orbit, Felix bundle repository etc.) exist to provide open-source Jars annotated with OSGi metadata.
As a result of the growth of OSGi, both web-based and back-end systems are being built on OSGi directly. Linked In's use of OSGi has been discussed on their engineering blog, and a copy of the presentation at the Colorado Software Summit 2008 is available. It's even possible to run OSGi services on Amazon EC2 and even on an iPhone.
Whether directly or indirectly, the chance of using OSGi in enterprise applications is growing higher. With the Spring framework becoming a de-facto standard for application development and the benefits of the Spring DM server, building dynamic, modular applications is where the industry is headed.