1. Eric Tryon Brian Clark Christopher McKeowen

2. System Architecture 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

3. Architectural Overview 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

4. Overview Cont. 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

5. Overview Cont. 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.

6. Stub/Skeleton Layer Basics 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.

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

8. Skeleton 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

9. Remote Reference Layer 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)

10. Invocation Protocol 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 client- side component can forward the invocation to the multicast group rather than just a single remote object

11. Transport Responsibilities 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

12. Transport 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.

13. Transport cont. 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).

14. Garbage Collection 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.

15. Dynamic Stub Loading 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