Re: Size of Service Objects in Jini
Gregg Wonderly <[email protected]> Thu, 7 Feb 2008 08:22:28 -0600
| Newsgroups | gmane.comp.java.sun.jini |
|---|---|
| Message-ID | <[email protected]> |
Stefan Hoferer wrote: > Hello everybody, > > I am currently writing my diploma thesis need to include a (very) short > comparison between Jini, UPnP and other service discovery mechanisms. > > Unfortunately I don't have the time to read the full Jini architecture. > > Main focus is on the amount of information that has to be exchanged > between client and lookup service prior a service can be used by the > client. For UPnP this mainly corresponds to the XML service description > documents. > As far as I understand Jini exchanges Service Objects. Is there any > limitation of size? Or can someone provide me with some example values > from his/her own services? Is there other information exchanged or is > everything included in this service objects? The service discovery mechanisms are based around what is defined in the ServiceRegistrar interface. The value registered with the ServiceRegistrar implementation is simply a Java Serializable object. It can be of any size and complexity needed. It might be a simple remote proxy stub that points at a remote service implementation. It might be a Serializable object that is the service in its entirety. It might also be a combination of these two where it is a Serializable object that holds a reference to one or more proxy stubs with some client side code execution that makes remote calls when appropriate. This kind of proxy (a Serialized object that isn't a remote stub) is often called a smart proxy because of the logic it uses locally, at the client, to decide when to use the network. 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]