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:

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, 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:

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

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



© 2020 by Stephen Wong