Re: Why, at least, serialization?

On Mon, Jun 22, 2009 at 6:33 AM, Alex Co<[email protected]> wrote:

> The question is:
> Can this class or an object of this class (smart proxy) be registered in LUS?

An object of a class is registered in the LUS together with the
service interface, a Unique Identitfier and other attributes (called
Entry).

> As far as i know that class must implements serializable, to be possible to
> register it on LUS, right?

Yes, one of the two possible options (serializable or externalizable).

> As far as i know serialization is to transfer live objects over wire. "Download via
> http is a way to transfer class files over wire".

Well, try to avoid mixing classes and objects in the same sentence.
RMI allows for dynamic classloading, i.e. that the classes needed on
the 'opposite side' of the transfer that is not already present, can
be downloaded from a known location. The location URL of where those
classes are to be downloaded are located;
 1. If the Classloader have loaded the classes at the originating host
via a globally accessible protocol (i.e. http, ftp), then the
destination JVM's classloader will use that URL to find the classes
needed.
 2. If the above fails, then the client will try to download it from
the location specified by java.rmi.server.codebase property.

Note that dynamic classloading is optional. You could possibly have a
situation where no classes are needed to be transported over the wire.

The service proxy will need to be uploaded to the LUS (not necessarily
by the service itself) in a serialized format, and the client need to
be able to retrieve that object instance via the LUS interface.

Now, the Jini Discovery/Join/Lookup specs defines how the client will
join the federation, find one or more LUSes, and how to lookup a
service. Now, considering your questions on RMI-USERS, I suspect that
you are after to bypass the LUS to get to your service, since the RMI
level conversation between the client and the LUS is fairly 'chatty'.
If that is the case, then you are effectively disabling everything
that Jini provides, and perhaps you should be looking at UPnP instead.


> To the best of my knowledge the client needs LUS to abstract localization of
> the server, but why server must instantiate a serializable class in order to add
> it to the LUS?

The typical scenario is that the server will instantiate the service
proxy, together with its own location information, and then upload the
service proxy to the LUS via the LUS' interface. That is technically
not a requirement. Search for "Surrogate Architecture" for more info
what is needed to have a service not capable of RMI or even Java
itself.

> Why LUS do not store class files instead of objects and then
> clientes discover LUS and dowload class files instead of serializable objects?

Because downloading class files via http is so much more effecient,
and hosting those via http left the RMI team to focus on more
important stuff.
Personally, I employed one out of two strategies to deal with
dynamically loaded classes (I'm sure there are others);

1. Either embed a tiny http server in each service, and all classes
are picked up from the originating host. Requires a little bit of
trickery, since it is (or at least was) not possible to specify http:
URLs in the classpath on the command-line. And basically, the
bootstrap code would launch the http server, and then create a new
classloader with the real application's classes pointed out via a
http:// to the current running machine.

 2. Have a central repository of all classes, and have all
java.rmi.server.codebase properties set to it.


> In this case, client needs only the class file not the live object stored in the
> LUS by server, right?
> Once getting the class file, client instantiates it and call the method.
> So, why serialization is obligatory on Jini?

I think because your exception to the 'rule', that you can have
successfully use a class without any instance data, is too rare, and
the chosen path handles that simple case, but the opposite isn't true.


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]