On Jun 20, 2009, at 9:20 AM, Alex Co wrote:
> Jini does not mandate the use of rmi as the communication protocol
> client and server, 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
> 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
> 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