Yes, you are right. Interface is needed to "shape" the service and to be a
mean to identify it on LUS and it is the proxy that must implements serializable.
Ok, now i start to understand why smart proxy class file is not enough on the
client side. With just the class file the system would be more static, that is
that class file was writeen and then the client would use always the same ip,
port etc etc. by introducing also the deserialized proxy object (data) each
server could "tune" that smart object at the moment of register it with the lus
and the whole system would be more "dynamic"  because the smart proxy
object is not static and bot bound with a static source.

So, this means that the default LUS server needs to receive at least a
serializable object to maintain the Jini system as it was specified (very dynamic
and agnostic in location matters)...

If my client device do not suports even (de)serialization, is there any way to
integrate that device in the jini federation (without using surrogate) in order to
give the chance to it to expose and consume Jini services, even sacrificing (a
little) the whole jini federation?


Thanks a lot

Alex

--------------------------------------------------------------------------
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 listserv@java...