A Distributed Object Model for the Java System

1. A Distributed Object Model for the Java System Eric Tryon Brian Clark ChristopherMcKeowen

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