The Enterprise is Getting It’s OSGi

DZone 's Guide to

The Enterprise is Getting It’s OSGi

· Java Zone ·
Free Resource

There have been a few folks who believe that OSGi isn’t something that enterprise developers want. I’ve heartily disagreed with this, and have stated that the enterprise wants it’s OSGi. In The Two Faces of Modularity and OSGi, I stated:

While there is some dispute over whether vendors will expose the virtues of OSGi to the enterprise, eventually they will (SpringSource dm Server currently does). They will because the enterprise stands to gain considerably from a more modular architecture. There is benefit in a world void of classpath hell and monolithic applications. There is benefit in modularity, and eventually the enterprise will ask for OSGi. In the end, the enterprise will get what they’re asking for…

Well, it looks like that day is finally arriving. IBM recently announced the IBM Websphere Application Server V7 OSGi Application Open Alpha Program. From the program’s homepage, I quote the following:

The OSGi Applications Open Alpha brings the modularity, dynamism, and versioning of the OSGi service platform to enterprise application developers. It delivers a simple to use, lightweight programming model for web applications that combines the standard Blueprint component model with familiar Java enterprise technologies. TheOSGi Applications Open Alpha enables enterprise applications to be deployed to the WebSphere Application Server as collections of OSGi bundles, leveraging WebSphere platform enterprise qualities of service to provide the most complete and robust enterprise server for modular web applications. In addition to being easy to use, theWebSphere OSGi applications implementation addresses many of the challenges of developing and maintaining extensible Web applications through OSGi technology benefits of modularity, dynamism, and versioning.

Additionally, a post to the IBM developerWorks forum discusses some of the capabilities, which includes:

  • a built-in bundle repository which can host common and versioned bundles shared between multiple applications so that each application does not deploy its own copy of each common library.
  • a standardized (by the OSGI Alliance) and IBM-supported evolution of the Spring framework called the Blueprint component model. This provides the declarative assembly and simplified unit test of the Spring framework but in a standardized form that is provided as part of the WAS runtime rather than being a 3rd party library deployed as part of the application
  • familiar Java EE programming model with the option of deploying web applications as a set of versioned OSGi bundles with dynamic lifecycle.
  • full integration with WAS Admin and WAS platform enterprise qualities of service

This is great for enterprise developers who are tied to the Websphere Applicatin Server (WAS) platform. But don’t confuse WAS support of OSGi with WAS being a next generation application platform. Other vendors have done a great job providing platforms built atop OSGi, including SpringSource and Paremus.

And don’t confuse support of OSGi as a promise that you’ll immediately realize the benefits of modularity. We’ve made that mistake before with other technologies. There is still a lot to learn about how to design more modular software applications. While WAS support for OSGi brings many of the runtime and management benefits of modularity to the enterprise, it’s still our responsibility to craft systems with a modular architecture.

I’m still unsure of the actual release date for WAS V7, and I don’t have information surrounding all the prickly details of OSGi in WAS 7 and the Open Alpha program. But I intend to find out, and have already reached out to IBM to gather more details. There is still more to learn, so stay tuned. Maybe…just maybe…2010 will be the year that OSGi (and modularity) hits the enterprise.

From http://techdistrict.kirkk.com


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}