|
This topic is the subject of considerable debate in the OSGi community right now. At EclipseCon last week David Savage of Paremus sponsored a Birds of Feather (BOF) discussion about tools for OSGi application development and deployment. At the same time Burton Group analyst Kirk Knoernschild published an article saying OSGi is not ready for enterprise application development, in large part due to a lack of tooling (http://java.dzone.com/news/osgi-discontent-no-migration). And finally,
on the Friday after EclipseCon Peter Kriens hosted an OSGi tooling summit on behalf of the OSGi Alliance (good summary here).
So this is a very hot topic right now, and the answer is a partial yes. However most of the current early adopters using an OSGi framework for enterprise application development are saying it is still to hard to develop applications and they are struggling to find a good, comprehensive
approach to the complete development and deployment lifecycle. Multiple abstractions for the low level and complex framework APIs are available from the Spring, iPOJO, and Peaberry projects, and the upcoming OSGi R4.2 (in early draft release) includes a standardization of an annotation based dependency injection API derived from Spring.
Some open source tooling exists for OSGi applications today, such as the BND tool (from Peter Kriens) that helps create OSGi bundles, and the Eclipse Plug-in Development Environment (PDE) that helps create Eclipse plug-ins (which are basically OSGi bundles), but neither is a complete solution. Some OSGi-focused vendors supply tooling, such as Paremus and SpringSource, but these are specifically developed for use with those vendors' runtime environments.
Last week's BOF was well attended by representatives of the OSGi user community, who were vociferous in their demands for tooling solutions totheentire enterprise development lifecycle, including assistance in migrating existing Java programs to an OSGi framework.
Two things in particular stand out as work items for the OSGi Enterprise Expert Group, and I and my co-chair, Tim Diekmann of Tibco, will behighlighting these areas during the next few meetings. The first is to try to standardize the definition of an "application" for OSGi - meaning the unit of deployment comprising multiple bundles (a bundle as a JAR file with OSGi metadata added so it can be deployed into an OSGi framework) and the resources the depend on (files, databases, configuration metadata, and
so on). Directly related to this is the second big work item, standardizing the OSGi Bundle Repository that can be used to store and retrieve the
bundles and their associated resources.
A lot of challenges exist in getting the tooling right, but another interesting development is the Tycho project from Jason van Zyl of
Sonatype, which is integrating OSGi with Maven. This effort would also benefitsignificantly from the standardization of an OSGi bundle repository andapplication definition, which only adds to the urgency to tackle these work items.
Anyway the good news is that people are already using OSGi for enterprise application development (see LinkedIn for a good example), and that OSGi has been already proven to work at the enterprise level since Eclipse uses it as does every major Java vendor for middleware and other enterprise products. We would not be hearing about these issues if they weren't. And the community is responding...
|
