Java-HPC++ Interoperability

• Introduction
  
• Achieving Compatibility
  
• Object Serialization Protocol
  
• Compile and run HPC++2NexusRMI example
  
• Browse through the interface
  
• DownLoad HPC++2NexusRMI example
  

• Stubs and Skeletons
  
• Unique Method IDs
  
• NexusRMIRegistry
  
• Bind to a registry
  

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);

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

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

• the Server needs to attach to the NexusRMIRegistry.
  

  template <'class T'>
  void RMIRegistry<'T'> :: attachToRegistry(char *registryHost, unsigned short port) { 
    
    int rc = hpcxx_grabContext(®istryStartpoint, host, port); 
    if (rc != 0){
      cout <<"\n Error ...RMIRegistry->attachToRegistry() failed returnValue =  " << rc << endl; 
      cout <<"\n Is a NexusRMIregistry running at " << registryHost <<"::" << port <<" ? " <<  endl; 
      cout <<"\n  ... Exiting ... " << endl ; 
      exit(EXIT_FAILURE);
    } 
  } 
    
  

• the Server then needs to bind or rebind to this registry.

  
  template <'class T'>
  int RMIRegistry<'T'> :: rebindRegistry(HPCxx_GlobalPtr<'T'> gp, HPCxx_String rmiURL, HPCxx_String FQN) {
  
    Component component;
    int result;
    HPCxx_GlobalPtr remoteGP(&component, ®istryStartpoint);
    HPCxx_GlobalRefImpl &r = *gp;
    HPCxx_ContextID remoteObjStartpoint;
    globus_nexus_startpoint_copy(&remoteObjStartpoint , r.contextID_);
    BindObject bindObject(rmiURL, FQN, localStartpoint, remoteObjStartpoint);
    hpcxx_minvoke(&remoteGP, result, rebindFID, bindObject);
    cout <<"RMIRegistry-->::rebindRegistry(): hpcxx_minvoke() ... returned " << endl << endl;
    return SUCCESS;
  }
  

• Basic Data Types
• Arrays
• Vectors
• Strings
• Objects
• RemoteReferences (GlobalPointers)
• CallBacks

• make configure
• make all

• 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:

  HPC++2NexusRMI/rmitest>> TestNewRMI Server REGISTRY_HOST REGISTRY_PORT
  Executable Name: TestNewRMI
  ServerName in registry: Server
  

• 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:

  HPC++2NexusRMI/rmitest>> make clientRun ARGS="REGISTRY_HOST REGISTRY_PORT"
  Executable Name: TestNewRMI
  ServerName in registry: Server
  

• NexusRMI Java Client Interface
• HPC++ HPC++ Server Interface