users@glassfish.java.net

Re: Java EE & OSGi [Re: GlassFish and Container]

From: S. Ali Tokmen <java_at_alishomepage.com>
Date: Thu, 11 Nov 2010 12:47:13 +0100

Hello Richards and Alexis

I have done some work with OSGi and Java EE, most notably trying to
integrate advanced applications on both sides. I've found out about
three stable Java EE servers that can do OSGi:

    * Glassfish 3.x
    * JBoss 5.x and 6.x
    * OW2 JOnAS 5.x

Currently, Glassfish is the only server to be certified as being Java EE
version 6. Both JBoss 5.x and JOnAS are currently Java EE 5. JBoss 6.x
is expected to be Java EE 6, but has not been certified yet.

What you can expect from Java EE and OSGi integration can be at many levels:

   1. Being able of executing Java EE and OSGi applications in the same
      JVM, to ease for example monitoring and deployment-related tasks
   2. Help you solve versioning and dependency management issues
   3. Making Java EE applications able of reusing OSGi resources/services
          * Typical use case: you have applications developed in OSGi,
            that are stable; and would like to reuse them in your Java
            EE applications without having to repackage everything
   4. Making OSGi applications able of reusing Java EE
      resources/services (be it applications or the server itself)
          * Typical use case: you have complex OSGi applications, that
            need to use all services exposed by the Java EE container.
            For example, you want to integrate the Apache CAMEL
            lightweight ESB into your Java EE server and make it reuse
            all advanced Java EE possibilities such as the managed HTTP
            services, XA, transaction management, ...
   5. If the server itself is also OSGi, being able of having optimized
      profiles; which include no unneeded Java libraries.

If we analyze the servers and use cases:

    * In JBoss, an OSGi runtime is run aside the existing Java EE server
      (JBoss microcontainer). The JBoss microcontainer is therefore not
      OSGi, and actually the OSGi container is not aware of JBoss.
    * Glassfish and JOnAS use an OSGi runtime such as Apache Felix as
      the base container. As a result, all their services are packaged
      as bundles, which helps you in your versioning-related tasks and
      dependency management.
    * JOnAS also uses OSGi for service binding: the whole runtime is
      based on Apache iPOJO, and all JOnAS services are also available
      as OSGi services. Moreover, with iPOJO, you can dynamically start,
      stop and rebind service dependencies of your service.

Now, the mapping between the four levels and the servers:

   1. JBoss, Glassfish and JOnAS support the execution of Java EE and
      OSGi applications on the same JVM. When OSGi applications create
      MBeans, these are registered on the existing MBeanServer, which
      renders monitoring and management trivial.
   2. JBoss, Glassfish and JOnAS handle versioning and dependency
      management for your OSGi applications.
      On the other hand, reuse of existing Java EE packages in OSGi
      applications is only possible in Glassfish and JOnAS.
   3. Glassfish and JOnAS both permit the reuse of OSGi services in Java
      EE applications. The blog post
      http://blogs.sun.com/dochez/entry/glassfish_v3_extensions_part_4
      actually works on both servers.
   4. Tight integration of Java EE and OSGi as well as automated service
      injection is currently only possible in JOnAS. I have for example
      written an article that explains how to integrate the Apache CAMEL
      lightweight ESB to the OW2 JOnAS Java EE server, enhancing the
      lightweight ESB with centralized configuration, management and
      deployment as well as advanced Java EE services such as managed
      HTTP, XA, etc. You can read more on
      http://www.alishomepage.com/Articles/CAMEL_JONAS_5_OSGi/Article.pdf
   5. Java EE server with only the subset of libraries you need: both
      JOnAS and Glassfish have some support. Both servers can also start
      their services dynamically, based on what applications exactly
      need. Still, for the moment, none of these two have a simple
      wizard that would create a Java EE server with only the services
      and libraries you need based on your application.

Cheers

S. Ali Tokmen
http://ali.tokmen.com/

GSM (fr): +33 66 43 00 555 [Orange]
GSM (tr): +90 555 266 52 73 [Avea]

My AIM, ICQ, MSN Messenger and Yahoo IM
contact details are on http://contact.ali.tokmen.com


On 11.11.2010 12:07, Alexis Moussine-Pouchkine wrote:
> Hi Richard,
>
> That's a good question as I don't believe this is covered in the official documentation.
>
> There are really two ways to "uses" OSGi at the application layer IMO :
> 1/ Use OSGi declarative services and inject them in you standard Java EE apps using (@Resource).
> This works well with the current stable version of GlassFish (3.0, 3.0.1) and is detailed in Jerome's earlier blog:
> http://blogs.sun.com/dochez/entry/glassfish_v3_extensions_part_4
>
> 2/ Use the OSGi Enterprise Spec implementation to package your Java EE application and resources into OSGi bundles
> (allowing for versioning, dependencies, etc.). For that part you'd need to use GlassFish 3.1 and Sahoo's blog is probably the best place to start: http://www.java.net/blogs/ss141213
>
> Of course you don't *have* to use OSGi. Most people just get the benefits of the GlassFish modularity without being exposed to the implementation details. But if you do want to use OSGi, please try it out and provide feedback!
>
> cheers,
> -Alexis
>
> On 11 nov. 2010, at 10:51, Richard Kolb wrote:
>
>> Hi Alexis
>>
>> On 10 November 2010 23:43, Alexis Moussine-Pouchkine <alexis.moussine-pouchkine_at_oracle.com> wrote:
>>
>> On 10 nov. 2010, at 20:26, forums_at_java.net wrote:
>>> 3. How does glassfish know which container, services ... it must active
>>> / start?
>> It's smart! :)
>> It depends on the artifacts you deploy. A WAR file will require the web container for instance, for JARs it decides based on deployment descriptors whether it's an EJB, a library or an ACC archive. Sniffers are responsible for this logic.
>> There is also the special case of OSGi bundles that can be deployed using "asadmin deploy --type osgi" to explicitly target the OSGi runtime.
>> In any case, GlassFish is auto-adaptative and there is no need to cut a "profile" upfront with a specific set of features.
>>
>> GlassFish is so cool :)
>>
>> Is there any good document / tutorials on using OSGi for my Java-EE applications in GlassFish ?
>>
>> thanks
>> Richard.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>