The trade offs to be solved are:

• How should references be represented?

• How much transparency to provide?

• How much are users willing to pay in execution overhead for each degree of transparency?

• How much are the programmers of the distributed object system willing to pay in developing time for providing transparency?

Reference representation

• A machine address + an address space identifier.

  Disadvantage: What if the remote runtime compacts the memory heap?

• An object identifier + an address space identifier.

  A table maps object identifiers to machine addresses at any address space.

  Disadvantage: introduces an overhead in memory usage and execution time for local objects.

Best solution:

• If the referenced object is local: the machine address of the object.

• If the referenced object is remote: the machine address of a descriptor for the object. The descriptor should keep:
  • An identifier of the address space.
  • An object identifier.

Providing location transparency for accessing instance variables

• Every access to an instance variable should test if the object is local or remote.

• If the object is local, access the instance variable as in a non distributed system.

• If the object is remote, send a message to the remote process asking for the access, and wait (patiently) for the answer.

• The runtime must provide one thread to serve remote accesses to local instance variables.

Providing location transparency for method invocation

• Implements the remote object descriptor as a subclass of the class of the concrete remote object.

• Redefine all methods so they send messages to the remote process and wait for their remote execution.

• Every method should be redefinable!

• The runtime must provide threads to serve remote methods invocations to local objects.

Location or Invocation Transparency?

• Providing location transparency only for method invocation can be implemented at no extra cost for local objects.

• However, providing location transparency for accessing instance variables does introduce an overhead for local objects.

On the other hand:

• The latencies of network communication will hide any extra cost for translating object identifiers to machine addresses or other housekeeping tasks.

• The cost of a remote method invocation would be typically hiden also by the latencies of network communication.

• So, accessing an instance variable will cost in time as much as a remote method invocation.

• If a program should execute several accesses to instance variables of a same remote object, it would be more efficient that the programmer encapsulates those accesses in a single method.

Therefore:

• The value added by full location transparency does not justify the overhead introduced on applications running on a single address space.

• It would be advisable to guide the programmer to encapsulate several remote operations on a single method invocation, to reduce the penalties of network latency.

Network Objects

• Remote references.

• Distributed typing.

• Location transparency of method invocation.

• A mechanism for exporting and importing named objects.

• Distributed Garbage Collection (but does not collect distributed cycles).

• Fault tolerance.

• Does not require language or compiler modifications.

• Does not introduce an overhead on local object management.

Restrictions of transparency

• Let r be a remote reference declared to reference objects of type R.

• R must be a pure type (i.e. without instance variables).

• R must be subtype of a generic remote type (Remote in RMI and NetObj.T in Modula 3).

• Let C be the class implementing the concrete object referenced by r.

• C must be a subtype of the generic remote type.

Stub and skeletons

• A stub is a descriptor of a remote reference.

• There is only one stub per process, so testing if two remote reference are the same is equivalent to the identity test of the stubs.

• A stub generator takes the class C as input an produces a stub class which is also a subtype of the generic remote type. The stub class implements all the methods of R as message sending.

• The stub generator produces also a skeleton which receives the messages and dispatches the method invocations to the concrete object.

Requirements

• Object orientation with inheritance.

• Threads.

• Inter-process communication.

• Garbage collection with finalization and weak references.

• Reflection.