Server Smalltalk Guide
-
- 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 has uses stubs and skeletons. A
stub is 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. They contain
class-specific code to receive requests, unmarshal the arguments and dispatch
the message to the proxied object.
- 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*.
[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]