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
>
>