Java RMI support

To better understand this section, examine the sample SstPingPongRmi.

The Java Remote Method Invocation (RMI) messaging model is similar to that of SST in that requests to remote objects are marshaled into bytes and sent across a transport for processing. The sender waits for the result which is returned via a similar mechanism. RMI differs significantly however in the implementation of this model. Below is a summary of the issues most relevant to Java and Smalltalk interoperation:

Marshaling

RMI uses Java Object Serialization to convert objects to bytes and vice versa. As noted elsewhere in this document, SST uses Swapper or an SST-specific marshaler. These formats are completely incompatible.

Communications

RMI communications is largely TCP-based. While this presents no particular problem, the use of the TCP connections is specific to RMI. For example, RMI maintains a pool of connections between any two machines. If there are no available (existing or free) connections, a new connection is created. Connections used for a request are marked as in-use for the duration of that send (until the reply and related DGC messages have been exchanged). Standard SST on the other hand uses a more loosely coupled model which requires just one connection between any two hosts.

Object model

Both Smalltalk and Java are class-based object-oriented languages. Java however contains notions such as interfaces and types. While Smalltalk objects are uniformly self-describing, Java language elements sometimes need the help of a type or interface specification to determine how they should be handled (for example, primitive types). For Smalltalk to interact with Java, this information must be made available in the Smalltalk environment.

Remote references

Given that Java is typed, transparent, generic remote references (in SST) are impossible. Instead, Java uses stubs and skeletons. A stub is a proxy similar to that of SST but is specific to a particular class. It defines all of the remote methods defined by the class' remote interfaces. These methods in effect trap message sends, marshal the arguments and send a message to the remote object for which the stub is a proxy. The effect is the same, the implementation is different. Skeletons are the server-side version of stubs. In JDK versions prior to 1.2, the skeleton code was class-specific and contained the necessary code to receive requests, unmarshal the arguments and dispatch the message to the proxied object. In later versions of the JDK, class-specific skeletons have been replaced with a generic option and are no longer necessary. The RMI Wizard generates the proper runtime structures based upon the level of JDK you indicate.

Distributed GC

There are many possible DGC algorithms each with their own merits and short-comings. Java uses a DGC based on the Network Objects work by Birrel, et al, at Digital. SST uses a distributed mark/sweep algorithm loosely based on work at University of Tokyo by Kamada, et al. These two algorithms are fundamentally incompatible.

SST contains components which enable the interoperation of Java and Smalltalk through Java RMI and for the most part eliminate the limitations imposed by these differences. Users of SST can send to and receive messages from Java systems in a transparent way providing they meet certain requirements. The following sections detail the steps you must take to interoperate with Java RMI. Users keen to see how this works and try it for themselves are encouraged to look at the examples in SstPingPongRmi*.