Chapter 5: Distributed Objects and Remote Invocation
---

- in a distributed object system, an object's data should be
  accessible only via its methods;

- objects can be accessed via object references;

- an interface provides a definition of the signatures of a set of
  methods without specifying their implementation;

- an action is initiated by an object invoking a method in another
  object;

- the state of an object consists of the values of its instance
  variables;

- remote invocations are method invocations for objects in different
  processes (in the same machine or not);

- remote objects are objects that can receive remote invocation;

- heart of the distributed object model:

	- remote object reference;
	- remote interface: specifies which methods can be invoked
	  remotely;

- CORBA IDL can be used to define the interface of a class.  The
  classes of remote objects can be implemented in any language for 
  which an IDL compiler is available;

- depending whether request retransmission (RT), duplicate filtering
  (DF), and retransmission of results (RR) are present, we may
  identify three different semantics:

	Semantics		RT	DF	   RR
	--------------------------------------------------
	Maybe			No	Not appl.  Not appl.
	
	At-least-once		Yes	No	   Re-execute procedure

	At-most-once		Yes	Yes	   Retransmit repply


- in both Java RMI and CORBA, the invocation semantics is
  at-most-once, but CORBA allows maybe semantics to be requested 
  for methods that do not return results; Sun RPC provides
  at-least-once semantics;

- RMI is composed of:

	- communication module;
	- remote reference module;
	- the RMI software;

- a remote reference module (RRM) is responsible for translating between
  local and remote object references (ROR) and for creating remote object
  references;

- the RRM in each process contains a remote object table (ROT) that
  records the correspondence between local object references in that 
  process and remote object references;

- when a remote object is to be passed as argument or result for the
  first time, the RRM is asked to create a remote object reference,
  which it adds to its table;

- when a ROR arrives in a message (either request or reply), the RRM
  is asked for the corresponding local object reference (LOR);

- the RMI software is a layer of software between the application-level 
  objects and the communication and remote reference modules;

- three roles for middleware objects:

	- Proxy: the role of the proxy is to make RMI transparent to
	  clients by behaving like a local object to the invoker, but
	  actually contacting the remote object.  It hides the ROR,
	  marshalling/unmarshalling of messages and the communication
	  itself.  THERE IS ONE PROXY FOR EACH REMOTE OBJECT FOR WHICH
	  A PROCESS HOLDS A ROR.

	- Dispatcher: a server has one dispatcher and skeleton for
	  each class representing a remote object.  The dispatcher 
	  receives the request message from the communication module 
	  and uses the methodId to select the appropriate method in
	  the skeleton, passing on the request message;

	- Skeleton: the class of a remote object has a skeleton, which
	  implements the methods in the remote interface.  It is
	  responsible for the marshalling/unmarshalling of messages.

- the classes for the proxy, dispatcher, and skeleton used in RMI are
  generated automatically by an interface compiler (e.g. Orbix's
  implementation of CORBA, Java RMI);

- the server program contains the classes for the dispatchers and
  skeletons, together with the implementations of the classes of all 
  the remote objects that it supports;

- the client program will contain the classes of the proxies for all
  remote objects it will invoke;

- remote object interfaces cannot include constructors, i.e., remote
  objects cannot be created by remote invocation.  Remote objects are
  created in the initialization section or in methods in a remote 
  interface designed for that purpose (sometimes called factory methods);

- to obtain remote references, a binder is used.  A binder in a
  distributed system is a separate service that maintains a table
  containing mappings from textual names to RORs.  Servers register
  their objects with the binder, while clients contact it to translate 
  textual names;

- an activation service (like the one implemented by inetd) is
  implemented in RMI.  This makes unecessary to maintain all servers 
  running at all times;

- a remote object can be either active or passive at a given time;

- a passive object consists of the implementation of its methods and
  its state in marshalled form.  Activation consists of creating an 
  active object from the passive form.

- a location service maps RORs to their probable current locations;

- distributed garbage collection is usually performed by reference
  counting.  The server for a remote object should be informed when
  a proxy is created/destroyed for one of its objects;

- in Java distributed GC, when a server adds a remote process to the 
  list of holders of one of its objects (a reference list), it also 
  returns a lease.  The reference count is decreased when a remove 
  request is received or when the lease expires;
  
REMOTE PROCEDURE CALL (RPC):

- not concerned with objects and remote references (RRM not needed);

- a client includes one stub procedure for each procedure in the
  service interface.  This stub procedure is responsible for
  marshalling/unmarshalling and passing the message to the communication
  module;

- the server contains a dispatcher together with oneserver stub
  procedure and one service procedure for each procedure in the
  service interface.  The dispatcher selects one of the server stub
  procedures according to the procedure identifier in the request
  message;

SUN RPC CASE STUDY:

- can be used over either TCP or UDP;

- interface language called XDR and an interface compiler called rpcgen;

- instead of using interface names, Sun RPC (SRPC) uses a program
  number and a version number (incremented when the signature of 
  a function changes).  Both numbers are passed in request messages;

- a procedure definition specifies a procedure signature and a
  procedure number;

- only a single parameter is allowed (structures can be used);

- a single result is also returned;

- each program as a number and a version, and the procedures inside
  the program are ordered beginning at 1 (0 is reserved for a null
  procedure, used for testing purposes);

- the compiler can be used to generate:

	- client stub procedures;
	- server main procedure, dispatcher, and server stub
	  procedures;
	- XDR marshalling/unmarshalling procedures.

- local binding sevice: the port mapper, which runs on a well-known
  port number.  When a server starts up, it registers it program
  number, version number, and port number with the local port mapper.
  When a client starts up, it finds out the server's port by making a
  remote request to the port mapper at the server's host;

- several authentication mechanisms are possible:

	- none;
	- UNIX style, using UID and GID;
	- shared-key-based MACs;
	- Kerberos style of authentication;

- a field in the header indicates which one is being used;

JAVA RMI CASE STUDY:

- any object that is serializable can be used as parameter or output
  value in RMI;

- classes for arguments and result values are donwloaded to the
  recipient by the RMI system where necessary;

- all serializable non-remote objects are copied into the message and
  passed by value;

- whenever an object that implements the Remote interface is
  serialized, it is replaced by its ROR, which contains the name of
  its class;

- when any object is serialized, its class information is annotated
  with the location of the class (as a URL), enabling the class to be
  downloaded by the receiver;

- the RMIregistry is the binder for Java RMI, containing mappings from
  textual names to ROR at each server.  This is not system wide;
  clients must direct their lookups to particular hosts;