Why, at least, serialization?

[Alex Co]

(Sorry if this msg is duplicated. Not sure about the registration on this forum)

Hi all,
I am learnnig Jini.

I have a question for you that i till now didnt get an answer:
The subject is why serialization for Jini services. Please, read this thought:

Jini does not mandate the use of rmi as the communication protocol between
client and server, right?
So, for those that do not want to use rmi, the service interface must at least
implements serializable, right?

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 deserialization.

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?


When using mobile code i understand that the proxy object must travel too in
order to save data and state by for invoke a Jini method are proxy objects
really needed too?

Many thanks

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 ***@java.sun.com

[Niclas Hedhman]

Not sure if I should at all try to answer this from a phone...

1. The client doesn't need to know where the services are located, and Jini
defines a way via the Discovery and Join protocols (btw, your use of Join
make me think you have not understand the concepts used), even to a point
where you don't need to know where the lookup service is or that the actual
service to run Java.

2. The smart proxy will carry the location information for the client when
registered to the lookup service. The proxy concept is also good as a
mechanism for zthe service author to balance server- and client- side
computations without bothering the client author.

3. Dynamic classloading is an RMI specific and can be used, or not.

4. By using JERI, Jini will also give you additional flexibility and
security options.

Jini's mission is built around the concept of location-independence,
configuration-free and self-healing networked systems.

So, to answer 'serialization'; No it is up to the service and proxy to agree
to any private protocol they like. It can be RMI, or it could be a
home-brewed protocol over UDP, SPX or what not. The service contract is only
between the client and the proxy running in the client.

Cheers
Niclas

On Jun 20, 2009 9:25 PM, "Alex Co" <***@iol.pt> wrote:

(Sorry if this msg is duplicated. Not sure about the registration on this
forum)

Hi all,
I am learnnig Jini.

I have a question for you that i till now didnt get an answer:
The subject is why serialization for Jini services. Please, read this
thought:

Jini does not mandate the use of rmi as the communication protocol between
client and server, right?
So, for those that do not want to use rmi, the service interface must at
least
implements serializable, right?

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 deserialization.

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?


When using mobile code i understand that the proxy object must travel too in
order to save data and state by for invoke a Jini method are proxy objects
really needed too?

Many thanks

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 ***@java.sun.com

--------------------------------------------------------------------------
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 ***@java.sun.com

[Peter Jones]

Post by Niclas Hedhman
Jini's mission is built around the concept of location-independence,
configuration-free and self-healing networked systems.
So, to answer 'serialization'; No it is up to the service and proxy
to agree to any private protocol they like. It can be RMI, or it
could be a home-brewed protocol over UDP, SPX or what not. The
service contract is only between the client and the proxy running in
the client.

Yes, but I think that the question is about the requirements for one
service's proxy to be passed to another (the primary example being a
lookup service), for which there needs to be some agreement for how
the second service can transfer the first's proxy-- and the
expectation there is that the proxy supports RMI marshalling semantics
(and thus serialization) even if second service doesn't actually use
RMI to do such a transfer.

-- Peter

--------------------------------------------------------------------------
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 ***@java.sun.com

[Alex Co]

Thank you Niclas.

Well, I think I understood the jini concept already. May be i did not explain me
good in the question i made.

I know that the smart proxy, stub or local proxy abstract client from all. It just
have to call the method. The language spoken between server and
proxys/stubs is private and jini do not cares about that.

My question is in other direction! The LUS!

Jini is basically clients, servers and LUS(s), right?

Supose I what to develop a service and an smart proxy in Java. The service
has the method void helloworld(void). Nio need a smart procy in this case, but
consider that a smart proxy is then developed that opens a socket to the
server on its constructor and provides a method called InvokeHello that
invokes helloworld on the server.

The smart proxy do not have to be developed using RMI, I know that (and that
is very good!). In this case the smart proxy is just a class file that do not
implements nor extends nothing.in the lus
The question is:
Can this class or an object of this class (smart proxy) be registered in LUS?
As far as i know that class must implements serializable, to be possible to
register it on LUS, right?

As far as i know serialization is to transfer live objects over wire. "Download via
http is a way to transfer class files over wire".

To the best of my knowledge the client needs LUS to abstract localization of
the server, but why server must instantiate a serializable class in order to add
it to the LUS? Why LUS do not store class files instead of objects and then
clientes discover LUS and dowload class files instead of serializable objects?


In this case, client needs only the class file not the live object stored in the
LUS by server, right?

Once getting the class file, client instantiates it and call the method.


So, why serialization is obligatory on Jini?

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 ***@java.sun.com

[Niclas Hedhman]

Post by Alex Co
Can this class or an object of this class (smart proxy) be registered in LUS?

