- Forward


Remote Method Invocation
An Introduction


Prof. David Bernstein
James Madison University

Computer Science Department
bernstdh@jmu.edu

Print

Motivation
Back SMYC Forward
  • Traditional Distributed Applications:
    • A "sender" on one host must convert the objects it wants to transmit from their actual type to a string (a process which is known as marshalling)
    • The receiver, on the other hand, must convert the incoming string back to objects (a process which is known as unmarshalling)
  • An Observation:
    • This can be very tedious
Motivation (cont.)
Back SMYC Forward

Marshalling/Unmarshalling

images/marshaling.gif
Motivation (cont.)
Back SMYC Forward
  • One Objective:
    • Automate the marshalling/unmarshalling process
  • Another Objective:
    • Have an object on one host invoke the methods of an object on another host
A Design for Remote Method Invocation
Back SMYC Forward
  • An Observation:
    • The proxy pattern provides a way to achieve both of these goals
  • Terminology:
    • A stub is a proxy for a remote object which is responsible for forwarding method invocations on remote objects to the host where the actual implementation resides
    • The stub communicates with a skeleton of the remote object which invokes the actual remote object implementation
A Design for Remote Method Invocation (cont.)
Back SMYC Forward

Stubs and Skeletons

images/stubs_skeletons.gif
A Design for Remote Method Invocation (cont.)
Back SMYC Forward
  • An Observation:
    • The stub and the remote object cannot be members of the same class (since they have different responsibilities)
  • A Requirement:
    • The stub and the remote object must appear to be of the same type
  • A Solution:
    • Have them implement the same interface
An Example of RMI
Back SMYC Forward

The Core Classes/Interfaces

javaexamples/remoteobjects/Course.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Core Classes/Interfaces (cont.)

javaexamples/remoteobjects/CourseDatabase.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Core Classes/Interfaces (cont.)

javaexamples/remoteobjects/CourseDatabaseImpl.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Stub

javaexamples/remoteobjects/CourseDatabaseStub.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Skeleton

javaexamples/remoteobjects/CourseDatabaseSkeleton.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Factory

javaexamples/remoteobjects/CourseDatabaseFactory.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Client Driver

javaexamples/remoteobjects/ClientDriver.java
 
An Example of RMI (cont.)
Back SMYC Forward

The Server Driver

javaexamples/remoteobjects/ServerDriver.java
 
Implementation of Stubs and Skeletons
Back SMYC Forward
  • An Annoyance:
    • The process is fairly tedious
  • An Observation:
    • The process is "repetitive" so it should be possible to automate it
Object Location Management
Back SMYC Forward
  • It would be nice if...
    • The "invoker" did not need to know where the remote objects reside (or whether they are, in fact, even located remotely)
  • One Possible Solution:
    • Have a naming/directory service that maps names to remote objects
    • Objects that want to make themselves available to be invoked must register themselves
    • The invoker then need only request an object (by name) from the service
Object Location Management (cont.)
Back SMYC Forward

One Possible Design

images/rmi.gif
Object Location Management (cont.)
Back SMYC Forward
  • An Observation:
    • It is important to be able to uniquely identify objects in the naming/directory service
  • One Solution:
    • Add a namespace prefix to the identifier (to avoid collisions)
There's Always More to Learn
Back -