I once heard an OSGi guy from BEA (now Oracle) say that everyone thinks about OSGi for its deployment capabilities, but the real power is in its service model.
I have mentioned this controversy before, i.e. whether or not the OSGi programming model is likely to become widely adopted in the enterprise. To a large extent this may well depend on how well the EEG does its job. This is one topic I’m hoping to explore during next week’s meeting, i.e., which scenarios the release is good for, and which it isn’t.
I have also mentioned before that one of the current work items for the OSGi enterprise expert group is adapting various Java EE components to the OSGi Framework. The first priority is to ensure that the components work as they did before, i.e. as if the OSGi Framework were irrelevant. This is the deployment capability, where the OSGi Framework (and by this I mean one of the various implementations of the current specification) is used only to host the application. Such an application could equally be deployed on Tomcat, or a Java EE compliant application server. For this scenario, the EEG work is pretty straightforward. We just have to make sure nothing is broken.
To enable the service model, however the work to map the Java EE components is quite different. For example, perhaps you want to create an OSGi service that uses a Web app as a service, or a JTA-managed transaction as a service. Let’s say you want to use JNDI to discover an OSGi service, etc. This will take some effort, and we are running short on time. A critical evaluation point for the enterprise release therefore is whether or not the Java EE components we’re mapping are sufficient and/or appropriate.
A recent EEG vote approved four of the design documents in progress (early drafts) to move to the specification (and final) stage: the Blueprint model (based on Spring dm), Distributed OSGi (which I’ve written about before), JTA, and JMX. Is this enough? Well, perhaps it is for some applications – and probably not for others. What else is needed? JNDI? JPA? JDBC? Web apps?
One great thing about the OSGi standardization process is that it starts by gathering requirements – in fact the initial requirements gathering exercise is what led to the OSGi Board’s decision to charter the EEG in the first place. And for any work item pulled from the initial requirements list, the first job was to refine and document the requirements in sufficient detail to create move to the design stage.
Implementations based on the current version of the OSGi specifications seems to gaining momentum: in addition to the several hundred IBM products (I have heard from different IBM sources that the number is between 200 and 300) currently deployed on OSGi, and the plans of all application server vendors to support OSGi based deployments, open source ESBs such as ServiceMix4, OpenESB (BTW this pointer was harder to find than I expected, I am wondering whether pre Project Jigsaw they had more top level info on OSGi?), Carbon, and Mule also support OSGi, or plan to (actually among these it seems Mule is alone in not yet supporting OSGi). And perhaps more interestingly, the Spring dm Server and ServiceMix4 support developers interested in using the OSGi programming model.
Mainly, I think that the enterprise release of OSGi should be about creating enterprise Java applications as a collection of OSGi services. But is the industry really ready to move past the deployment only stage?
Early indications point in the right direction, but I suppose we will have to wait for next year to really find out for sure.
Eric Newcomer's Blog 