Enterprise OSGi - "Not List"

I spend a lot of time talking about what enterprise OSGi is, but I always get a lot of questions, particularly about distributed OSGi. I thought it might help to put out a list of what enterprise OSGi is not.

Enterprise OSGi is not:

• Java EE - but EE components are being mapped to OSGi
• A new distributed computing stack - but it defines how to use existing ones
• Spring - but it has a "Spring-inspired" Blueprint service that does something similar
• Something a bunch of vendors dreamed up and decided to standardize - it's a grass roots effort started because people were already using OSGi for enterprise applications and needed help
• Done - the release of the specification is scheduled for June/July (part 1) and December (Part 2)
• Simply a deployment standard - the real power and ultimate benefits of OSGi are in its service programming model
• Untested - the OSGi Framework has been successfully used in enterprise scale deployments

 Many of you who have been following the OSGi specification for a while are familiar with its trajectory - starting with its adoption as the platform for Eclipse, the OSGi Framework is used underneath most enterprise products based on Java, including market leading application servers, development tools, portals, and ESBs.

The question that stirs the most debate is not this aspect of OSGi but whether enterprise Java application developers will embrace it in addition to, or in place of, Java EE APIs. Those of us working on the enterprise OSGi release do understand that it is currently too hard to use, and that it's best to develop OSGi bundles and services using the Spring Framework/Blueprint service or another programming abstraction technology such as iPOJO or Peaberry. But we fully expect the benefits OSGi provides for improved modularity and dynamic deployment and update are benefits enterprise developers need.