Information Technology Reference
In-Depth Information
such as CORBA, the stub is compiled into the client and linked before runtime.
In RMI, the stub originates with the client and is loaded dynamically and may
therefore be different for different objects with the same apparent type. The actual
type of the stub is loaded at runtime when the system is able to determine the
exact type [116].
The stub forwards requests to the server using the remote reference layer.
The remote reference layer implements the semantics of the type of invocation, for
example unicast or multicast communication. The remote reference layer therefore
provides a framework for adding additional types of remote object communication
[122], although unicast communication is the only implementation that is provided
by default.
The transport layer is responsible for connection setup, connection manage-
ment and keeping track of and dispatching to remote objects. To dispatch to a
remote object, the call is forwarded by the transport to the server specific remote
reference layer. The remote reference layer hands the request off to the server's
skeleton, which in turn passes it to the remote object implementation to perform
the actual method call. Return values from the call are passed back through the
skeleton, the remote reference layer, and finally to the client stub [122].
The RMI system passes parameters and return values either by reference
or by value. If the object to be passed is a remote object (it implements the
java.rmi.Remote interface) a remote reference is passed. If, however, the object
is not a remote object, a copy of that object is passed.
RMI uses Java's object serialization mechanism to marshal and unmarshal
parameters and return values, which encodes objects and any objects they refer
to, into a byte stream for transmission from one virtual machine to another. Once
the byte stream is received, it is converted into the original object using a process
known as de-serialization. RMI therefore requires that all objects and any ob-
jects they reference, that are used as parameters or return values, implement the
java.io.Serializable interface, a marker interface (one that has no methods)
that indicates to the serialization system that they may be safely converted to a
byte stream.
The objects that are passed are 'real objects' in the sense that they include
both the object's data as well as an annotation describing the type of the object.
If an object of a previously unknown type is received, the RMI system fetches
the bytecode for the object and loads it into the receiving process. By preserving
the object's type, RMI preserves the basic object-oriented notion of polymorphism
[116, 122].
In order to fetch the bytecode of a previously unknown object, RMI uses
Java's dynamic class-loading mechanism. The following classes are loaded during
an RMI call [122]:
• Classes of remote objects and their interfaces.
• Stub and skeleton classes that serve as proxies for remote objects.
Search WWH ::




Custom Search