Microcontainer based kernel. For JBoss OSGi only the 5.x series is relevenant so lets start with that.
Integration in JBossAS-5.x
Like any other service JBoss OSGi is integrated via a *-beans.xml descriptor.
More specifically, when you choose JBossAS integration in the Installer you will find and 'osgi.deployer' directory together with all your other MC deployers.
Deployers must be loaded first because as their name nicely suggests they deploy other services and applications. There is a lot to say about deployers, but lets focus on the JBoss OSGi specific osgi-deployers-jboss-beans.xml beans descriptor. Here you'll find all OSGi relevevant configuration options. For this post I'll take the Apache Felix integration as an example. There is however a similar beans descriptor for Equinox and Knopflerfish.
Without going in too much detail there are various beans configurations
- OSGi Framework Integration
- Bundle Management (JMX) Service
- MC Integration Service
- OSGi Deployers
The JBoss OSGi AS integration looks something like this
You will notice that all the interesting AS provided services are 'outside' the OSGi world. You can think of them as 'system services' like the ones provided by the JVM itself. Hence a bundle wanting to access EJB, JTA, JPA, etc. can only do so if the packages that it imports are defined on the OSGi System Classpath. This would be the content of the 'org.osgi.framework.system.packages' property, which for Felix is currently defined like this
Say good bye to modularity, if packages from services need to be defined statically as part of some non-recyclable deployer.
<!-- system -->
<!-- jboss-osgi -->
<!-- jboss -->
So how can the AS integration still be useful?
- It is useful for folks who have plain OSGi applications that either do not interact with system services or can have static dependency on those services. i.e. you can send/receive JMS messages, but there cannot be more than one JMS service available nor can the JMS service come and go.
- It is a neccessary starting point from which OSGi/AS integration can develop. What I describe here is the state of the current AS integration, over the course of time you should see posts explaining an ever improving OSGi/AS integration.
- JBoss-5.2.0 (not yet released)
- JBoss-6.0.0 (not yet released)
There is another JBoss OSGi Runtime available, which is already covered to some extend in the Userguide. Lets have a closer look.
Standalone JBoss OSGi Runtime
The JBoss OSGi Runtime is a pure OSGi container onto which components, services and applications can be deployed.
Instead of bootstrapping the OSGi Framework from the Microcontainer, the Microcontainer Service is installed in the OSGi Framework as a bundle.
Preconfigured profiles, contain OSGi bundles that logically work together. A profile can be bootstrapped either as a standalone server or embedded in some other environment. With a startup time of less than 600ms, the runtime can be easily be bootstrapped from within plain JUnit4 test cases.'-c all' profile
[tdiesler@tdvaio runtime]$ bin/run.sh -c all
JBossOSGi Bootstrap Environment
JAVA_OPTS: -Dprogram.name=run.sh ...
... [FelixIntegration] OSGi Integration Felix - 1.0.0.Beta2
... [FelixIntegration] Installed bundle : org.osgi.compendium
... [FelixIntegration] Installed bundle : org.apache.felix.log
... [FelixIntegration] Installed bundle : jboss-osgi-common
... [FelixIntegration] Installed bundle : jboss-osgi-hotdeploy
... [OSGiBootstrap] JBossOSGi Runtime booted in 0.421sec
... [jboss-osgi-common] Installed: jboss-osgi-xml-binding 
... [jboss-osgi-common] Installed: jboss-osgi-microcontainer 
... [jboss-osgi-common] Installed: org.apache.felix.metatype 
... [jboss-osgi-common] Installed: jboss-osgi-jndi 
... [jboss-osgi-common] Installed: org.apache.felix.http.jetty 
... [jboss-osgi-common] Installed: org.apache.felix.configadmin 
... [jboss-osgi-common] Installed: jboss-osgi-jmx 
... [jboss-osgi-common] Installed: jboss-osgi-jaxb 
... [jboss-osgi-common] Installed: jboss-osgi-common-core 
... [jboss-osgi-common] Installed: jboss-osgi-webconsole 
... [jboss-osgi-common] Installed: jboss-osgi-apache-xerces 
... [jboss-osgi-jndi] JNDI started: JNP=localhost:1099
... [jboss-osgi-jmx] Bound to: jmx/invoker/RMIAdaptor
... [OSGiBootstrap] JBossOSGi Runtime started in 5.156sec
The OSGi Framework boots up and starts the services that are shown in the picture above. Although the startup time is considerably faster that that of the AS it should be mentioned that this is currently not optimized. OSGi comes with a lazy bundle activation policy. What you see above is 'eager' bundle activation for all. Lazy bundle activation means that bundles and their associated service can be started on demand, which should bring the startup time much closer to the boot time.
So why is this OSGi runtime useful?
- It is useful for folks who want a "clean" OSGi environment with all the benefits that are described in the feature set
- 3rd party bundles can be installed in that runtime and provide truly modular services similar to the ones that exist in the AS integration.
- It is the foundation of our OSGi activities that take an already existing OSGi Framework for granted (i.e. the upcomming Blueprint implementation)
So what cannot be done with this runtime?
- You cannot take advantage of many of the JavaEE and advanced JBoss features. EJB3, JTA, AOP, etc are not available (yet).
- JMX and AOP annotations on MC beans do not work
- You cannot deploy existing JBoss applications on that runtime
The possible future of JBoss OSGi
Conceptually, the Microcontainer already implements the OSGi provided functionality. Some folks even go as far as saying that the MC is a superset of OSGi. The criteria to prove the truth of that claim is well defined, MC "simply" needs to pass the OSGi core TCK.
The idea is to provide the MC with a facade that implements the OSGi core API. Our chief scientist has signed up for it, and I am exited to see what will come out of it. The resulting architecture would then look similar to this
The Microcontainer is the OSGi Framework and manages the classloading scope and lifecycle of all components deployed on it. This is the vision, the time line and details still need to be defined.
That's it for now. Next week I'll be off for a short holiday to my favourite climbing spot
In my next post I'm going to look into the OSGiRuntime abstraction and the Husky Test Harness in more detail. If you like, you can already look forward to Beta3, which should see major improvements to our Blueprint implementation - stay tuned.
May this be useful