COMP 310
Fall 2012

Lec27: RMI Stubs Everywhere!

Home  Info  Owlspace  Java Resources  Eclipse Resources

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

 

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".

 

 

 


© 2012 by Stephen Wong