Distributed Objects

Message Passing versus Distributed

Objects
• The message-passing paradigm is a natural model for distributed
computing, in the sense that it mimics inter-human communications.
• It is an appropriate paradigm for network services where processes
interact with each other through the exchanges of messages.
• However, the abstraction provided by this paradigm does not meet the
needs of the complexity of sophisticated network applications.
 Message Passing Paradigm
• Message passing requires the participating processes to be tightly-coupled:
throughout their interaction, the processes must be in direct communication
with each other.
• If communication is lost between the processes (due to failures in the communication
link, in the systems, or in one of the processes), the collaboration fails.
• The message-passing paradigm is data-oriented.
• Each message contains data marshalled in a mutually agreed upon format and is
interpreted as a request or response according to the protocol.
• The receiving of each message triggers an action in the receiving process.
• It is inadequate for complex applications involving a large mix of requests and responses.
• In such an application, the task of interpreting the messages can become overwhelming.
The distributed object paradigm
• provides abstractions beyond those of the message-passing
model.
• In object-oriented programming, objects are used to represent
an entity significant to an application.
• Each object encapsulates:
• the state or data of the entity: in Java, such data is contained in the
instance variables of each object;
• the operations of the entity, through which the state of the entity
can be accessed or updated.
Local Objects vs. Distributed Objects
• Local objects are those whose methods can only be invoked by a local
process, a process that runs on the same computer on which the object
exists.
• A distributed object is one whose methods can be invoked by a remote
process, a process running on a computer connected via a network to
the computer on which the object exists.
The Distributed Object Paradigm
• In a distributed object paradigm, network resources are represented by
distributed objects.
• To request service from a network resource, a process invokes one of
its operations or methods, passing data as parameters to the method.
• The method is executed on the remote host, and the response is sent
back to the requesting process as a return value.
The Distributed Object Paradigm
Message-passing paradigm vs Distributed
objects paradigm
• Message-passing paradigm => data-oriented,
• Distributed objects paradigm => action-oriented:
• the focus is on the invocation of the operations, while the
data passed takes on a secondary role.
• Although less intuitive to human-beings, the distributed-
object paradigm is more natural to object-oriented
software development.
Distributed Object Systems/Protocols
• The distributed object paradigm has been widely adopted in
distributed applications, for which a large number of mechanisms
based on the paradigm are available.
• Among the most well known of such mechanisms are:
• Java Remote Method Invocation (RMI),
• the Common Object Request Broker Architecture (CORBA) systems,
• the Distributed Component Object Model (DCOM),
• mechanisms that support the Simple Object Access Protocol (SOAP).
• Of these, the most straightforward is the Java RMI
From Remote Procedure Call to Remote Method Invocation

Remote Procedure Calls (RPC) – 1

• Remote Method Invocation has its origin in a paradigm called Remote
Procedure Call
• Remote procedure call model:
• A procedure call is made by one process to another, with data passed as
arguments.
• Upon receiving a call:
• the actions encoded in the procedure are executed,
• the caller is notified of the completion of the call,
• a return value, if any, is transmitted from the callee to the caller.
From Remote Procedure Call to Remote Method Invocation
From Remote Procedure Call to Remote Method Invocation

Remote Procedure Calls (RPC) – 2

• Since its introduction in the early 1980s, the Remote Procedure
Call model has been widely in use in network applications.
• There are two prevalent APIs for this paradigm.
• the Open Network Computing Remote Procedure Call, evolved from
the RPC API originated from Sun Microsystems in the early 1980s.
• The other well-known API is the Open Group Distributed Computing
Environment (DCE) RPC.
• Both APIs provide a tool, rpcgen, for transforming remote
procedure calls to local procedure calls to the stub.
 Java Remote Method Invocation