An object of a class is registered in the LUS together with the
service interface, a Unique Identitfier and other attributes (called
Entry).

Post by Alex Co
As far as i know that class must implements serializable, to be possible to
register it on LUS, right?

Yes, one of the two possible options (serializable or externalizable).

Post by Alex Co
As far as i know serialization is to transfer live objects over wire. "Download via
http is a way to transfer class files over wire".

Well, try to avoid mixing classes and objects in the same sentence.
RMI allows for dynamic classloading, i.e. that the classes needed on
the 'opposite side' of the transfer that is not already present, can
be downloaded from a known location. The location URL of where those
classes are to be downloaded are located;
1. If the Classloader have loaded the classes at the originating host
via a globally accessible protocol (i.e. http, ftp), then the
destination JVM's classloader will use that URL to find the classes
needed.
2. If the above fails, then the client will try to download it from
the location specified by java.rmi.server.codebase property.

Note that dynamic classloading is optional. You could possibly have a
situation where no classes are needed to be transported over the wire.

The service proxy will need to be uploaded to the LUS (not necessarily
by the service itself) in a serialized format, and the client need to
be able to retrieve that object instance via the LUS interface.

Now, the Jini Discovery/Join/Lookup specs defines how the client will
join the federation, find one or more LUSes, and how to lookup a
service. Now, considering your questions on RMI-USERS, I suspect that
you are after to bypass the LUS to get to your service, since the RMI
level conversation between the client and the LUS is fairly 'chatty'.
If that is the case, then you are effectively disabling everything
that Jini provides, and perhaps you should be looking at UPnP instead.

Post by Alex Co
To the best of my knowledge the client needs LUS to abstract localization of
the server, but why server must instantiate a serializable class in order to add
it to the LUS?

The typical scenario is that the server will instantiate the service
proxy, together with its own location information, and then upload the
service proxy to the LUS via the LUS' interface. That is technically
not a requirement. Search for "Surrogate Architecture" for more info
what is needed to have a service not capable of RMI or even Java
itself.

Post by Alex Co
Why LUS do not store class files instead of objects and then
clientes discover LUS and dowload class files instead of serializable objects?

Because downloading class files via http is so much more effecient,
and hosting those via http left the RMI team to focus on more
important stuff.
Personally, I employed one out of two strategies to deal with
dynamically loaded classes (I'm sure there are others);

1. Either embed a tiny http server in each service, and all classes
are picked up from the originating host. Requires a little bit of
trickery, since it is (or at least was) not possible to specify http:
URLs in the classpath on the command-line. And basically, the
bootstrap code would launch the http server, and then create a new
classloader with the real application's classes pointed out via a
http:// to the current running machine.

2. Have a central repository of all classes, and have all
java.rmi.server.codebase properties set to it.

Post by Alex Co
In this case, client needs only the class file not the live object stored in the
LUS by server, right?
Once getting the class file, client instantiates it and call the method.
So, why serialization is obligatory on Jini?

I think because your exception to the 'rule', that you can have
successfully use a class without any instance data, is too rare, and
the chosen path handles that simple case, but the opposite isn't true.


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
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 ***@java.sun.com

[Gregg Wonderly]

Post by Niclas Hedhman
Because downloading class files via http is so much more effecient,
and hosting those via http left the RMI team to focus on more
important stuff.
Personally, I employed one out of two strategies to deal with
dynamically loaded classes (I'm sure there are others);
1. Either embed a tiny http server in each service, and all classes
are picked up from the originating host. Requires a little bit of
URLs in the classpath on the command-line. And basically, the
bootstrap code would launch the http server, and then create a new
classloader with the real application's classes pointed out via a
http:// to the current running machine.

The RMIClassLoaderSPI is meant to take care of this issue by allowing you to
specify a classloader that will provide the appropriate annotations.

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 ***@java.sun.com

[Peter Jones]

Post by Alex Co
Jini does not mandate the use of rmi as the communication protocol between
client and server, right?

Right.

Post by Alex Co
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
be serializable.

Post by Alex Co
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
deserialization.
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
implementation.

-- Peter

--------------------------------------------------------------------------
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 ***@java.sun.com

[Alex Co]

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 ***@java.sun.com

[Niclas Hedhman]

Post by Alex Co
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.

Yes, that is one way to express it...

Post by Alex Co
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)...

There is no "default" LUS. All LUSes in the same group are registering
all services in parallel to provide for redundancy, scalability and
robustness to intermittent network problems. Otherwise correct.

Post by Alex Co
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?

As I mentioned just now, I think you will be in for a tough ride. Even
surrogate won't help you, since Jini basically requires a full JVM on
the client, whereas you are much more free to do what you like on the
server. I think that you may have better luck with either UPnP or
perhaps SLP. If you are into OSGi, check out r-OSGi which may (I have
not looked at the details) suit your needs, as I know Jan Rallermeier
is biased heavily towards the embedded space.


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
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 ***@java.sun.com

[Gregg Wonderly]

Post by Niclas Hedhman

Post by Alex Co
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?

As I mentioned just now, I think you will be in for a tough ride. Even
surrogate won't help you, since Jini basically requires a full JVM on
the client, whereas you are much more free to do what you like on the
server. I think that you may have better luck with either UPnP or
perhaps SLP. If you are into OSGi, check out r-OSGi which may (I have
not looked at the details) suit your needs, as I know Jan Rallermeier
is biased heavily towards the embedded space.

The specification of JERI/RMI and Serialization has a lot of freedom allowed if
you stick with the term "semantics" and not with the term "specifics". What has
to happen is that you need to be able to "act" with behaviors that mean the
semantic meaning of what should happen but you need to do that by implementing
the "specifics" of what is known as (de)serialization.

In particular, you can provide end point and invocation layer activities in your
service endpoint that only require http and transfer XML data.

When you talk about service discovery, than you have a different issue. Because
the LUS specification already exists, and because LUS implementations are pretty
much just Reggie, you have to go to some more direct steps to get a "services
client endpoint" in your "jini client".

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.

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.

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

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 ***@java.sun.com

[Alex Co]

Post by Niclas Hedhman

Post by Alex Co
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

Post by Niclas Hedhman

Post by Alex Co
and agnostic in location matters)...

