DC - Chapter - 7 : Distributed Objects

7.1 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.

·     Processes are tightly-coupled: Throughout their interaction, the processes must be in direct communication with each other. If communication is lost between the processes(due to failure 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 containing marshalled data, 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 is a paradigm that provides abstractions beyond those of the message-passing model.  It is based on objects that exist in a distributed system.

In Object-oriented programming, supported by an    object-oriented programming language such as Java, 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 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.

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.

                               

                                     Figure 7.1 The distributed objects paradigm

Figure 7.1 illustrates the paradigm

·        A process running in a host A makes a method call to a distributed object residing on host B, passing with the call data for the parameters if any.

·        The method call invokes an action performed by the method on host B, and a return value, if any, is passed from host B to host A.

·        A process which makes use of a distributed object is said to be a client process of that object, and the methods of the objects are called remote methods (as opposed to local methods, or methods belonging to a local object) to the client process.

7.2 An Archetypal Distributed Object Architecture

                               Figure 7.2: An Archetypal Distributed Object Architecture

·        A distributed object is provided , or exported, by a process, here called the Object Server. A facility, here called an Object Registry, must be present in the system architecture for the distributed object to be registered.

·        To access a distributed object, a process –an Object Client –looks up the object registry for reference to the object. This reference is used by the object client to make calls to the methods.

·        Logically, the object client makes a call directly to a remote method.

·        In reality, the call is handled by a software component, called a client proxy, which interacts which the software on the client host that provides the runtime support for the distributed object system. 

·        The runtime support is responsible for the inter-process communication needed to transmit the call to the remote host, including the marshalling of the argument data that needs to be transmitted to the remote object.

·        A similar architecture is required on the server side, where the runtime support for the distributed object system handles the receiving of messages and the unmarshalling of data, and forwards the call to a software component called the server proxy. 

·        The server proxy interfaces with the distributed object to invoke the method call locally, passing in the unmarshalled data for the arguments. 

·        The method call results in the performance of some tasks on the server host.  The outcome of the execution of the method, including the marshalled data for the return value, is forwarded by the server proxy to the client proxy, via the runtime support and network support on both sides.

7.3 Distributed Object Systems

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,

·        .NET and its predecessor, the Distributed Component Object Model (DCOM)

·        Mechanisms that support the Simple Object  Access Protocol (SOAP). 

Of these, the most straightforward is the Java RMI

  

7.4 Remote Procedure Calls

‘Remote Method Invocation’ has its origin in a paradigm called Remote Procedure Call

In the 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 call, and a  return value, if any, is transmitted from the callee to the caller.

  

            Figure 7.3: Remote Procedure Call Paradigm

                         Figure 7.4 Local Procedure Call Versus Remote Procedure Call

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.

7.5 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.

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:

·         A remote object is declared with a remote interface, an extension of the Java interface. 

·         The remote interface is implemented by the object server.

·         An object client accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations.

7.6 The Java RMI Architecture

                             

                                      Figure 7.5 : The Java RMI Architecture

Figure 7.5 illustrates the architecture of the Java RMI API. As with RPC APIs, Java RMI Architecture calls for proxy software modules to provide the run-time support needed to transform the remote method invocations to local method calls, and to handle the details for the underlying inter-process communications. In this architecture, three abstraction layers are present on both the client side and the server side.

Client-Side Architecture

1. The Stub Layer. A client process’s remote method invocation is directed to a proxy object, known as stub. The stub layer lies beneath the application layer and serves to intercept remote method invocations made by the client program; then it forwards them to the next layer below, the Remote Reference Layer

2. The Remote Reference Layer interprets and manages references made from clients to the remote service objects and issues the IPC operations to the next layer, the transport layer, to transmit the method calls to the remote host.

3.The Transport Layer is TCP based and therefore connection-oriented. This layer and the rest of the network architecture carry out the IPC, transmitting the data representing the method call to the remote host

Server-Side Architecture

The server-side architecture also involves three abstractions:

1. The Skelton Layer lies just below the application layer and serves to interact with the stub layer on the client side.

2. The Remote Reference Layer. This layer manages and transforms the remote reference originating from the client to local references that are understandable to the Skelton layer.

3. The Transport Layer. As with client-side architecture, this layer is the connection-oriented transport layer, that is, the TCP in the TCP/IP network architecture.

Object Registry

The RMI API makes it possible for a number of directory services to be used for registering a distributed object. One such directory service is the Java Naming and Directory Interface(JNDI).The RMI Register, rmiregistry, a simple directory service, is provided with the Java Software Development Kit(JDK). 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.

   

Logically, from the point of view of the software developer, the remote method invocations issued in a client program interact directly with the remote objects in a server program, in the same manner that a local method call interacts with a local object. Physically, the remote method invocations are transformed to calls to the stubs and skeletons at run time, resulting in data transmission across the network link

                                                 

                           Figure 7.6 Interactions between the RMI Stub and Skelton

Logically, from the point of view of the software developer, the remote method invocations issued in a client program interact directly with the remote objects in a server program, in the same manner that a local method call interacts with a local object. Physically, the remote method invocations are transformed to calls to the stubs and skeletons at run-time, resulting in data transmission across network link.

7.7 The API for the Java RMI

The subset of Java RMI API

·         The Remote Interface

·         The Server-side Software

·         The Remote Interface Implementation

·         Stub Generation

·         The Object Server

·         The Client-side Software

The Remote Interface

A Java remote interface is an interface that inherits from the Java Remote Interface. Other than the Remote extension and the Remote exception that must be specified with each method signature, a simple remote interface has the same syntax as a regular or local java interface.

                                  

                                                  A sample remote interface

The java.rmi.RemoteException 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

The object server provides the methods of 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

                              

                                           The Remote Interface Implementation

Stub Generation

In RMI, each distributed object requires a proxy for the object server  and the object client.

This proxy generated from the implementation of a remote interface using a tool provided with the Java SDK:

The RMI  compiler rmic

 rmic SomeImpl

As a result of the compilation, the proxy class  will be generated,  prefixed  with the implementation class name

           SomeImpl_Stub.class

The Object Server

The object server  class instantiates and exports an object implementing the remote interface.

The Naming class provides methods for storing and obtaining references from the registry. The rebind method allows an object reference to be stored in the registry with a URL. The rebind method will overwrite any reference in the registry bound with the given reference name.  The host name should be the name of the server, or simply local host. The reference name is a name of your choice, and should be unique in the registry

 The RMI Registry is required to run on the host of the server which exports remote objects.It can be activated by hand using the rmiregistry utility as follows:

rmiregistry <port number>

where the port number is a TCP port number

If no port number is specified, port number 1099 is assumed. The registry will run continuously until it is shut down (via CTRL-C, for example)

When an object server is executed, the exporting of the distributed object causes the server process to begin to listen and wait for clients to connect and request services of the object. An RMI object is a concurrent server: each request from an object client is served using a separate thread. Note that if a client process invokes multiple remote method calls, these calls will be executed concurrently unless provisions are made in the client process to synchronize the calls.

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

• looking up the remote reference for the server object

• the reference can then be cast to the remote interface and the remote methods invoked

Invoking Remote Method

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. It should be cast as the interface

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 as these files 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

7.8 Steps for Building an RMI Application

Algorithm for Developing the Server-Side Software

1. Open a directory for all the files to be generated for this application. 
2. Specify the remote-server interface in SomeInterface.java.  Compile it until there is no more syntax error.
3. Implement the interface in SomeImpl.java  Compile it until there is no more syntax error.
4. Use the RMI compiler rmic to process the implementation class and generate the stub file and skelton file for the remote object:

                    rmic  SomeImpl

            The files generated can be found in the directory as SomeImpl_Skel.class and SomeImpl_Stub.class.             Steps 3 and 4 must be repeated each time that a change is made to the interface implementation.

5.    Create the object server program  SomeServer.java.  Compile it until there is no more syntax error.

6.     Activate the object server               

            

             java   SomeServer

  Algorithm for Developing the Client-Side Software

1. Open a directory for all the files to be generated for this application.
2. Obtain a copy of the remote interface class file.  Alternatively, obtain a copy of the source file for the remote interface, and compile it using  javac  to generate the interface class file.
3. Obtain a copy of the stub file for the implementation of the interface:

    SomeImpl_Stub.class.

4. Develop the client program SomeClient.java, and compile it to generate the client class.

5. Activate the client.

     java SomeClient

                                                

                               Figure 7.17 Placement of files for an RMI Application

7.9 Testing and Debugging

1. Build a template for a minimal RMI program.  Start with a remote interface with a single signature, its implementation using a stub, a server program which exports the object, and a client program which invokes the remote method.  Test the template programs on one host until the remote method can be made successfully.

2. Add one signature at a time to the interface.  With each addition, modify the client program to invoke the added method.

3. Fill in the definition of each remote method, one at a time.  Test and thoroughly debug each newly added method before proceeding with the next one.

4. After all remote methods have been thoroughly tested,  develop the client application using an incremental approach.  With each increment, test and debug the programs. 

5. Distribute the programs on separate machines. Test and Debug.

7.10 Comparison of RMI and Socket APIs

The remote method invocation can be used in lieu of the socket API in a network application

Some of the tradeoffs between  the RMI API  and the socket API are as follows:

·        The socket API  is closely related to the operating system, hence has less execution overhead. For applications which require high performance, this may be a consideration.

·        The RMI API provides the abstraction which  eases the task  of software development. Programs developed with a higher  level of abstraction are more comprehensible and easier to debug.

·        Because it operates at a lower layer, a socket API is typically platform and language independent. The same may not be true with RMI. The Java RMI, for example, requires Java-specific run-time supports. As a result, an application implemented using Java RMI must be written in Java and can only run in Java platforms.