PadRMI communicates using TCP connections and its own text-based protocol: the PadRMI Protocol (pp://). In order for this to work, the Java VM property java.protocol.handler.pkgs has to be set to the value padrmi. Internally, PadRMI uses asynchronous messages for communication; for this, an instance of the PadRMI server has to run at both the server and client side.
Like in Java RMI, the server's remotely invokable methods must be defined in a special interface: it has to extend the padrmi.PpRemote interface, and all its methods must declare the padrmi.PpException:
import padrmi.*;
import padrmi.exception.*;
public interface MyRemoteService extends PpRemote {
public Object computeSomething(Object input) throws PpException;
}In contrast to Java RMI, PadRMI does not support remote objects, so the implementation of the server only requires the implementation of the remote interface and its registration at the PadRMI server (see example below). The description "MyRemoteService" needs to be a locally unique identifier. Username and password are optional and may be null in order to be disabled.
import padrmi.*;
import padrmi.exception.*;
public class MyRemoteServiceImpl implements MyRemoteService {
public Object computeSomething(Object input) throws PpException; {
// ...
}
// ...
public static void main(String[] args) {
Server.startDefaultServer();
MyRemoteServiceImpl impl = new MyRemoteServiceImpl();
Server.getDefaultServer().addObject("MyRemoteService", impl, MyRemoteServiceImpl.class, "user", "password");
}
}The PadRMI server needs a few properties to be set correctly in order to start: padrmi.guid must be a globally unique identifier (GUID) string. padrmi.bind.address and padrmi.bind.port are the IP address and TCP port to be used, respectively. When using NAT, the router's IP address and its forwarding port can be specified as padrmi.address and padrmi.port, respectively.
In contrast to Java RMI, no stubs and skeletons need to be generated. Instead, PadRMI internally uses java.lang.reflect.Proxy to create local proxy objects at the client side. An invocation of the method defined in the interface above would look like this:
import java.net.*;
import padrmi.*;
import padrmi.exception.*;
public class MyRemoteMethodInvocation {
public static void main(String[] args) {
Server.startDefaultServer();
URL url = new URL("pp://user:password@there:1234/itsguid/MyRemoteService");
MyRemoteService service = (MyRemoteService) Server.getDefaultServer().getProxyFactory().createProxy(url, MyRemoteService.class);
Object result = service.computeSomething(args[0]);
}
}A distinguishing feature of PadRMI is its support for routing; all messages (i.e., serialized remote method invocations or requested resources) are routed using their GUIDs according to the routes defined. The example below shows how to set a route for GUID "myguid" to there:1234:
import padrmi.*;
// ...
Server.getDefaultServer().addRoute("myguid", "there", 1234);The PadRMI server can also be used to host class files and other resources for downloading (e.g., as a remote codebase). The base directory, where the resources are located, needs to be specified via the padrmi.path property; also multiple directories can be supplied, separated by the platform-specific path separator character. The files can be accessed on the client side for dynamic code downloading or as shown below:
import java.net.*;
import padrmi.*;
// ...
Server.startDefaultServer();
URL url = new URL("pp://there:1234/itsguid/subdirectory/file.txt");
url.openStream();Further aspects of PadRMI to consider in your implementations include: only serializable arguments and results are allowed; for these, standard Java serialization is employed. Passing references as arguments or results is not supported. Methods are matched only by their names and number of arguments, but not by their argument and return types. PadRMI is compatible with the standard Java classloader. The remote method calls are in a different protection domain with restricted privileges and can be timeouted using annotations.