Re: A real jini service

Tommy tommy wrote:
> I have readed the service UI API.
> I have some doubts and I would want ask you some councils.

Great!  Please keep asking questions!

> My service proxy will be composed from:
>
> chat user main. It will contain the chat user GUI (inside entries, like
> specified from service UI API)
>
> How do I export the message class? Can I include in serviceitem (service
> proxy) two class? Or can client download the message class from servce
> provider's webserver?

A Jini Service registration is made up of multiple pieces.

1.  A Serializable Java Object that represents the service.  This might
     be a proxy returned from Exporter.export() in many cases, but might
     also be a "Smart Proxy" which is usually just a java.io.Serializable
     implementing class which implements the service by executing some, or
     all code on the client.

     public class Adder implements Serializable, Remote {
        public int add( int v1, int v2 ) throws RemoteException {
            return v1 + v2;
         }
     }

     The above is a class that might be considered a Smart Proxy or just
     a local service.
2.  A serviceID value which is usually provided to a newly registering service
     via the JoinManager's facilities to pass in a ServiceIDListener
     implementation.
3.  Entry objects which annotate, extend or otherwise qualify the service
     with more information about it's use or capabilities.

Item 1 (and sometimes item 2, especially with a ServiceUI UIDescriptor object),
involves the marshalling of 1 or more java objects within the service VM, and
then sending it/them (MarshalledObject is a Serializable object) to all lookup
servers that JoinManager can see.

The important detail is that MarshalledObjects are build with extra information,
called the annotation, which comes from the actions driven by RMIClassLoaderSPI
implementations installed and/or active in your service's JVM.  That annotation
is typically the "codebase" value that you provided in your JVM startup via
-Djava.rmi.server.codebase=http://... or via the codebase parameter to the
construction of a ServiceDescriptor in your use of the
com.sun.jini.start.ServiceStarter facilities.

So, yes, the classes definition should come the client downloading those classes
from your services designated codebase URLs.  Those URLs can point to any
appropriate location where the appropriate jar files have been placed.

The XXX-dl.jar pseudo standard naming convention is the common way that you
would distribute the jar file which contains the classes that a client would
download when using your service.

Gregg Wonderly

> Which is the correct way?
> Sorry for my confusion, but I'm little expert.
>
> Thank you
>
> Regards
>
> --------------------------------------------------------------------------
> 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]
>
>

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