Advanced Remote Method Invocations

Overview of Advanced Remote Method Invocations

  • Author and Presentation Details: Presented by M. L. Liu on April 30, 2026, as part of a course on Distributed Computing.

  • Advanced Features Scope: The Java RMI API provides a wide array of features. This study guide focuses specifically on three advanced mechanisms:     * Stub Downloading: Dynamic retrieval of client-side logic.     * Security Manager: Managing access and protection for distributed systems.     * Client Callback: Enabling the server to initiate communication with the client.

  • Utility: While these features are not strictly mandatory for the distributed object paradigm, they are helpful for developing robust, scalable, and interactive applications.

The Java RMI Architecture Layers

  • Conceptual Architecture: The architecture is split between the Client and the Server, moving through logical and physical data paths.

  • Application/Interface Layer:     * Supports the interface with the application program.     * Utilizes the local Stub (on the client side) and the Skeleton (on the server side).

  • Remote Reference Layer:     * Maps the platform-independent layer to the platform-dependent transport layer.     * Carries out remote reference management.

  • Transport Layer:     * Sets up, maintains, and shuts down connections.     * Carries out the transport protocol.

Standard Java RMI Client-Server Interaction

  • Interaction Steps:     1. Registry Lookup: The client looks up the interface object in the RMI registry located on the server host.     2. Remote Reference Return: The RMI Registry returns a remote reference to the interface object.     3. Stub Downloading (Optional): If the interface object's stub is not present on the client host, and ifconfigured by the server, the stub is downloaded from an HTTP server.     4. Method Access: Via the server stub, the client process interacts with the skeleton of the interface object to access the methods in the server object.

  • File Components:     * Client Host: Client.class, SomeInterface_stub.class (retrieved via HTTP if necessary).     * Server Host: SomeInterface_stub.class, SomeInterface_skel.class, SomeServer.class, and the RMI registry.     * HTTP Host: Stores SomeInterface_stub.class for downloading.

Introduction to RMI Callbacks

  • The Passive Server Model: In the standard client-server model, the server is passive. Inter-process communication (IPC) is initiated by the client. The server merely waits for requests and provides responses.

  • The Need for Active Servers: Some applications require the server to initiate communication upon the occurrence of specific events. Examples include:     * Monitoring systems.     * Multiplayer games.     * Auctioning platforms.     * Voting or polling systems.     * Chat-rooms.     * Message or bulletin boards.     * Groupware applications.

  • Polling vs. Callback:     * Polling: In the absence of a callback mechanism, a client must repeatedly query (poll) a passive server to check if an event has occurred.     * Callback: The server actively notifies the client when an event occurs.

  • Two-way Communications:     * Applications may require duplex communication where both sides can initiate IPC.     * In socket programming, this is achieved using two sockets on each side; both sides act as both a client and a server.

Mechanics of RMI Callbacks

  • Process Overview:     1. Registration: A callback client registers itself with an RMI server.     2. Notification: The server makes a callback to each registered client when a specific event occurs.

  • Step-by-Step Callback Interaction:     1. Lookup: Client looks up the interface object in the RMI registry on the server host.     2. Reference: Registry returns a remote reference to the interface object.     3. Registration for Callback: Via the server stub, the client invokes a remote method to register for callbacks. It passes a remote reference to itself (as a callback object) to the server. The server saves this reference in a callback list.     4. Standard Interaction: The client continues to interact with the server interface object/skeleton as needed.     5. Event Callback: When the anticipated event occurs, the server makes a callback to each registered client via the callback interface stub (now on the server side) and the callback interface skeleton (now on the client side).

