Java-HPC++ Interoperability

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.

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.

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() .

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.

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:

make configure

make all

The following three steps need to be done to run the example.

Start a
NexusRMI registry
at a specific machine and port. This can be done by invoking the nexusrmiregistry script or writing a small java program that invokes the method LocateRegistry.createRegistry(). Using the example you can do it in the following manner:

HPC++2NexusRMI/rmitest>> make regRun PORT="REGISTRY_PORT"

Run the HPC++ server. The HPC++ server first tries to attach to the
NexusRMI registry
and in the process receives the HPCxx_ContextID of the registry. Once this is done it tries to a bind the global pointer to the server object, to the registry, using the registry contextID. The global pointer is packed like a NexusRMI
remote reference.
Remote method calls in HPC++ are made using hpcxx_minvoke().
Using the example you can do it in the following manner:

The client does a Naming.Lookup() on the registry and obtains a remote reference to the HPC++server. Note that the client on receiving this reference is not aware that this reference is for an HPC++Server. The client invokes methods using this reference just at if it were a java server. Since the remote method interface of the dummy java server matches that of the HPC++Server, an RMI interoperable interface is presented to the client.
In the example you can run the client as follows: