Re: Why, at least, serialization?

Yes, you are right. Interface is needed to "shape" the service and to be =
a=20
mean to identify it on LUS and it is the proxy that must implements seria=
lizable.=20
Ok, now i start to understand why smart proxy class file is not enough on=
 the=20
client side. With just the class file the system would be more static, th=
at is=20
that class file was writeen and then the client would use always the same=
 ip,=20
port etc etc. by introducing also the deserialized proxy object (data) ea=
ch=20
server could "tune" that smart object at the moment of register it with t=
he lus=20
and the whole system would be more "dynamic"  because the smart proxy=20
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=20=

serializable object to maintain the Jini system as it was specified (very=
 dynamic=20
and agnostic in location matters)...

If my client device do not suports even (de)serialization, is there any w=
ay to=20
integrate that device in the jini federation (without using surrogate) in=
 order to=20
give the chance to it to expose and consume Jini services, even sacrifici=
ng (a=20
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 [email protected]