• Objects can be implemented in many different ways
• Compile-time objects
• e.g., instance of classes written in object-oriented language like Java, C++
• Data-base objects
• Procedural languages like C,with an appropriate “wrapper code” that gives it the appearance of an object
• System like Java RMI support compile-time objects
• Not possible or difficult in language-independent RMI middleware such as CORBA
• These systems use object adapters
• Implementations of object interfaces are registered at an object adapter, which acts as an intermediary between the client and the object implementation

Persistent vs. Transient Objects

• Persistent objects 
• continue to exist even if they are not contained in the address space of server process
• the “state” of a persistent object has to be stored on a persistent store, i.e., some second storage
• invocation requests result in an instance of the object being created in the address space of a running process
• many policies possible for object instantiation and (de)instantiation
• Transient objects
• Only exist as long as their container server process are running
• i.e., only exist in memory

Static vs Dynamic Remote Method Invocations

• Static invocation
• Typical ways for writing code that uses RMI is similar to the process for writing RPCC
• declare the interface in IDL, compile the IDL file to generate client and server stubs, link them to client and server side code to generate the client and the server executables
• requires the object interface to be known when the client is being developed
• Dynamic invocation
• The method invocation is composed at run-time
• invoke (object, method, input_parameters, output_parameters)
• Useful for applications where object interface are discovered at runtime
• e.g., object browser, batch processing systems for object invocations

Design Issues for RMI

• RMI invocation semantics
• Invocation semantics depend upon implementation of Request-Reply protocol used by RMI
• Could be Maybe, At-least-once, At-most-once

• Transparency
• Should remote invocations be transparent to the programmer?
• Partial failure, higher latency
• Different semantics for remote objects, e.g., difficult to implement “cloning” in the same way for local and remote objects or to support synchronization operations e.g., wait/notify
• Current consensus
• Access transparency
• Remote invocations should be made transparent in the sense that syntax of a remote invocation is the same as the syntax of local invocation
• Distinguish
• But programmers should be able to distinguish between remote and local objects by looking at their interfaces, 
• e.g., in Java RMI, remote objects implement the Remote interface

Implementing Issues for RMI

• Parameter Passing
• Representation of a remote object referece

• Request/Reply protocol
• Handling failures at client and/or server
• Issues in marshaling of parameters and results
• Input, output, inout parameters
• Data representation
• handling reference parameters
• Distributed object references
• handling failures in request-reply protocol
• Partial failure
• Client, server, network
• Supporting persistent objects, object adapters, dynamic invocations, etc

Marshalling

• Client unable to locate server
• Reasons
• Server has crashes
• Server has moved
• (RPC systems) client compiled using old version of service interfance
• System must report error (remote exception) to client 
• Loss of transparency
• Request message lost
• Retransmit a fixed number of times before throwing an exception
• Reply message lost
• Client resubmits request
• Server choices
• Re-execute procedure
• Server should be idempotent so that it can be repeated safely
• Filter duplicates
• Server should hold on to results until ackowledged
• Server crashes after receiving a request
• At least once
• Keep trying till server comes up again
• At most once
• Return immediately
• Exactly once impossible to achieve
• Client crashes after sending a request
• If a client crashes before RPC returns, we have an “orphan” computation at server
• Waste resources, could also start other comutations
• Orphan detection
• Reincarnation
• Client broadcasts new epoch when it comes up again
• Expiration
• RPC has fixed amount of time to do work

Note

• Implementing the request-reply protocol on top of TCP
• Does not help in providing applications with different invocation semantics
• TCP does not help with server crashes
• If a connection is broken, the end points do not have any guarantees about the delivery of messages that may have been in transit

RMI Software Components

• Communication module
• Implements the request-reply protocol
• Remote reference module
• Responsible for translating between local and remote object references and for creating remote object references
• Maintains remote object table that maintains a mapping between local&remote object references
• E.g., Object Adapter in CORBA

• Activation of remote objects
• Some applications require that information survive for long periods of time
• However, objects not in user all the time, so keeping them in running processes is a potential waste of resources
• Object can be activated on demand
• E.g., standard TCP services such as FTP on UNIX machines are activated by inetd
• Active and passive objects
• Active objects
• Instantiated in a running processes
• Passive objects
• Not currently active but can be made active
• Implementation of its methods, and marshalled state stored on disk
• Activator responsible for
• Registering passive objects that are available for activation
• Starting named server processes and activating remote objects in them
• Keeping track of locations of servers for mote objects that it has already activated
• Examples
• CORBA implementation repository
• JAVA RMI has once activator on each server computer

RMI – Other Topics

• Persistent object stores
• An object that is guaranteed to live between activations of process is called a persistent object
• Stored the state of an object in a marshalled (serialized) form on disk
• Location service
• Objects can be migrated from one system to another during their lifetime
• Maintains mapping between object references and the location of an object
• Distributed Garbage Collection
• Needed for reclaiming space on servers
• Passing “behavior”
• Java allows objects (data+code) to be passed by value
• If the class for an object passed by value is not present in a JVM, its code is downloaded automatically
• Use of reflection in Java RMI
• Allows construction of generic dispatcher and skeleton

• Java approach based on reference counting
• Each server process maintains a list of remote processes that hold remote object references for its remote objects
• When a client first acquires a remote reference to an object, it make addRef() invocation to server before creating a proxy
• When a clients local garbage collector notices that a proxy is no longer reachable, it makes a removeRef() invocation to the server before deleting the proxy
• When the local garbage collector on the server notices that the list of client processes that have a more reference to an object is empty, it will delete the object (unless there are any local objects that have a reference to the object)
• Other approaches
• Evictor pattern
• Leases