Friday, June 5, 2009

JBoss OSGi Runtime & JBossAS Integration

Now that JBoss OSGi 1.0.0.Beta2 is out I thought I'll explain a little more in detail what the various JBoss OSGi runtime models are about. In this post I'll cover
JBossAS has always been good at integrating loosely coupled services. In the 3.x and 4.x series that was done via a JMX based kernel in the 5.x series the AS switched to a 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
Every time you deploy a bundle (i.e. drop it into the 'deploy' folder), the bundle gets processed by the OSGi Deployers, each of them taking care of a specific deployment aspect.

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


<!-- system -->

<!-- jboss-osgi -->

<!-- jboss -->

Say good bye to modularity, if packages from services need to be defined statically as part of some non-recyclable deployer.

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.
The AS intgration is available for
  • JBoss-5.0.1.GA
  • JBoss-5.1.0.GA
  • JBoss-5.2.0 (not yet released)
  • JBoss-6.0.0 (not yet released)
both for jdk1.5 and jdk1.6. Here is the full matrix.

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.

For a more detailed description and the feature set, please have a look at the userguide.

For this post lets focus on the '-c all' profile

[tdiesler@tdvaio runtime]$ bin/ -c all
JBossOSGi Bootstrap Environment
OSGI_HOME: /home/tdiesler/jboss-osgi-1.0.0.Beta2/runtime
JAVA: /usr/java/jdk1.6/bin/java
... [FelixIntegration] OSGi Integration Felix - 1.0.0.Beta2
... [FelixIntegration] Installed bundle [1]: org.osgi.compendium
... [FelixIntegration] Installed bundle [2]: org.apache.felix.log
... [FelixIntegration] Installed bundle [3]: jboss-osgi-common
... [FelixIntegration] Installed bundle [4]: jboss-osgi-hotdeploy
... [OSGiBootstrap] JBossOSGi Runtime booted in 0.421sec
... [jboss-osgi-common] Installed: jboss-osgi-xml-binding [5]
... [jboss-osgi-common] Installed: jboss-osgi-microcontainer [6]
... [jboss-osgi-common] Installed: org.apache.felix.metatype [7]
... [jboss-osgi-common] Installed: jboss-osgi-jndi [8]
... [jboss-osgi-common] Installed: org.apache.felix.http.jetty [9]
... [jboss-osgi-common] Installed: org.apache.felix.configadmin [10]
... [jboss-osgi-common] Installed: jboss-osgi-jmx [11]
... [jboss-osgi-common] Installed: jboss-osgi-jaxb [12]
... [jboss-osgi-common] Installed: jboss-osgi-common-core [13]
... [jboss-osgi-common] Installed: jboss-osgi-webconsole [14]
... [jboss-osgi-common] Installed: jboss-osgi-apache-xerces [15]
... [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
From the contrast of the two aproaches you see that it would be beneficial to have the benefits of both available in one runtime environment.

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

Wednesday, June 3, 2009

JBossOSGi 1.0.0.Beta2 Released

I am happy to announce the release of JBossOSGi-1.0.0.Beta2.

You can download it here: jboss-osgi-installer-1.0.0.Beta2.jar

The release comes with improvements in the following areas
For details please have a look at the latest version of our User Guide.

Here are the change log details

Feature Request

  • [JBOSGI-70] - Expose bundle headers through JMX