Let’s face it. We all knew Sun would get acquired. The question was just when and by whom. Now that its happened, and Oracle is the winner, I must say I like the situation better than if IBM had bought them. Just from a EE specification perspective, IBM was always a bit reactionary when it came to anything new. On EE 5, Oracle was a staunch ally in our push to get JPA through and a part of EE 5 (and thus retiring CMP and making JDO obsolete). On EE 6, we’ve met a bit of resistence from them when it comes to the-spec-formally-known-as-Web-Beans, but they’ve been at least open to the idea. Who knows how the Oracle business guys will want to deal with Java. That is the wildcard IMO. Should be fun… Interesting times.
OSGi doesn’t need to be in your face
April 2, 2009
java, jboss, spring 8 Comments
Awhile back on TSS, I complained about OSGi possibly bleeding too much into applications. That OSGi did not belong within application code. This IBM article is a prime example of my point. Here we have standard Spring code and XML. Nowhere in there do you have OSGi APIs. Yet, you get OSGi classloading and lifecycle. I bet, that if you can’t already right now, Spring will eventually be able to register IoC references as direct dependencies within an OSGi kernel. There’s really no reason or advantage to have OSGi APIs bleed into application code.
Another example is JBoss 5. While not running on top of an OSGi kernel (instead its running on JBoss’s own special kernel) it can manage dependency and lifecycle for a variety of different component models like: Spring, JBoss MC, EJBs, JCA adapters, Queues, Topics, Servlets, etc. This can work because JBoss’s kernel provides a deployment abstraction and framework to publish and manage inter-component dependencies. The end goal here is that all these different component models can take advantage of all this dependency management without writing to specific APIs and to stay within the confines of their own component model’s specification. The metadata is there. The dependency information is there. There’s no reason to write to a specific deployment API to leverage these types of services.
This is what I had hoped OSGi would become. A standard kernel where classloading, deployment, and dependency management would be provided as low level services so that existing and new component models would have a standard way to mix and match themselves and to deploy themselves. In theory, such a kernel would allow JBoss’s Transaction Manager to run within a Web Logic server. JBoss’s EJB container to run within Websphere. Sun’s WS-* implementation to run within JBoss.
Maybe my concern is not real. Maybe most OSGi evangelists are not positioning OSGi as an application API. Let’s hope they aren’t.
Bill the Plumber 