DC - Chapter - 8 : Advanced RMI

8.1 Client Callback

Some applications require the server to initiate communication upon certain events.  Examples applications are:

·        Auctioning: user submits bid, server inform if higher bid by others.

·        Chat-room: user type message, server forwards messages from other users.

·        Message/bulletin board.

One of the important benefits of RMI is that it supports callbacks, which enable the server to invoke the methods on the client. With the RMI callback feature, you can develop interactive distributed applications.

Polling is indeed a technique employed in many network programs. But it is very costly method in terms of system resources, as each remote method invocation takes up a separate thread on the server host, along with the system resources that its execution entails.

Callback : It allows each object client interested in the occurrence of an event to register itself with the object server so that the server may initiate a remote method invocation to the object clients when the awaited event occurs.

                        

                Figure 8.1 : Compares the two techniques: Polling and Callback

In RMI, Client Callback is a feature that allows an object client to register itself with a remote object server for callbacks so that the server may issue a remote method invocation to the client when an awaited event occurs.

When an object server makes a callback, the roles of the two processes are reversed: The object server becomes a client of the object client so that the object server may initiate a remote method invocation to the object client.

                          

                       Figure 8.2. The architecture of RMI with Client Callback

Figure 8.2 illustrates the architecture for RMI with client callback. Compared with the architecture for basic RMI, two sets of proxies are now requited. One set is required for the server remote interface, as in the basic RMI architecture. The other set of proxies is for an additional interface, the client remote interface. The client remote interface provides a remote method that can be invoked by the server for the callback.

8.1.1 Client-Side Augmentation for Client Callback

For the callback, the client must provide a remote method that allows the server to notify it of the awaited event. It can do so in a manner similar to the remote methods provided by the object server.

The Client Remote Interface

The object server provides a remote interface that declares the remote methods that an object client may invoke. For the callback, a similar remote interface will need to be provided by the object client. We will call this interface the client remote interface, as opposes to the server remote interface. The client remote interface should contain at least one method to be invoked by the server for the callbacks. The client remote interface for example is as follows:

Public interface CallbackClientInterface

                    extends java.rmi.Remote{

                    //This remote method is invoked by a callback

                    //server to make a callbacl to a client which

                    //implements this interface.

                    // The parameter is a string containing information for the

                    // client to process upon being called back.

                    // This method returns a message to the server.

Public string notifyMe(String message)

                     throws java.rmi.RemoteException;

} // End Interface

Here the method notifyMe  is to be invoked by the server when it makes the callbacks, passing as argument a string. Upon receiving the callback, the client makes use of the string it receives to compose a string that it returns to the server.

The Client Remote Interface Implementation

As with the server remote interface, the client remote interface needs to be implemented in a class, called CallbackClientImpl in example, as follows:-

import java.rmi.*;

import java.rmi.server.*;

public class CallbackClientImpl extends UnicaseRemoteObject

      Implements CallbackClientInterface   {

      Public CallbackClientImpl( ) throws RemoteException {

                    Super( );

}

public string notifyMe(String message) {

string returnMessage = “Call back received : “+ message;

System.out.println(returnmessage);

return returnMessage;

    }

}  // End CallbackClientImpl class

In this example the callback method notifyMe simply displays the string returned from the server and returns a string to the server.

As with the server remote interface, the compiler rmic  should be applied to the implementation of the client remote interface to generate the proxies needed at run time.

Augmentation to the Client Class

In the object client class, code needs to be added for the client to instantiate an object of the remote client interface implementation. A reference to the object is then registered with the server using a remote method provided by the server.  A sample of the code that needs to be added to the client class is as follows:

CallbackServerInterface h=

                    (CallbackServerInterface)Naming.lookup(registryURL);

CallbackClientInterface calbackObj =

                    New CallbackClientImpl ( );

// register for callback

h.registerForCallback(callbackObj);

8.1.2 Server-Side Augmentation for Client Callback

On the server side, a remote method needs to be provided to allow a client to register for callback. In the simplest case, the method signature may be analogous to this sample:

Public void registerForCallback

                    // You may choose a method name of your choice.

                    CallbackClientInterface callbackClientObject

}  throws java.rmi.RemoteException;

A reference to an object that implements the client remote interface is accepted as an argument. A companion method unregisterForCallback may also be provided to allow a client to cancel the registration. The implementation of these methods, along with a local method doCallbacks- for performing callbacks.

It is necessary for the server to employ a data structure to mainintain a list of the client interface references registered for callbacks. In the sample code, a Vector object is used for this purpose, but you may substitute any appropriate data structure of your choice. Each call to unregisterForCallback results in the removal of a reference from the vector.

In sample, a client unregisters itself after a specified period of time. In actual applications, the cancellation of registration may occur at the end of a client session(such as a chat room session, a game session, or an auction session)

8.1.3 Steps for Building an RMI Application with Client Callback

8.1.1(a) Algorithm for Developing the Server-Side Software

1. Open a directory for all the files to be generated for this application.

2. Specify the remote server interface in CallbackServerInterface.java. Compile it until there is no more syntax error.

3. Implement the interface in CallbackServerImpl.java. Compile it until there is no more syntax error.

4.Use the RMI compiler rmic to process the implementation class and generate the stub file and Skelton file for the remote object:

                    rmic CallbackServerImpl