There is no "default" LUS. All LUSes in the same group are registering
all services in parallel to provide for redundancy, scalability and
robustness to intermittent network problems. Otherwise correct.^

When I refer default LUS I mean the default LUS implementation algorithm
(reggie) not a particular LUS running on the federation. Sorry it was my
mistake.
I already studied UpnP, SLP etc but Jini is my target. Why? I dont know?
because the Java world that is fashinating. I have a tiny JVM for that device
(made at my home) with tcp/IP sockets but no serialization (no room for that
:-( ). I am looking for ways to enter in the jini federation with that device (for
consume and for supply jini services, obviously tiny services).

I just have one idea that is operate on LUS default implementation. May be the
LUS could start accept ALSO other form of things which are not serializable
objects .

Please, could you comment this solution?


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 ***@java.sun.com

[Niclas Hedhman]

Post by Alex Co
I just have one idea that is operate on LUS default implementation. May be the
LUS could start accept ALSO other form of things which are not serializable
objects .

Since Jini implementation is now sitting in Apache River project, you
could of course add your own extensions to it, and totally
disregarding what the spec mandates. The upside is that you can
control everything, and the downside is no interoperability and
possibly long term maintenace problems.

So, for instance, as part of the Discovery/Join phase, you could for
instance use UPnP (or a home brewed mechanism) to discover the LUS,
and modify Reggie to support other protocols than RMI. I am not sure
how resource contrained you are, but perhaps xstream or some json
system would be possible to handle the serialization. You could also
check out an old alternative RMI implementation (AltRMI, sitting in
Apache Incubator as a project failing to create a community) for ideas
on how to do the method dispatch system and perhaps use AltRMI as a
base, then swap out the serialization with a json one and manage to
squeeze that into your device.
You could for instance opt to disallow support for some Lookup Service
features, such as Entries and Events, and perhaps try to reach a
'primitives only' solution at service interface levels.


Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

--------------------------------------------------------------------------
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 ***@java.sun.com

[Alex Co]

Another problem is that the reggie is based on RMI and to interact with it the
client must speak rmi too.


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 ***@java.sun.com

[Alex Co]

Thanks a lot...
Your advices and tips were vary valuable for me.

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 ***@java.sun.com

[Alex Co]

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.



So, let me know if i understood

Post by Gregg Wonderly
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?

Post by Gregg Wonderly
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?


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?


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 ?


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 ***@java.sun.com

[Gregg Wonderly]

Post by Alex Co
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.

Post by Alex Co
So, let me know if i understood

Post by Gregg Wonderly
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.

Post by Alex Co

Post by Gregg Wonderly
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.

Post by Alex Co

Post by Gregg Wonderly
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.

Post by Alex Co
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 ***@java.sun.com

[Alex Co]

Thanks Gregg,
Lots of usefull explanation you wrote. I am afraid of not understood all you
recommend to me because my skills on Jini ar far way from yours.


It seems that even Jeri is too much for my toy :-(

I have to use plain sockets between server and (smart) proxy. No serialization
at all... :-(

MAy be the solution is to use slp or upnp to discover service (as someone
already recommended to me in this forum) and then download the class file
from the server and do not support serialization (data) at all. Just class file
download for instantiation on client side. No more solutions i think...

Thanks

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 ***@java.sun.com