RMI Stubs Everywhere!

COMP 310 Java Resources Eclipse Resources

(Back to Java RMI)

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

Careful! Don't confuse creating an RMI stub with passing a stub. Creating an RMI stub from an RMI Server object is accomplished using UnicastRemoteObject.exportObject(). This is a local operation that instantiates a stub that can then be passed to other applications via the techniques discussed below. The discussion below is about transporting RMI stubs across the network, i.e. these are remote operations.

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:

Stub passed as an input parameter to another stub's method: The ICompute stub is the main stub obtained by the ClientModel from the RMI Registry. A IRemoteTaskViewAdapter object's stub is passed to the remote ComputeEngine through the ICompute stub's setTextAdapter() method as an input parameter. This enables the ComputeEngine to send text information directly to the ClientModel's view.
Stub returned by another stub's method: The ComputeEngine's setTextAdapter() method returns an IRemoteTaskViewAdapter object. In fact, it returns the stub of an IRemoteTaskViewAdapter object which displays Strings on the EngineModel's view (or the ComputeEngine's view, depending on how you want to look at it). Since the ComputeEngine's setTextAdapter() method is called via its stub over in the ClientModel, the IRemoteTaskViewAdapter stub is returned all the way back over to the ClientModel. The ClientModel can now send text information directly to the remote view.

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:

RMI stubs can serve as factories for more stubs by returning stubs. Not all stubs need to be bound in the Registry to be used.
Some parts of the system may not need to bind a stub into the Registry at all. They send their stubs to other parts of the system via input parameters of methods of other stubs.
At least one stub somewhere needs to be bound in the Registry. That's the stub that starts everything else. The number of stubs bound in a Registry should be kept to an absolute minimum, i.e. only one.
More than one RMI Client may use the same stub (technically, different copies of the same stub from the RMI server machine). Stubs can be replicated by passing them around the network, creating multiple RMI clients all connected to the same RMI server.

We can see from these conclusions that if we bind just a very few factory objects as stubs into the Registry, i.e. only one, 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".

For any given application, the RMI Registry should only hold ONE stub!

Do NOT put every stub in the Registry! Only put a SINGLE stub that enables a client to retrieve or supply ALL additional stubs!

Even when connecting to multiple apps on multiple machines, ONLY the stub for the FIRST machine needs to be in the Registry! -- A stub can have method(s) to supply stubs to other machines/apps!

Comparing RMI Stubs

RMI stub equality behaves transparently to the developer and stubs can be used in comparisons as if they were instances of their associated RMI Server objects. That is:

If two RMI stubs, stub1 and stub2, refer back to the same RMI Server object, they will compare properly, i.e. they will adhere to the Java rules for equality:

true = stub1.equals(stub2) = stub2.equals(stub1)

stub1.hashCode() = stub2.hashCode()

As per the same Java language rules, if two RMI stubs, stubA and stubB, refer back to the different RMI Server objects:

false = stub1.equals(stub2) = stub2.equals(stub1)

stub1.hashCode() may or may not equal stub2.hashCode()

In such, RMI stubs can be used as keys in hashtables and other situations requiring comparable objects.