Niclas Hedhman wrote:
On Friday 22 December 2006 16:32, Peter Kriens wrote:
I am also very curious what the state of the art is concerning
distribution in OSGi.
Where is Corba, RMI, UPnP, Jini, Voyager with respect to OSGi. I would
really appreciate some experiences here.
Corba - Not my cup of tea.
Voyager - I don't think this mobile agent technology survived. I remember I
did a a funky Agent007 chasing various villains on the computers in the
office, but that is 8-9 years ago. Last time I checked, I couldn't find any
relevant references to it still being around.
UPnP - There are others who knows this well.
UPnP is similar to Jini regarding to the discovery capabilities and
robustness of the network (i.e. leasing mechanism for event
notification) on the contrary being based on an stack of standard
protocols (HTTP, SAOP) your cannot move object code between UPnP nodes,
at least not in a standard way.
There are several framework written in C++, PHP, Java that can be used
to develop Control Points and Devices which are the two kind of entities
composing an UPnP network. So this could be a vantage if you are
thinking to CORBA to connect heterogeneous systems.
Basically look at UPnP as simple Web Services with enhanced or different
discovery capabilities.
The OSGi-UPnP specification define a bridge between the OSGi world and
the UPnP Networks. The networked UPnP devices are discovered and
registered as services (is not possible to discover Control Points) and
vice-versa services registered in the platform can be announced on the
network and be used by external Control Points.
I think UPnP can be a convenient option if you ave to integrate external
(simple) services in the OSGi Platform, everything is exposed as service
and it is easy to build added value services on top of them.
If you have a complex communication pattern Jini could be a better
solution. Other things that you have to take into account is the
security, in UPnP is not integrated in the original specification, the
network is considered trusted, anyway there is a separate standard
profile to implement. At last UPnP works fine only in the LAN domain.
regards
francesco
RMI/JINI - RMI and Jini are possibly the true problem childs. And it relates
to what is know as "dynamic classloading" and a.k.a in Jini as "mobile code".
When RMI marshals a serialized object, it will annotate the serialized stream
with the "codebase" of the classes that are inside the stream. If the
classloader is a URLClassloader and it contains 'global' URLs, such as
http:// and ftp://, then those are used, otherwise the stream will be
annotated with the value of the system property "java.rmi.server.codebase".
On the unmarshalling side, a new classloader will be created with the
classloader of the calling class as the parent. In standard Java2
classloading hierarchy fashion, such classloader delegates to its parent for
each of the classes, and if not resolved that way, the classloader will load
the classes from the URLs supplied in the MarshalledObject, i.e. a remote
location where the classes/jars can be downloaded from.
This means that if I write a bundle that uses RMI services on the network,
then there is essentially not much problems. I think the problems arises when
you try to create generic bundles that exposes for instance Jini services as
OSGi services. Such bundle will not be able to Export the classes, since they
are not known until runtime.
Another problem is about exposing OSGi services as for instance Jini services,
or for that matter RMI objects. Since OSGi doesn't use (I think) a
classloader that is a subclass of URLClassloader, it is not possible to get
RMI to annotate the MarshalledObject with a correct codebase, and setting the
java.rmi.server.codebase is very anti-OSGi. That means that the whole concept
of "dynamic classloading" / "mobile code" can't easily be used in a OSGi
environment. And for Jini, this is a very central concept that you don't tell
them "don't use it", especially since Jini now uses RMI2.0 (JSR76/JSR78)
which has strong security features for these scenarios.
IMHO, there are some changes needed in the java.rmi packages to better support
non-Java2 classloading scenarios such as OSGi. Perhaps OSGi also need to
converge a little bit and start using subclass of URLClassloader. Details on
what needs to be done, needs some more ironing....
Hope that clarifies it a bit.
Cheers
Niclas
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
