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.