The files generated can be found in the directory as CallbackServerImpl_Skel.class and CallbackServerImpl_Stub.class. Steps 3 and 4 should be repeated each time a change is made to the interface implementation.

5. Obtain a copy of the client remote interface class file. Alternatively, obtain a copy of the source file for the remote interface and compile it using javac to generate the interface class file CallbackClientInterface.class.

6. Create the object server program SomeServer.java. Compile it until there is no more syntax error.

7. Obtain a copy of the client remote interface stub file CallbackClientImpl_Stub.class.

8. Activate the object server.

8.1.1.(b) Algorithm for Developing the Client-Side Software

1. Open a directory for all the files to be generated for this application.

2. Specify the remote client interface in CallbackClientInterface.java. Compile it until there is no more syntax error.

3. Implement the interface in CallbackClientImpl.java. Compile it until there is no more syntax error.

4. Use the RMI compiler rmic to process the implementation class CallbackClientImpl.class and generate the stub file CallbackClientImpl_Stub.class and Skelton file CallbackClientImpl_Skel.class for the remote object-

rmic CallbackClientImpl

The files generated can be found in the directory as CallbackImpl_Skel.class and CallbackImpl_Stub.class Steps 3 and 4 should be repeated each time a change is made to the interface implementation.

5. Obtain a copy of the server remote interface class file. Alternatively, obtain a copy of the source file for the remote interface and compile it using javac to generate the interface class file.

6. Create the object client program CallbackClient.java. Compile it until there is no more syntax error.

7. Obtain a copy of the server remote interface stub file CallbackServerImpl_Stub.class. Activate the client.

java SomeClient

 

8.2 Stub Downloading

RMI is designed to allow stubs to be made available to the client dynamically.  Doing so allows changes to be made in the remote methods without affecting the client program.

The stub can be filed with an web server and be downloaded using HTTP.

Stub downloading makes use of “ the ability to dynamically download Java software from any Uniform Resource Locator(URL) to Java Virtual Machine(JVM) running in a separate process, usually on a different physical system”. Using stub downloading, a stub class is filed by the object developer with a web server as a web document, which can then be downloaded (using HTTP) when an object client is executed.

A Client that wishes to invoke a remote method of an exported object contacts the RMI registry on the server host to retrieve the remote reference by name. without stub downloading, the stub object(a java class file) must be placed on the client host manually and must be locatable by the Java Virtual Machine. If stub downloading is in use, then the stub class is obtained dynamically from an HTTP server so that it can interact with the object client and the RMI run-time support. The downloaded stub class is not persistent, meaning that it will not be stored permanently on the client host, but will instead be deallocated by the system when the client session is over. In the absence of Web Caching(it is a technique that employs caching to avoid repeated downloading of the same document), each execution of the client class will require that the stub  be re-downloaded from the web server.

                                  

Figure 8.4: Stub Downloading

8.3 RMI Security Manager

To encounter the treats posed by a downloaded stub, Java provides a RMISecurityManager class. An RMI program may instantiate an object of this class. Once instantiated, the object oversees all security-sensitive actions that arise during the execution of the program. These actions include the accessing of local files and the making of network connections, since such actions may result in undesirable modification of local resources or misuse of network resources. In particular, the RMI run-time support requires that a server process install a security manager before it can export any object that requires stub downloading, and that a client process install a security manager before it can download a stub.

By Default, an RMI security manager is very restrictive: it allows no file access and allows connections to the originating host only. So it will prevent an object client from contacting RMI registry of the object server and also from downloading a stub.

It is possible to relax these restrictions by installing a special file known as a security policy file,  whose syntax specifies what type of restrictions a security manager, including RMI security managers, should enforce.

By default, there is a systemwide security policy file installed in a special directory of each Java-enabled system.

The restrictions specified in the system security policy file will be those enforced by the security manager unless override it by specifying an alternatively policy file.

You can write your own security manager, if so desired.

     try {

         System.setSecurityManager(new   

            RMISecurityManager( ));

             }

         catch { …}

8.3.1 Algorithms for Building an RMI application, Allowing for Stub Downloading

8.3.1.(a) : Algorithm for Developing the Server-Side Software

1. Open a directory for all the files to be generated for this application.
2. Specify the remote-server interface SomeInterface.java, and compile it to generate the interface class file.
3. Build the remote server class SomeImpl.java by implementing the interface, and compile it using javac.
4. Use rmic to process the server class to generate a stub.class file and a skelton.class file:  rmic SomeServer
5. If stub downloading is desired, copy the stub file to an appropriate directory on the HTTP host.
6. Activate the RMIRegistry, if it has not already been activated.
7. Set up a java.policy file.
8. Activate the server, specifying (i) the codebase if stub downloading is desired, (ii) the server host name, and (iii) the security policy file.

8.3.1. (b): Object Client-Side Algorithm for Developing the Client-Side Software

1. Open a directory for all the files to be generated for this application.
2. Obtain a copy of the remote interface class file SomeInterface.class, Alternatively, obtain a copy of the source file SomeInterface.java for the remote interface, and compile it using javac to generate the interface class file.
3. If stub downloading is not in effect, obtain a copy of the stub class file and place it in the current directory.
4. Set up a java.policy file for application, and place it in an appropriate directory or the current direct directory.
5. Activate the client, specifying (i) the server host name, and (ii) the security policy file.