- 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

marshaling
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

stubs_skeletons
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

rmi
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 -