Re: Why, at least, serialization?

On Jun 20, 2009, at 9:20 AM, Alex Co wrote:
> Jini does not mandate the use of rmi as the communication protocol  
> between
> client and server, right?

Right.

> So, for those that do not want to use rmi, the service interface  
> must at least
> implements serializable, right?

Not the service interface in particular (in general interfaces should  
not extend java.io.Serializable), but the service proxy's class should  
be serializable.

> Then, on client side, if client needs to use a jini service it  
> downloads service
> classes definitions by http (for example) and the jini service  
> object comes by
> wire by using serialization on server side and deserialization on  
> client side. Then
> the proxy is constructed on the client side by "joining" the  
> downloaded classes
> definitions and the proxy object that arrives to client by  
> deserialization.
>
> My question is: why it is necessary downloaded class definitions and
> deserialized proxy object to invoke jini service?
>
> Why not just get the class definitions, instantiate them and call  
> its methods?
> What is the role of the proxy object there?

In general, objects are code + data.  In particular, service proxy  
objects typically have instance data identifying the network location  
(like host and port, and object ID in the RMI case, etc.) of the  
service's back end-- you wouldn't want to need a separate service  
proxy class and definition for each possible deployment of the service  
implementation.

-- Peter

--------------------------------------------------------------------------
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]