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

<key>org.osgi.framework.system.packages.extra</key>
<value>

<!-- system -->
org.apache.xerces.dom,

<!-- jboss-osgi -->
org.jboss.osgi.spi;version=1.0,
org.jboss.osgi.spi.capability;version=1.0,
org.jboss.osgi.spi.logging;version=1.0,
org.jboss.osgi.spi.management;version=1.0,
org.jboss.osgi.spi.service;version=1.0,
org.jboss.osgi.spi.testing;version=1.0,

<!-- jboss -->
org.jboss.logging,
org.jboss.virtual,
org.jboss.virtual.plugins.registry,
org.jboss.virtual.plugins.context.jar,
org.jboss.virtual.plugins.vfs.helpers,
org.jboss.virtual.protocol,
org.jboss.xb.binding;version=2.0,
org.jboss.xb.binding.sunday.unmarshalling;version=2.0,
</value>

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/run.sh -c all
=========================================================================
JBossOSGi Bootstrap Environment
OSGI_HOME: /home/tdiesler/jboss-osgi-1.0.0.Beta2/runtime
JAVA: /usr/java/jdk1.6/bin/java
JAVA_OPTS: -Dprogram.name=run.sh ...
=========================================================================
... [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

4 comments:

  1. Seems to be the exciting future of JBossAS Thomas ;)
    I'm staying tuned ;)

    ReplyDelete
  2. I am running Apache Felix inside Jboss AS 5.
    1. How do I deploy OSGi bundles ? in /deploy/osgi ?
    2. Are the deployed bundles available in the JMX space ? What I'de like to do is load my OSGi bundle, and then use the JbossWS stack to deploy web services from my bundle. Any idea of how you would do that (for example writing an OSGi service that would use packages imported from JbossWS) ?

    ReplyDelete
  3. @TheWinch

    Could you please post this to the user forum?

    ReplyDelete
  4. Hi Thomas,

    I just red your whole blog the last hour. The vision you describe is REALLY exciting for the OSGi community.

    Indeed, the main problem for now when developing modular JEE apps with OSGi is to OSGify,package,setup and expose mostly yourself basic JEE service like JTA, JMS, JMX, Datasources, logging.

    If JBoss comes up with a packaged JEE server providing all those services out of the box available within OSGi runtime, you'll gain huge momentum within the OSGi community and redefine as well the servers ecosystem for the next few years.

    Congratulations for the work so far !

    ReplyDelete