Java-HPC++ Interoperability


Introduction

The growing demand for Distributed Object Models has resulted in the developement of models like Voyager, Infosheres and Java RMI, to name a few. RMI enables the programmer to create distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines, possibly on different hosts. NexusRMI and HPC++ are implementations on top of Globus java and Globus respectively. With a goal of providing interoperability between vairous distributed object models, we have developed a communication model between NexusRMI and HPC++ We show an example wherein an application writen in Java uses a substantial interface of JavaRMI to interoperate with a corresponding HPC++ remote object model.

Achieving Compatibility


Stubs and Skeletons

The NexusRMI compiler uses the java server interface to generate stubs and skeletons. The Client talks to the Server using a proxy called the stub. Each remote object has a stub associated with it. The stub communicates with an active entity called skeleton on the Server side. When the Client makes a remote method call, the request is transferred to the corresponding stub of this remote object. The stub sends the arguments of the call to the skeleton. The skeleton in turn makes the actual call on the server object and sends the result back to the stub. The stub then return the result to the client.

In our example we show a mechanism by which a java client talks to a Server, unaware of the run time system of the Server. (i.e. Is it an HPC++ Server or a Java Server that it is talking to ?). When we use an HPC++Server, the unmarhalling mechanism of HPC++ can be thought of as the skelton, that the stub on the client side communicates with. The object serialization mechanism between HPC++ and NexusRMI need to match, for this to work.

Unique Method IDs

Each remote method is assigned a unique ID on both the Client and Server side. This method ID is used to identify the method on the server for which a request has been made by the client. It is to be noted that the ID is unique over all remote objects in the current JVM. These method IDs need to be unique as HPC++ maintains a global table of registered methods. The server on the java side is a dummy one as it just has the correct method signatures. The server on the HPC++ side has the implementation for these methods. The java client uses the interface provided by the dummy java server to invoke remote methods. However, the invocation requests are transferred to an HPC++ server. So, it is essential that the server interfaces on both sides be identical. Each remote method on the HPC++ side needs to be registered using the templated HPC++ function hpcxx_register() .

 int PUT_BOOL_METHOD_ID = 200;
 int CID1 = hpcxx_registerClass((Component *) NULL);
 int FID0 = hpcxx_register(Component::putBool, PUT_BOOL_METHOD_ID);

The methodIDs that are assigned on the HPC++server side need to match the ones that are generated by the NexusRMI compiler. These methodIDs on the java side can be obtained from the generated stubs.

NexusRMIRegistry

Both the server and client need to to aware of the NexusRMIRegistry. Before we can run the server, this registry needs to be running. The Server binds itself to this registry. The Client is unaware of where and in what environment the Server is running. The Client contacts the NexusRMIregistry to get a remote reference to the Server.

RemoteObjectReference = (ServerInterface)Naming.lookup("rmi://bread.extreme.indiana.edu:7000/ServerName")

registryHost: bread.extreme.indiana.edu
registryPort: 7000
nameToBindAs: ServerName

The Client can now inovke methods on this remote reference.

Bind to a registry

Binding to a NexusRMIRegistry is a two step process:

Object Serialization Protocol

We now show the object serialization protocol.

Compile and Run

Once you download and unzip the example, edit the file config.base to set the paths for the various libraries that will be used. Then do the following at the top level directory: The following three steps need to be done to run the example. On the HPC++Server side, object serialization and deserialization is done using the appropriate pack() and unpack() functions. Object serialization on the client side is done by the NexusRMI compiler.

Browse the Server and Client interface

Download

This is a gzipped tar file.
[ IU CS ] [ Extreme! Computing ] [ HPC++ ]
mgovinda@extreme.indiana.edu

Last modified: Thu Feb 11 18:18:00 EST 1999