Callback File and Role Management

  • Dual Roles for Hosts: Each host acts as both a provider and a consumer of remote objects.

  • Object Client Host Directory:     * Client.class     * ClientInterface.class     * ServerInterface.class     * ClientImpl.class     * ServerImpl_Stub.class (copied or downloaded from server)     * ClientImpl_skel.class

  • Object Server Host Directory:     * Server.class     * ServerInterface.class     * ClientInterface.class     * ServerImpl.class     * ClientImpl_Stub.class (generated from client's callback implementation)     * ServerImpl_skel.class

  • Placement Matrix:     * Client Host: SomeClient.class, CallbackInterface_skel.class, java.policy.     * Server Host: SomeServer.class, SomeInterface_stub.class, SomeInterface.Skeleton.class, CallbackInterface_stub.class.     * HTTP Server: SomeInterface_stub.class, java.policy.

Implementing the Hello Application with Callback

  • Remote Interface for Server (HelloInterface):     * Extends Remote.     * Includes public String sayHello() throws java.rmi.RemoteException;.     * Includes public void addCallback(HelloCallbackInterface CallbackObject) throws java.rmi.RemoteException; to allow clients to register.

  • Remote Interface for Callback Client (HelloCallbackInterface):     * Extends java.rmi.Remote.     * Includes public void callMe(String message) throws java.rmi.RemoteException;.

  • Server Implementation (HelloServer):     * Extends UnicastRemoteObject and implements HelloInterface.     * Maintains a private static Vector callbackObjects to store references to clients.     * The addCallback method uses callbackObjects.addElement(CallbackObject);.     * The callback() method iterates through the vector: HelloCallbackInterface client = (HelloCallbackInterface) callbackObjects.elementAt(i); and invokes client.callMe("Server calling back to client " + i);.

  • Client Implementation (HelloClient):     * In the constructor: sets RMISecurityManager, exports itself as a remote object using UnicastRemoteObject.exportObject(this);.     * Locates registry and performs lookup: h = (HelloInterface) registry.lookup("helloLiu");.     * Registers itself: h.addCallback(this);.     * Implements callMe(String message) to display the server's message.

Stats Server and Client Example

  • StatsServer Class Diagram:     * Attributes: RMIPort.     * Methods: getTotalRunningYardage, getTotalPassingYardage, getTotalTurnovers, setStatistics, addCallback.

  • StatsClient Class Diagram:     * Attributes: RMI Port.     * Methods: statsChanged (defined in the Callback Interface).

RMI Stub Downloading

  • Definition: Allows stubs to be made available to the client dynamically at runtime.

  • Purpose: Allows changes to be made to remote methods (and regenerated stubs) without requiring manuals updates to the client-side software.

  • Mechanism: Stubs are hosted on a web server and downloaded via HTTP.

  • Security Requirements:     * A java.policy file must exist on both client and server hosts.     * A Java Security Manager must be instantiated in both programs.

  • Activation Command: When activating the server, the codebase must be specified to point to the URL of the HTTP server containing the stub classes.

Java Security and The java.policy File

  • Security Risk: Because RMI involves interactions with foreign hosts and object downloading, systems must be protected from malicious access.

  • RMISecurityManager: A built-in Java class to limit access privileges. Developers can also write custom security managers.

  • Installation Code:java try { System.setSecurityManager(new RMISecurityManager()); } catch (Exception e) { ... }     

  • Policy File Content:     * Granting permissions for socket access: permission java.net.SocketPermission "*:1024-65535", "connect,accept,resolve"; (Essential for RMI registry and communication).     * Granting permissions for HTTP access: permission java.net.SocketPermission "*:80", "connect"; (Essential for stub downloading).

  • Execution Command: java -Djava.security.policy=java.policy SomeClient.

Developmental Algorithms

Algorithm for Building a Callback Application (Server Side)

  1. Open a directory for all application files.

  2. Specify the remote-server interface; compile to generate the class file.

  3. Build the remote server class implementing the interface; compile with javac.

  4. Use rmic to generate stub.class and skeleton.class (e.g., rmic SomeServer).

  5. (Optional) Copy the stub file to the HTTP host for stub downloading.

  6. Activate the RMIRegistry.

  7. Set up the java.policy file.

  8. Activate the server, specifying codebase (if downloading stubs), server host name, and security policy.

  9. Obtain and compile the CallbackInterface and use rmic to generate its stub file.

Algorithm for Building a Callback Application (Client Side)

  1. Open a directory for all application files.

  2. Implement the client program/applet; compile the class file.

  3. If stub downloading is NOT used, copy the server interface stub file manually.

  4. Implement the callback interface; compile with javac and use rmic to generate its stub and skeleton classes.

  5. Set up the java.policy file.

  6. Activate the client, specifying the server host name and security policy.

Summary of Advanced Features

  • Client Callbacks: Useful for event notification. Requires the client to supply a remote interface and pass a reference to itself to the server. The server stores these references in a data structure (like a Vector) to call later. This requires two sets of stub-skeleton pairs (one for the server interface, one for the client callback interface).

  • Stub Downloading: Facilitates runtime loading of stub classes. This enables implementation changes and stub regeneration without affecting the client-side host software.

  • Security Management: Security managers oversee access restrictions defined in the java.policy file. This is recommended for all RMI applications, even those not using stub downloading, to ensure protection against malicious access.