Re: [architecture] Geronimo and OSGi

[Mikael Desertot <mikael.desertot@xxxxxxx>]

Guillaume Sauthier a écrit :

> > 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).
>
> So we're ahead of Geronimo for OSGi integration in an app server :)
>
> >
> > 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
>
> In other words, each JOnAS service is now an OSGi Service, with its 
> own ClassLoader linked to other services.

correct

> >
> > 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 
> <http://www-adele.imag.fr/%7Edesertot/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 
> <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.
>
> Each "top level" Fractal component (the ones that are directly inside 
> the bundle) become an OSGi service ?
> is OSGi binding Fractal components interfaces with service trading ?

Fractal is the way services are implemented. Components' server 
interfaces can be registered as services. Then it is a classical service 
oriented architecture.

> > 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?).
>
> I think that in that prototype, the Fractal application is split into 
> one or more bundle, deployed on an OSGi gateway.

It is split for delivering. Then components are instanciated by the same 
Fractal primordial component so in the same classloader. Only deployment 
and class sharing capabilities are used.

> > 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...).
>
> Yep, as Fractal components inside the bindles are not OSGi services, 
> their is no native support for code unloading, ...
> But maybe this is just a matter of linking an OSGi service interface 
> (that will be notified of OSGi events like bind/unbind of services) 
> with a Fractal  controller that can start/stop the component ?

I think didier answered this point.
see FROGi proposition

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