Re: Why, at least, serialization?

Alex Co wrote:
> Thanks Gregg,
> 
> I think i did not explain well the surrogate issue. Of course my device and my 
> tiny vm can interact with jini federation through surrogate. But i dont want to 
> have my device depending of another device/computer to participate on the 
> jini federation. That could introduce more point of failures and more setup 
> effort. I want that my tiny device could participate on jini federations by its 
> own, not relying in others get get is participate job done. The idea is to 
> transform my device in a Jini device that could offer and consume jini services 
> in a transparent way.

When the surrogate architecture was conceived, the JERI subsystem was in its 
infancy as an idea and as working code I believe.  Since surrogate was 
published, JERI came around and we had a very customizable stack to allow things 
to be non-JRMI based.  Deserialization is a very powerful and important part of 
"joining" a random network, because you can't know the "implementations" on all 
networks and thus you need to be able to download the appropriate implementation 
definitions (class files), and deserialize the instance data for them so that 
you can instantiate something that works.

The URLClassLoader is, more or less, the foundation of this from my perspective. 
  Jini references this class and extends it with the PreferredClassLoader, and 
the RMIClassLoaderSPI is wired into this API to help define how a serialized 
object can be deserialized later, and even elsewhere.

If you can't really provide a URLClassLoader kind of deserialization 
implementation, than you have to step back and look at what you think you need 
to accomplish with some ideas of minimization I believe.

> So, let me know if i understood
> 
>> People have done wide and varying things to get a service object active. I've 
>> heard of http download of a serialized object stream.  You could do this by 
>> writing a MarshalledObject instance to a file, for example.
> 
> Well, in this case we have an extra mean to store already serialized objects on 
> lus may be by serializing them in compile time or something. in this case only 
> clients must include deserializing capabilities. As i wat my device to be server 
> and client, it just have to embed deserializing capabilities, right?

I think yes, but what about outbound calls?

Note that there are two ways that I think about deserialization.  First question 
from my perspective is, can you understand the serialized data stream?  There 
are standards for Java Serialization, so for that, its more of a question of can 
you swallow what you are being fed from a size and complexity perspective 
including complex object graphs with duplicate references for example.

So deserialization is a big part.  Making calls out to a server requires some 
degree of serialization too, as I believe you understand.

>> But, you could also have all the "classes" "known" in your application and just 
>> have the client ready to instantiate an instance, and just have "data" 
>> 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 only 
> classes stores in a http server and client downloads them and instantiate them 
> and call the methods. Obviously client must have some form of identify the 
> classes it needs for the service in wants to use. Those classes (smart proxies 
> can create sockets and speak with the server). In this case all works but 
> location abstraction is sacrificed, right?

If you don't "download class definitions", you don't have to have "class 
loading" built into your JVM.  Instead, you already have the class definition 
available, and you just deserialize instances, using the noargs constructor and 
other serialization mechanisms to get an instance.

The instantiated classes will be "java" code, so they can do what you need them 
to do, based on what you've decided should happen with their communcations, API etc.

>> There are choices for using services, but not a lot of choices if you want to 
>> use a ServiceRegistrar instance for your lookup service.
> 
> Well, this ServiceRegistrar is also a stub that my device as a client must get in 
> order to speak with the lus, right?

Yes, you need to be able to implement the "semantics" of what the reggie proxy 
does.  If you decide that you need an instance of reggie, deployed with a 
particular kind of endpoint and invocation layer, than you can "decide" ahead of 
time how clients will use that reggie instance.

If you want to join the network arbitrarilly, than you have to be prepared to 
accept a lot more variation, which most likely includes the ability to download 
and instantiate a wide range of classes because of how rich the JERI stack is in 
flexibility and capability.

Think about what it might mean to provide a "Configuration" for Reggie that 
specified a custom end-point and invocation-layer implementation that you need, 
along with a small jar containing the needed classes.

Then you could say "deploy an instance of reggie with this configuration for my 
devices to use".  As long as the client endpoint was down loadable and worked, 
than all services would have no problem connecting to that reggie instance and 
registering so that your simple devices could find them.

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

ServiceRegistrar can be part of the problem to solve, but it may also be 
possible to make a configuration change that limits what you need to be able to 
  "load", because you've set the JERI configuration to a fixed set of classes 
that you can provide implementations of.

Gregg Wonderly

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