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
