Design of a Multi-Protocol RMI System

A multi-protocol RMI system should have the following properties:

• Provide a common-denominator protocol.
• Architect a common RMI API to different protocols.
• Provide the user with the ability to dynamically switch between protocols.
• Enable dynamic discovery of protocols.
• Implement reliable RMI in a heterogenous environment through a failsafe mechanism.
• Use meta-information (XML Schemas) to define component interfaces.
• Automatic generation of stubs and skeletons from component meta-information.
• Allow high-speed, large data transfers.

SOAP RMI addresses many of these criteria except the last, and as the experiments have shown, for small data sizes SOAP can be faster than Nexus. Having character-based messages, SOAP RMI provides a central, universally accessible protocol that can be readily translated into other protocols. Combined with XML Schemas it is a lingua franca for meta-information.

  

Figure 8: Multi-protocol design

Figure 8 shows the top level design of a proposed multi-protocol RMI system. Our current testbed supports Java RMI, Nexus RMI and Soap RMI. SOAP RMI is the default protocol that all clients and servers are expected to support. However the testbed is designed to accommodate any RMI system. RMI consists of two parts: publication and discovery of remote services (the bind and lookup operations), and data transfer between the client and server via invocation of the remote method. The testbed system requires a registry for each supported protocol. However, clients need to be aware of the existence of just one registry, the SOAP RMI registry, as SOAP RMI is the default protocol. A client can specify the protocols it supports to the protocol-suite. The protocol-suite maintains two lists: the first list has the protocols that the server supports and the second has the protocols that the client supports. When a client invokes a method on a remote reference, the method is actually invoked on the meta-stub. The meta-stub queries the protocol-suite to decide which protocol to use. The protocol-suite does a simple match between the client-list and the server-list to determine the protocol to be used for the current method invocation. The protocol can therefore be switched on a per-remote-method call basis. The client can however override this mechanism and fix the protocol to be used before the method invocation. The implementation provides mechanisms so that any policy can be used by the client for protocol selection.