|
»
»
Why, at least, serialization?
|
View:
New views
17 Messages
—
Rating Filter:
Alert me
|
 |
Why, at least, serialization?
by Alex Co
::
Rate this Message:
(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 listserv@... |
|
|
|
|
|
|
|
|
Re: Why, at least, serialization?
by Peter Jones-21
::
Rate this Message:
On Jun 20, 2009, at 9:20 AM, Alex Co wrote:
> Jini does not mandate the use of rmi as the communication protocol > between > client and server, right? Right. > 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. > 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 listserv@... |
|
|
Re: Why, at least, serialization?
by Peter Jones-21
::
Rate this Message:
On Jun 21, 2009, at 10:22 AM, Niclas Hedhman wrote:
> 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 listserv@... |
|
|
|
|
|
Re: Why, at least, serialization?
by Niclas Hedhman
::
Rate this Message:
On Mon, Jun 22, 2009 at 6:33 AM, Alex Co<alexe100@...> wrote:
> The question is: > 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). > 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). > 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. > 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. > 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. > 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 listserv@... |
|
|
Re: Why, at least, serialization?
by Niclas Hedhman
::
Rate this Message:
On Mon, Jun 22, 2009 at 4:32 PM, Alex Co<alexe100@...> wrote:
> 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... > 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. > 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 listserv@... |
|
|
|
|
|
|
|
|
Re: Why, at least, serialization?
by Niclas Hedhman
::
Rate this Message:
On Mon, Jun 22, 2009 at 5:24 PM, Alex Co<alexe100@...> wrote:
> 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 listserv@... |
|
|
|
|
|
Re: Why, at least, serialization?
by Gregg Wonderly-2
::
Rate this Message:
Niclas Hedhman wrote:
> 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. 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 listserv@... |
|
|
Re: Why, at least, serialization?
by Gregg Wonderly-2
::
Rate this Message:
Niclas Hedhman wrote:
> On Mon, Jun 22, 2009 at 4:32 PM, Alex Co<alexe100@...> wrote: >> 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 listserv@... |
|
|
|
|
|
Re: Why, at least, serialization?
by Gregg Wonderly-2
::
Rate this Message:
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 listserv@... |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
