COMP 310
Fall 2010

Lec27: RMI Stubs Everywhere!

Home  Info  Owlspace  Resources

Today we will discuss different ways to pass RMI stubs around in a network-connected application.

Confusing Terms between Client-Server Architectures and RMI Systems

The designers of RMI chose an unfortunate terminology to describe the various parts of the RMI system:  "client" and "server".  These terms often clash with the more colloquial usage of those terms to describe network architectures.

Colloquially, the "client" is the part of a networked program that many users are operating to request services from a single central "server".   Thus a classic "client-server" architcture consists of multiple clients connecting to a single central server.   This is in contrast to the classic "peer-to-peer" architecture, where there is no central server and each peer provides some of the services needed by the other peers, thus resulting in network connections that go from one peer to the next on an equal level. 

Client-Server Architecture Peer-to-Peer Architecture
client-server architecture peer-to-peer architecture

RMI Client-Server:

On the other hand, the RMI system has very strict definitions for "client" and "server", which we will attempt to disambiguate by referring to as "RMI client" and "RMI Server":

RMI Client:  The part of the program that requests an RMI stub from a Registry and uses that stub to perform remote services for it. 

RMI Server:  The object that from which an RMI stub is created an thus provides remote services for the RMI client via that stub.   The stub is not the RMI server; the stub is just a proxy for the RMI server object.

In the Compute Engine project, we have several RMI client-server sets:

RMI Server object:

RMI Client object that uses it:



myTA (a local IRemoteTaskViewAdapter variable in the ComputerEngine.setTextAdapter() method)


clientTA (an IRemoteTaskViewAdapter field in ClientModel)


Bottom Line:  RMI "clients" and "servers" do not always correspond to the colloquial usage of those terms!


RMI Stubs and How To Get and Send Them

We've already seen that a RMI client can obtain a stub to a RMI server via the Registry.   But consider the fact that the stub is really just an object that is instantiated on the same machine as the RMI server, that the Registry serializes and sends to the RMI client.   (Note: Technically, the Registry does not have to be co-located on the same machine as the RMI server object.  Therefore, the stub may initially get serialized and sent to the Registry machine before the client requests it.)

In the Compute Engine project, stubs are passed in two other ways in order to establish view connections as part of the MVC architectures on both the Client and Engine sides of the program:

The 3 methods of passing RMI stubs are diagrammed below:

RMI Stub-Passing Mechanisms

RMI stub passing


What does it all mean?

(Humorous interpretation, good advice, and in case you didn't already know...)

The above discussion has several implications:

We can see from these conclusions that if we bind just a very few factory objects as stubs into the Registry, from these factory(s) we can dynamically build our networked system.

But there is a drawback:  Each stub consumes system resources in the form of allocated ports.  Once a stub is tied to a port the ability of other entities to use that port are severely limited, if not completely excluded.   This can severely impact a system and causes other headaches, such as having to reduce the system safety by opening more ports through the firewall.

In the next project, we will explore how to mitigate some of these issues by combining extended visitors with RMI and implementing a "Message-Passing Architecture".




© 2010 by Stephen Wong and Scott Rixner/p>