Re: Why, at least, serialization?

Thanks Gregg,

I think i did not explain well the surrogate issue. Of course my device a=
nd my=20
tiny vm can interact with jini federation through surrogate. But i dont w=
ant to=20
have my device depending of another device/computer to participate on the=
=20
jini federation. That could introduce more point of failures and more set=
up=20
effort. I want that my tiny device could participate on jini federations =
by its=20
own, not relying in others get get is participate job done. The idea is t=
o=20
transform my device in a Jini device that could offer and consume jini se=
rvices=20
in a transparent way.



So, let me know if i understood

>People have done wide and varying things to get a service object active.=
 I've=20
>heard of http download of a serialized object stream.  You could do this=
 by=20
>writing a MarshalledObject instance to a file, for example.

Well, in this case we have an extra mean to store already serialized obje=
cts on=20
lus may be by serializing them in compile time or something. in this case=
 only=20
clients must include deserializing capabilities. As i wat my device to be=
 server=20
and client, it just have to embed deserializing capabilities, right?


>But, you could also have all the "classes" "known" in your application a=
nd just=20
>have the client ready to instantiate an instance, and just have "data"=20=

>transported back and forth with XML, or JSON or something else.

In this case there is no objects running over the wire, right? there is o=
nly=20
classes stores in a http server and client downloads them and instantiate=
 them=20
and call the methods. Obviously client must have some form of identify th=
e=20
classes it needs for the service in wants to use. Those classes (smart pr=
oxies=20
can create sockets and speak with the server). In this case all works but=
=20
location abstraction is sacrificed, right?


There are choices for using services, but not a lot of choices if you wan=
t to=20
use a ServiceRegistrar instance for your lookup service.

Well, this ServiceRegistrar is also a stub that my device as a client mus=
t get in=20
order to speak with the lus, right?


What about modify the LUS to support what it supports now but also to=20
support servicing class downloading also and provide a new way to interac=
t=20
with it in order to avoid ServiceRegistrar ?


Thank you

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]