Distributed Systems Development - Autonomics Development: A Domain-Specific Aspect Language Approach - page 28

Application Client Server

Stub Skeleton
Remote Reference Layer RMI

Transport Distributed Garbage Collection

Classloader Security Manager

JVM

Garbage Collection etc.

Figure 2.11. RMI system architecture.

Waldo et al. [118] argue that this approach is fundamentally wrong and that
non-distributed objects cannot be treated the same as distributed objects as there
are fundamental differences in terms of latency, memory access, partial failure, and
concurrency. They further argue that the merging of the computational models of
local and distributed computing is both unwise to attempt and unable to succeed.
Java's Remote Method Invocation (RMI) takes an entirely different approach
to other types of distributed systems. RMI differs not only in the details but in the
basic set of assumptions made about the distributed systems in which it operates
[116].
While most distributed systems are heterogeneous, RMI assumes that the
client and the server are both running in a Java virtual machine and are both
written in Java. By doing so, RMI removes the need to describe remote interfaces
using a language-neutral IDL. Instead, the Java interface construct is used to
declare a remotely accessible interface as shown below:

public interface IDateService extends java.rmi.Remote {
Date getDate() throws RemoteException;

}

The RMI system architecture is illustrated in Figure 2.11. Messages from the
client application to the server pass through the stub (or proxy), an implementa-
tion of the remote objects exported interface.
The stub object is generated either statically by the RMI compiler, rmid ,
or dynamically at runtime. Unlike standard RPC IDL compilers, such as those
provided by CORBA systems, the stubs are generated on the implementation class
of the object which the stub refers to. These stub objects therefore support all the
remote methods that the remote object's implementation supports. In a system