The Newton project uses OSGi (Eclipse and Knopplerfish), Jini for
remote services and is also using SCA notation to combine services.
It looks to be a very promising project http://newton.codecauldron.org/
I have been doing something similar as I use OSGi (Felix) and Jini
for services, but am now using Jini to provision a bundle that uses
Jini to utilize remote services and still treat them as OSGi
bundles. When Jini gets accepted as an Apache project (it is being
voted on currently and if successful will be in the Apache
incubator), then these pieces will get added in at some point.
Cheers,
Thor HW
On 22-Dec-06, at 3:16 AM, 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.
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
