BasicObjectEndpoint has a Uuid as object identifier for the remote object.
It also has The endpoint to send remote call requests to

In BasicJeriExporter the constuctor creates an id from UuidFactory.
This is assigned to the object being exported. How about other Remote objects
though?

Look at the doc for net.jini.jeri:

    *  Proxy
          o InvocationHandler
                + BasicObjectEndpoint
                      # Endpoint
                      # object identifier (Uuid) 
                + client MethodConstraints
                + server MethodConstraints 

We could add to the Exporter constructor a uuid, which could be a hash
of a URL. Can we then constuct a proxy on the client side for this?

Object Identification Layer
The object identification layer identifies distinct remote objects that are 
exported to a given transport endpoint and implements behavior that is 
specific to individual exported remote objects (but not to the remote 
invocation semantics of those objects), such as distributed garbage collection.

Typically, an ObjectEndpoint contains an object identifier for the remote
 object as well as the Endpoint for communicating requests to the remote 
object, and a RequestDispatcher contains a table mapping object identifiers
 to exported remote objects.

On the client side, an ObjectEndpoint typically prepends the object 
identifier to the remote call request data for reading by the corresponding 
RequestDispatcher. The executeCall method typically reads from the beginning 
of the response an indication from the RequestDispatcher of whether or not 
the identified object was found, and if it was not, returns a
 NoSuchObjectException for the remote invocation to throw.

On the server side, when the transport layer receives a request, it 
dispatches that request to the RequestDispatcher for the communication 
endpoint that the request was received on, passing an InboundRequest for 
performing I/O on the request. The RequestDispatcher typically reads the
 object identifier from the beginning of the request data and looks for a 
remote object with that identifier in its table of exported objects. If
 such an object is found, the associated InvocationDispatcher is invoked
 with the remote object, the InboundRequest, and a server context collection
 populated by the InboundRequest. If no such object is found, an indication
 is written to the response output stream for reading by the corresponding
 ObjectEndpoint.

The invocation dispatcher is invoked inside an invocation of ServerContext.
doWithServerContext with an unmodifiable view of the server context
 collection described above, so that the context is available to the remote
 object implementation.

BasicJeriExporter uses BasicObjectEndpoint instances for the client-side
 object identification layer implementation and instances of an internal
 RequestDispatcher class for the server-side object identification layer
 implementation. This object identification layer implementation supports
 distributed garbage collection, as described below. 


From my book, p120:

exporter = new BasicJeriExporter(
	       TcpServerEndpoint.getInstance(0),
	       new BasicILFactory());

BasicJeriExporter has a method 
		  Uuid getObjectIdentifier()
to get the object id of the object exported. The id is randomly generated,
but we could maybe have a setter/constructor for it.

TcpEndpoint has
	    TcpEndpoint(String host, int port)
to connect to a service.

Proxy has from JavaDoc:
   InvocationHandler handler = new MyInvocationHandler(...);
   Foo f = (Foo) Proxy.newProxyInstance(Foo.class.getClassLoader(),
                                          new Class[] { Foo.class },
                                          handler);

From Jeri, we have
     BasicInvocationHandler(ObjectEndpoint oe, 
                            MethodConstraints serverConstraints) 

The Jeri ObjectEndpoint is
    BasicObjectEndpoint(Endpoint ep, Uuid id, boolean enableDGC) 

Tcp Endpoint is
    static TcpEndpoint 	getInstance(String host, int port, SocketFactory sf)
If the socket factory argument is null, then this endpoint will create 
Socket objects directly.

Okay, jini-rest/echo works fine with absolute addressing!

What are the advantages of Jini:
- downloadable code - only needed for smart proxies
- independence from transport protocol knowledge
- dynamic discovery
- no need for fixed addresses