• Remote Method Invocation (RMI) is an object-oriented implementation
of the Remote Procedure Call model.
• It is an API for Java programs only.
Remote Method Invocation
• Using RMI, an object server exports a remote object and registers it with
a directory service.
• The object provides remote methods, which can be invoked in client programs.
• Syntactically:
1. A remote object is declared with a remote interface, an extension of the Java
interface.
2. The remote interface is implemented by the object server.
3. An object client accesses the object by invoking the remote methods associated
with the objects using syntax provided for remote method invocations.
The Java RMI Architecture
Object Registry
• The RMI API allows a number of directory services to be
used[ for registering a distributed object.
• A simple directory service called the RMI registry,
rmiregistry, which is provided with the Java Software
Development Kit
• The RMI Registry is a service whose server, when active, runs on
the object server’s host machine, by convention and by default on
the TCP port 1099.
The interaction between the stub and the
skeleton
• A time-event diagram describing the interaction between the stub and
the skeleton:
The API for the Java RMI
• The Remote Interface
• The Server-side Software
• The Remote Interface Implementation
• Stub and Skeleton Generations
• The Object Server
• The Client-side Software
The Remote Interface
• A Java interface is a class that serves as a template for other classes:
• it contains declarations or signatures of methods[1] whose implementations
are to be supplied by classes that implements the interface.
• A java remote interface is an interface that inherits from the Java
Remote class, which allows the interface to be implemented using
RMI syntax.
• Other than the Remote extension and the Remote exception that must
be specified with each method signature, a remote interface has the
same syntax as a regular or local Java interface.
The Remote Interface
• The java.rmi.Remote Exception must be listed in the throw clause of
each method signature.
• This exception is raised when errors occur during the processing of a
remote method call, and the exception is required to be caught in the
method caller’s program.
• Causes of such exceptions include exceptions that may occur during
interprocess communications, such as access failures and connection
failures, as well as problems unique to remote method invocations,
including errors resulting from the object, the stub, or the skeleton not
being found.
The Server-side Software
• An object server is an object that provides the methods of and the
interface to a distributed object.
• Each object server must
• implement each of the remote methods specified in the interface,
• register an object which contains the implementation with a directory service.
• It is recommended that the two parts be provided as separate classes.
The Remote Interface Implementation
• A class which implements
the remote interface
should be provided.
• The syntax is similar to a
class that implements a
local interface.
Stub and Skeleton Generations
• In RMI, each distributed object requires a proxy each for the object server
and the object client, knowns as the object’s skeleton and stub respectively.
• These proxies are generated from the implementation of a remote interface
using a tool provided with the Java SDK:
the RMI compiler rmic.
rmic <class name of the remote interface implementation>
For example:
rmic SomeImpl
• As a result of the compilation, two proxy files will be generated, each
prefixed with the implementation class name:
SomeImpl_skel.class
SomeImpl_stub.class
Stub and Skeleton Generations
The stub file for the object
• The stub file for the object, as well as the remote interface file, must
be shared with each object client – these file are required for the client
program to compile.
• A copy of each file may be provided to the object client by hand.
• In addition, the Java RMI has a feature called “stub downloading” which
allows a stub file to be obtained by a client dynamically.
The Object Server
• The object server class is a class whose code instantiates and exports
an object of the remote interface implementation.
The Client-side Software
• The program for the client class is like any other Java class.
• The syntax needed for RMI involves
• locating the RMI Registry in the server host,and
• looking up the remote reference for the server object; the reference
can then be cast to the remote interface class and the remote
methods invoked.
The Client-side Software
Looking up the remote object
• The lookup method of the Naming class is used to retrieve the object reference, if any, previously stored in the registry
by the object server. Note that the retrieved reference must be cast to the remote interface (not its implementation) class.

Invoking the Remote Method

• The remote interface reference can be used to invoke any of the methods in the remote interface, as in the example:
String message = h.method1();
System.out.println(message);
• Note that the syntax for the invocation of the remote methods is the same as for local methods.
• It is a common mistake to cast the object retrieved from the registry to the interface implementation class or the
server object class .
• Instead, it should be cast as the interface class.