Nugget: Service without RMI

	Service without RMI

	This example demonstrates how to construct a Jini service and Jini client so that RMI (Remote Method Invocation) is not used when invoking the service.

Run Instructions

	To run this example Jini must first be started. Even though this service will not use RMI to receive its service requests, the RMI daemon, r2.bat, still needs to be launched because the lookup service, reggie, is dependent upon it. Start Jini from the JiniExample1 directory using the r1.bat, r2.bat, and r3.bat files. Then move the webserver files from this example to the webserver directory: Since each compile job deletes all the class files from the Jini lib directory, always recompile the example using the c.bat file (which performs the copy for you) before using the example. Then start the server: Open a new command line and change to the server run directory: `\java \nuggets \pages \examples \JiniExample4 \server-side` (remove the spaces from the path). Run the server program by executing the `r.bat` script file. Then start the client: Wait until the server is up (about 15 seconds) then open a new command line and change to the client run directory: `\java \nuggets \pages \examples \JiniExample4 \client-side` (remove the spaces from the path). Run the client program by executing the `r.bat` script file.

To run this example Jini must first be started. Even though this service will not use RMI to receive its service requests, the RMI daemon, r2.bat, still needs to be launched because the lookup service, reggie, is dependent upon it.

Start Jini from the JiniExample1 directory using the r1.bat, r2.bat, and r3.bat files.

Then move the webserver files from this example to the webserver directory:

Since each compile job deletes all the class files from the Jini lib directory, always recompile the example using the c.bat file (which performs the copy for you) before using the example.

Then start the server:

Open a new command line and change to the server run directory: \java \nuggets \pages \examples \JiniExample4 \server-side (remove the spaces from the path).
Run the server program by executing the r.bat script file.

Then start the client:

Wait until the server is up (about 15 seconds) then open a new command line and change to the client run directory: \java \nuggets \pages \examples \JiniExample4 \client-side (remove the spaces from the path).
Run the client program by executing the r.bat script file.

Client

	To simplify this example, the client assumes that the lookup service is running on the localhost and makes a unicast search for it.

Figure 1: MyClient

	The client extracts the proxy object from the lookup service. When it wants to invoke service from `MyServer` it calls the proxy object directly since both objects are in the same VM. The proxy object actually makes the call to the server. The only element of RMI that is contained in this example occurs in the first part of this client. When the `MyServerProxy` object arrives at the client's VM, it arrives as a serialized object. This object needs the `MyServerProxy` class to perform the deserialization. Since the client would not normally have that class in its directory, the class needs to be fetched from another location. For that reason, I coded the client to set the RMISecurityManager. This allows the class loader to follow the codebase in the serialized object and make a http request for the `MyServerProxy` class. If it is a problem to use the RMISecurityManager in the client, presumably you could write a custom class loader that performed a similar function.

The client extracts the proxy object from the lookup service. When it wants to invoke service from MyServer it calls the proxy object directly since both objects are in the same VM.

The proxy object actually makes the call to the server.

The only element of RMI that is contained in this example occurs in the first part of this client. When the MyServerProxy object arrives at the client's VM, it arrives as a serialized object. This object needs the MyServerProxy class to perform the deserialization. Since the client would not normally have that class in its directory, the class needs to be fetched from another location.

For that reason, I coded the client to set the RMISecurityManager. This allows the class loader to follow the codebase in the serialized object and make a http request for the MyServerProxy class. If it is a problem to use the RMISecurityManager in the client, presumably you could write a custom class loader that performed a similar function.

Server Proxy

	The server proxy object lives in the lookup server and is sent to the client upon request. The client calls the proxy's methods and the proxy makes any needed calls to the server.

The server proxy object lives in the lookup server and is sent to the client upon request. The client calls the proxy's methods and the proxy makes any needed calls to the server.

Figure 2: MyServerProxy

	The server instantiates the proxy and hands it to the lookup service. During the instantiation, the server's IP and port are passed to the proxy and held in instance variables. Then the client pulls the proxy from the lookup service and calls one of its methods. The proxy method, opens a socket and communicates to the server through normal socket communications. The socket protocol used in this example is the simplest possible socket interaction. For every connection the server receives, it sends back a string. Normal socket communications call for the client to send a length and request then the server responds with a length and a reply.

The server instantiates the proxy and hands it to the lookup service. During the instantiation, the server's IP and port are passed to the proxy and held in instance variables.

Then the client pulls the proxy from the lookup service and calls one of its methods. The proxy method, opens a socket and communicates to the server through normal socket communications.

The socket protocol used in this example is the simplest possible socket interaction. For every connection the server receives, it sends back a string. Normal socket communications call for the client to send a length and request then the server responds with a length and a reply.

Server Proxy Interface

	This interface identifies what methods the client can call in the proxy.

Figure 3: MyServerProxyInterface

Server

	This Jini service receives its requests through socket connections rather than through remote method invocations.

This Jini service receives its requests through socket connections rather than through remote method invocations.

Figure 4: MyServer

	When this server is instantiated, it launches a new thread that opens a server socket on port 7777. This socket expects to receive requests from the server's proxy object over this socket. After instantiation, the server's proxy object is handed to the lookup service and the client pulls it from the lookup service. Whenever the client wants to invoke service from the server, it makes a call to the proxy object which opens a socket to the server. In this example, every new socket connection receives a simple string reply. In a normal socket protocol, the proxy would speak first and send a request (preceded by a length in the case of a string request). Then the server would respond with an appropriate reply.

When this server is instantiated, it launches a new thread that opens a server socket on port 7777. This socket expects to receive requests from the server's proxy object over this socket.

After instantiation, the server's proxy object is handed to the lookup service and the client pulls it from the lookup service. Whenever the client wants to invoke service from the server, it makes a call to the proxy object which opens a socket to the server.

In this example, every new socket connection receives a simple string reply. In a normal socket protocol, the proxy would speak first and send a request (preceded by a length in the case of a string request). Then the server would respond with an appropriate reply.

	by Noel Enete . . . www.enete.com . . . noel@enete.com