Distributed Objects and Remote Invocation

Properties of middle providing remote invocation and events:

  • Location transparency:  Invoking client does know where the receiver is located nor even those objects sending or receiving events.
  • Communication Protocols: UDP/TCP
  • Computer Hardware: They hide properties such byte-ordering
  • Operating Systems: Independent from OSs
  • Programming Languages:  CORBA allows interaction between different programming languages

Distributed Objects

  • Can be used as a classical client-sever computational model, or distributing objects.
  • Using its own methods to access data helps integrity and hetereogenety
  • via RMI or local cache

Distributed Object model

  • Method invocation between objects in different processes known as RMI
  • Remote Objects are those which can receive remote invocations
  • Remote Object Reference: an object can invoke other if it has access to its remote object reference. Unique identifier across the Distributed System, different from the local object reference.
  • Remote Interface: every remote objects has one.  Local objects can invoke local/remote methods.
  • Garbage collection: local collector and a module for distributed collection, based on reference counting.

Design Issues for RMI

RMI Invocation semantics:

  • Maybe invocation semantics: client is not sure whether the remote method executed. Only useful when  failed invocation are acceptable.
  • At-least-once invocation semantics: The invoker receives a result or an exception. Achieve by retransmission. Suffers from: crash failures, arbitrary failures executing more than once.
  • At-most-once invocation semantics: Same as above, using all fault tolerance measures assuring only one execution after several requests.

Transparency:

  • Retransmissions are transparent to the caller, as well as locating remote object.
  • Same syntax as local but remote difference expressed in the interface.
  • Object receiving remote invocation should be able to keep its state consistent along with concurrency.

Implementation of RMI

Communication Module: Using request-reply protocol, marshalling/unmarshalling and server selects the selector.

Remote Reference Module:

  • Translates between local and remote references using a table to match those.
  • When an objects is passed as argument or result for first time, reference module is called.
  • When a request/reply arrives reference module is asked to get a proxy or remote object. If not there new proxy is created.

RMI Software:

  • Proxy: remote invocation made transparent as a local object. Forwards to remote object. Is the one which does (un)marshalling
  • Dispatcher: server has one and an skeleton per remote object.
  • Skeleton:  unmarshalls the arguments in a request and calls the corresponding method and sends the response back.

Binder: services holding a table mapping names and remote objects.

Activators: Processes that  start servers to host remote objects. Activation is creating a new object from a passive and initialize  its instance variables

Persistent Objects:

  • Lives between activations.
  • Activated when their methods are invoked.
  • Stored when reach a consistent state.
  • Object reachable from a root or inherit a class

Distributed Garbage Collection:

  • The proxy client should inform the proxy server when it is going to be destroyed so the proxy server can free resources.
  • Server leases an object for a period of time, till a removeRef is invoked or it expires.

Remote Procedure Call (RPC):

at-least-once / at-least-once generally chosen

Request-Reply protocol omitting object references from request messages.

stub procedure: behaves as a local procedure but it marshals and send the remote invocation and retrieve results back.

Server has a dispatcher to select one stub procedure at the server.

Events and Notifications:

publish-subscribe paradigm used. Objects publish the events others can subscribe (registering interest).

Objects that represent events are called notifications.

Distributed event-based systems characteristics:

  • Heterogeneous: Different components just need to publish their events.
  • Asynchronous: notifications are sent asynchronously.

Roles of observers:

  • Forwarding: Receives a notification and does all the work forwarding it to the subscriber
  • Filtering Notifications
  • Pattern of events
  • Notification mailboxes, only passing them when the subscriber is ready to receive them.