Re: [architecture] Geronimo and OSGi

[Mikael Desertot <mikael.desertot@xxxxxxx>]

Let's begin with a point on what I've done about the integration of OSGi 
into JOnAS:
I aim to use OSGi not only for deploying JOnAS on OSGi but also to take 
advantage of the service oriented architecture.
Concerning the work done by the IBM guy on Geronimo, it is AFAIK only 
deployment of Geronimo (packaging jars in bundles and writing metadata, 
nothing is mentioned concerning service trading or something similar).

From my point of view, technical services that are plugged on the 
containers (J2EE or Web) are delivered in bundles and registered on OSGi
Containers can then perform trading on the registry to retrieve service 
references.
It is then possible to start/stop/update/uninstall/... (and all 
capabilities OSGi brings) services during server runtime.

I've prototyped such an integration using JOnAS and Oscar
which implies flat classloader architecture in the server instead of the 
hierarchical one.
In fact, I'm considering technical services and application in the same 
way for deployment.
For now I've have tested two different versions:
- one by embedding OSGi inside the server (from outside, OSGi technology 
is not visible) but capabilities are still available
- the other by deploying the server on an OSGi gateway, collocated with 
other services. It is then possible to take advantage of legacy OSGi 
services.

So, in my prototype, every service is visible by legacy OSGi bundle and 
the other way round

Concerning this work, I've done a presentation at the OSGi world 
congress available there : 
http://www-adele.imag.fr/~desertot/desertot_1011_1130.pdf
and we published a paper at the Grid Computing Workshop of the 
Middleware Conference describing the interest we have for a dynamic J2EE 
server and that we are using OSGi to implement it.

About OSGi and Fractal:
I agree with Philippe Merle that the two approaches are not 
incompatible. It is interesting to take advantage of the better of the 
two worlds.
There are two different approaches:
The one Philippe mentioned and we have worked on and have presented a 
paper at DECOR'04.
Presentation and paper are available there: 
http://hal.ccsd.cnrs.fr/view_by_stamp.php?label=DECOR04&langue=fr&action_todo=view&id=ccsd-00003291&version=1
(it's in French, sorry, but we are working on an English version to 
publish. I can provide the draft when it will be finished)
It deals with using OSGi for deploying Fractal components and the OSGi 
service oriented architecture to bind them together.
In practice, components or complete fractal application are deployed an 
instantiated inside a bundle. This isolation allows the use of OSGi 
legacy services within Fractal. The difficulty with this approach is to 
benefit of Fractal capability to perform remote bindings between 
components distributed over different platforms. (I've read or heard of 
some solutions concerning distributed service binding with OSGi but some 
of them might be under patent. I've to check...). The problem comes from 
the use of the RMI classloader within OSGi (but there is no problem with 
the use of IIOP for instance). We implemented a prototype of it, but 
only for validating the concept. It needs some additional manpower to 
pass the prototype step.

The second is the one Takoua mentioned.
The way I've understood the prototype (Takoua and Jakub, correct me if 
I'm wrong), it deals with deploying Fractal components with OSGi and use 
classical Fractal binding between components. In this solution, a 
classical Fractal application is built in a single classloader (but what 
about the classloading problems with RMI and OSGi?). But in that case 
OSGi is only used as a deployment platform and the service oriented 
architecture of OSGi is lost and its capabilities too (code unloading, 
updates,etc...). In this solution, services are not visible as OSGi 
services, so no interaction is possible between Fractal components an 
OSGi legacy bundles and services.

The work that I'm currently doing:
I'm working on the integration of the Felix implementation of OSGi in 
JOnAS as it is an implementation of the specification release 4.
It brings very interesting new features :
- loading different versions of the same class at the same time
- improved package constraints for code sharing
- security (bundle signature and services security, allowing dynamic 
security policies definition)
- ...
but it also brings many modifications on the implementation.

I hope I clarify some points.
Mikael


--

Mikael Desertot                            Tel: +33 476 63 55 49
LSR, 220 rue de la chimie,                 Fax: +33 476 63 55 50
Domaine Universitaire, BP 53               http://www-adele.imag.fr
38041 Grenoble Cedex 9 France

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature