Eric Newcomer's Weblog

Peter Kriens blogged about the results of the OSGi Enterprise Workshop on Monday, and more information is available, including this list of prioritized requirements and draft charter.

I was pretty impressed that we covered so much ground in one day. The working style of the OSGi Alliance was very informal, low pressure, but keep-things-moving and get-it-done. (Does that sound too much like Larry the Cable Guy?) We went from stating requirements to brainstorming to prioritizing to drafting a charter...for a standards organization that is pretty good progress.

Of course a key question here is how would an "OSGi Enterprise Edition" relate to other enterprise software initiatives out there, such as Web services, SCA, CORBA, or J2EE? How well would OSGi be adopted in the enterprise, especially given its origins in a Java runtime environment for mobile devices?

One answer can be found within the recent OSGi-Spring mapping. This project allows Spring components to be delivered as OSGi bundles and creates proxies between Spring beans and OSGi services.

Another answer appears to be OSGi's willingness to reuse and adopt whatever makes sense, without regard to any industry marketing/hype campaign.

Other interesting aspects...

As of 6.1 IBM ships WebSphere as a collection of OSGi bundles. (And by the way a Google Search of Maven OSGi turns up evidence that OSGi support is already underway.)

The OSGi framework provides the foundation for the Eclipse runtime.

Open source and commercial projects and products are starting to emerge that deliver OSGi compliant servers for enterprise applications.

Workshop attendees described in detail a large-scale enterprise integration project in the airline industry, based on OSGi, that is already underway, with another one potentially to follow soon. In fact this project was the source for many of the requirements mentioned during the morning.

OSGi was chosen for this project instead of existing enterprise software technologies. J2EE, for example, was described as too heavyweight and complex. What they needed was basically a network of lightweight service containers talking directly to each other, without any broker, hub, or server in between.

Is this a good idea? Absolutely. Artix works exactly this way. Its distributed microkernel container with configurable plugins already handles large numbers of users, large numbers of applications, and large numbers of transactions in large numbers of customer applications in production today. Absolutely this approach works - actually it is the best way to do SOA.

But what about SCA? IBM was present in force at the OSGi workshop (where aren't they ? ;-) and they are also the main drivers behind SCA. The response was that the design center of SCA is clearly for distributed and large scale systems, whereas the design center for OSGi is for services running in a single JVM on mobile or embedded systems. Also OSGi is Java only while SCA is multi-language.

But guess what two of the main requirements are for enterprise OSGi? Distributed computing support (i.e. multi JVM/multi-process) and multi-language compatibility, of course.

But maybe also there's a good way to put all this together?

And maybe the OSGi Alliance is a good place to do it?

All in all, a very interesting set of questions.

As the board members present at the workshop said, OSGi simply noticed a groundswell of interest in applying OSGi to enterprise software problems, and thought they should probably look into starting an expert group to focus the conversation.