Eric Tryon
Brian Clark
Christopher McKeowen

 The architecture can be broken down to three different basic layers
 Stub/skeleton layer
 Remote reference layer
 Transport layer
 The system in place has each layer being independent of each other.
 If you change one layer it doesn’t affect the other 2 layers

 Stub/skeletons — client-side stubs (proxies) and server-side skeletons (dispatchers)
 remote reference layer — invocation behavior and reference semantics (e.g., unicast, multicast)
 Transport — connection set up and management and remote object tracking

 This figure demonstrates how a client can access a remote object via a local stub
 The client accesses a local stub which goes to the
Remote layer.
 The remote layer determines for the client whether it is a unicast or multicast connection to the server.
 For the server it determines whether it live and/or persistent reference to the remote object

 Now the transport layer is used to set up a connection from the client to the server side remote layer.
 The remote layer now hands off to the server-side skeleton and up to the remote object inside the server.
 To return the value, the process must then go in reverse order of which it came to the object.

 The way this layer transmits data to the remote reference layer is through marshal streams with a method referred to as pickling.
 Pickling allows for JAVA objects to be transmitted to address spaces. It copies from the stub to the address space in the remote reference layer.

 A stub for a remote object is the client-side proxy for the remote object.
 A client-side stub is responsible for:
 Initiating a call to the remote object (by calling the remote reference layer)
 Marshaling arguments to a marshal stream (obtained from the remote reference layer)
 Informing the remote reference layer that the call should be invoked
 Unmarshaling the return value from a marshal stream
 Informing the remote reference layer that the call is complete

 A skeleton for a remote object is a server-side entity that contains a method which dispatches calls to the actual remote object implementation
 The skeleton is responsible for:
 • Unmarshaling arguments from the marshal stream
 • Making the up-call to the actual remote object implementation
 • Marshaling the return value of the call onto the marshal stream




Deals with the lower level transport interface.
Each object chooses its own invocation protocol and stays with it for the life of the object.
Invocation Protocols include:






Unicast invocation
Multicast invocation
Support for a specific replication strategy
Support for a persistent reference to the remote
Object (enabling activation of the remote object)
Reconnection strategies (if remote object becomes inaccessible)




They are not mutually exclusive meaning more than one can be used at a time.
Divided into two cooperating components:
 Client-side component
 Server-side component
The client-side communicates to the server-side via the transport layer


These communicate to accomplish the specific invocation and reference semantics
I.e. if a remote object is part of a multicast group, the clientside component can forward the invocation to the multicast group rather than just a single remote object

 In general, the transport of the RMI system is responsible for:
 Setting up connections to remote address spaces


Managing connections
Monitoring connection liveness


Listening for incoming calls
Maintaining a table of remote objects that reside in the local address space


Setting up a connection for an incoming call
Locating the dispatcher for the target of the remote call and passing the connection to this dispatcher

 Consists of 4 basic Abstractions:
 Endpoint - denotes an address space so that a specific transport instance can be obtained
 Transport - The transport abstraction manages
Channels, virtual connection between two address spaces. Responsible for accepting calls on incoming connections to the address space, setting up a connection object for the call, and dispatching to higher layers in the system.

 Channel – It is responsible for managing connections between the local address space and the remote address space for which it is a channel
 Connection - A connection is the abstraction for transferring data (performing input/output)
 Multiple transport implementations may exist
 The design and implementation also allow multiple transports per address space (so both TCP and UDP can be supported in the same address space).





Similar to a local Garbage collection algorithm. Used to delete remote objects which are no longer in use.
RMI uses a reference counting garbage collection algorithm.
To accomplish reference-counting garbage collection, the
RMI runtime keeps track of all live references within each
Java virtual machine
The first reference sends a message saying it is referenced and a count is incremented each time it is referenced. On the other hand, when the object is found to be unreferenced the count is decremented.
 When this hits 0, the object is then deleted if there is no local reference to the object at that moment.





This solves the problem of needing specific stub code at run time as in a static system.
If this wasn’t used errors would be thrown if things did not match up perfectly.
In this scheme, client-side stub code is generated from the remote object implementation class, and therefore supports the same set of remote interfaces as supported by the remote implementation
Dynamic stub loading employs three mechanisms:



Specialized Java class loader
Security manager
Pickling system