Message Passing Vs Distributed Objects

Message Passing The message-passing paradigm is a natural model for distributed computing in the sense that it mimics interhuman communications.

Message Passing It is an appropriate paradigm for network services where processes interact with each other through the exchange of messages.

Message Passing The abstraction provided by this paradigm may not meet the needs of some complex network applications for the following reasons:

Message Passing Basic message passing requires that the participating processes be tightly coupled. Throughout their interaction, the processes must be in direct communication with each other.

Message Passing If the communication is lost between the processes the collaboration fails. Example: Consider a session of the Echo protocol If the communication between the client and the server is disrupted, the session cannot continue.

Message Passing The message-passing paradigm is data-oriented. Each message contains data marshaled in a mutually agreed upon format, and each message is interpreted as a request or response according to the protocol.

Message Passing Example: Echo Protocol The receiving of a message from a process p elicits in the Echo server this action: a message containing the same data is sent to p.

Message Passing The data orientation of the paradigm is appropriate for network services and simple network applications It is inadequate for complex applications involving large mix of requests and responses.

Distributed Object The distributed object paradigm is a paradigm that provides abstractions beyond those of the message-passing model.

Distributed Objects The paradigm is based on objects that exists in a distributed system. In Object-oriented programming objects are used to represent an entity that is significant to an application.

Distributed Objects Each Object encapsulates State Operations

Distributed Objects Example Consider the objects of the DatagramMessage class as shown

Import java.net.*; public class DatagramMessage { private String message; private InetAddress senderAddress; private int senderport; public void putVal(String message,InetAddress addr, int port) { this.message = message; this.senderAddress=addr; this.senderPort =port; } public String getMessage() { return this.message; } public InetAddress getAddress() { return this.senderAddress; } public int getPort() { return this.senderport; }

Distributed Objects Each object instantiated from this class contains three state and three operations.

Distributed Objects Local objects are objects whose methods can only be invoked by a local process. A process that runs on the same computer on which the object exists

Distributed Objects 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.

Distributed Objects In a distributed object paradigm, network resources are represented by distributed objects. To request service from a network resources, a process invokes one of its operations or methods, passing data as parameters to the method.

Distributed Objects The method is executed on the remote host, and the response is sent back to the requesting process as a return value.

Distributed Objects Compared to the message-passing paradigm, the distributed objects paradigm is action-oriented. The focus is on the invocation of the operations, while the data passed takes on a secondary role.

Distributed Objects

An Archetypal Distributed Object Architecture Original Model

ADOA The task of a distributed object system is to minimize the programming differences between remote method invocations and local invocations, Allowing remote methods to be invoked in an application using syntax similar to local method invocations.

ADOA In reality, there are differences because remote method invocations involve communication between independent process.

ADOA The issues such as data marshalling and event synchornization need to be addressed.

An Archetypal Distributed Object System

An Archetypal Distributed Object System Object Registry OBJECT CLIENT CLIENT PROXY RUN-TIME SUPPORT NETWORK SUPPORT OBJECT SERVER SERVER PROXY RUN-TIME SUPPORT NETWORK SUPPORT PHYSICAL DATA PATH LOGICAL DATA PATH

ADOA A distributed object is provided or exported by a process, here called object server A distributed object is registered in the object registry

ADOA A distributed object is accessed by the client process using object client The object client looks up the registry for a reference to the object. This reference is used by the object client to make calls to the methods of remote object

ADOA Logically the object client makes a call directly to a remote method of object server. Physically the client is handled by a software components called Client proxy - Object on behalf of client Run time support - data marshalling Network support – data transmission

Distributed Object Systems The distributed object paradigm has been widely adopted in distributed applications, among the most well known of such toolkits are: RMI CORBA DCOM SOAP

Remote Procedure Calls Remote Method Invocation (RMI) has its origin in a paradigm called Remote Procedure Call. Procedural Programming predates object-oriented programming.

Remote Procedure Calls Remote Procedure call model, a procedure call or a function call is made by one process to another, possibly residing in a remote system, with data passed as arguments.

Remote method Invocation Remote Method Invocation(RMI) is an object-oriented implementation of Remote Procedure Call model. It is an API for java programs only.

Remoted Method Invocation 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.

Remote Method Invocation A remote object is declared with a remote interface (in java). The remote interface is implemented by the object server. An object client accesses the object by invoking its methods.

Java RMI Architecture Client-Side Architecture Stub Layer Remote Reference Layer Transport Layer Server-Side Architecture Skeleton Layer

Client Side Architecture Stub Layer: A client process’s remote method invocation is directed to a proxy object, known as a stub.

Client Side Architecture Remote Reference Layer: Interprets and manages references made from clients to remote service objects and issues the IPC operations to next layer.

Client Side Architecture Transport Layer: It is TCP based and therefore connection-oriented. This layer and the rest of the network architecture carry out the IPC.

Server-Side Architecture Skeleton Layer: It lies just below the application layer and serves to interact with the stub layer on the client side.

Server-Side Architecture Remote Reference Layer: This layer manages and transforms the remote reference originating from the client to local references that are understandable by skeleton layer.

Server Side Architecture Transport Layer: This layer is a connection oriented layer based on TCP in the TCP/IP suite.

Object Registry The RMI registry a simple directory service, is provided with the JSDK. When active it runs on TCP port 1099 by default.

RMI Architecture Object Registry OBJECT CLIENT STUB Remote reference Layer Transport Layer OBJECT SERVER SKELETON Remote reference Layer Transport Layer Physical path Logical path

RMI Architecture Logically, from the point of view the software developer, the remote method invocation issued in a client program interact directly with the remote objects in a server program

RMI Architecture Physically, the remote method invocation are transformed to calls to the stub and skeleton at runtime, resulting in data transmission across the network.

RMI Stub and RMI Skeleton CLIENT STUB SKELETON REMOTE METHOD Remote method call Marshal reques Unmarshal request TIME Execute Remote Method Marshal reply Unmarshal reply Return value

Example of RMI Create a Remote Interface Create a Remote Implementation of Interface Create a Server to access instance of remote method(interface) Create a Client to access a remote method

RMI API Remote Interface: Normal java interface which extends Remote class for coping up with RMI Syntax.

Example: Import java.io.*; Public interface add extends Remote{ Public int addition(int,int); }

Remote Method(interface) Implementation of remote interface by supplying the functionality of method

Example: Import java.io.*; Class myadd extends UnicastRemoteObject implements add{ Public additon(int x,int y){ Return (x+y); }

Remote Server Remote server binds the instance of implementation object to remote registry

Example: Class myserver { Public static void main(String args[]) { myadd ma=new myadd(); Naming.bind(“myobj”,ma); }

Client Remote Client Looks up the rmi registry for the object reference and fetches the reference to access remote method

example Import java.rmi.*; Class client{ Public class client{ Public static void main(String args[]){ ref=Naming.lookup(“myobj”) }

Steps for Building an RMI Algorithm for Developing the server-side software: Algorithm for Developing the Client-side software

Algorithm Server-side 1. Open a directory for all the files to be generated for this application 2. Specify the remote server interface in someinterface.java and compile it. 3. Implement the interface in someimpl.java and compile it.

Algorithm Server-side 4. Use the RMI compiler rmic to process the implemntation class and generate the stub and skeleton file for the remote object 5.Create the object server program someserver.java and compile it 6. Activate the object server Java someserver

Algorithm for Client-side 1. Open a directory for all the files to be generated for this application 2. Obtain a copy of the remote interface class file 3. Obtain a copy of the stub file for the implementation of the interface someimple_stub.class

Algorithm for Client-side 4. Develop the client program someclient.java and compile it to generate the client class. 5. Activate the client Java someclient.

LOCATION OF FILES CLIENT SERVER OBJECT SERVER DIRECTORY OBJECT CLIENT DIRECTORY Someinterface.class Someinterface.class Someserver.class Someclient.class Someimpl.class Someimpl_stub.class Someimpl_stub.class

TESTING AND DEBUGGING 1. Build a template for a minimal RMI program. start with a remote interface containing single method signature. Its implementation using stub A server program that exports the object A client program with just enough code that invokes the remote method.

TESTING AND DEBUGGING 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.

TESTING AND DEBUGGING 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.

TESTING AND DEBUGGING 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.

TESTING AND DEBUGGING 5. Distribute the programs on separate machines. Test and debug

RMI API vs SOCKET API Socket API works closely with the operating system and hence has less execution overhead. RMI API requires additional software support, including proxies and directory service, which inevitably incur run-time overhead.

RMI API vs SOCKET API Socket API doesn’t provide abstraction for developing the application and hence difficult to debug RMI API provides abstraction for developing the application and hence easy to debug

RMI API vs SOCKET API SOCKET API is typically platform and language independent. RMI API is platform and language dependent

Execution Start Registry(start rmiregistry) Compile all java files(javac *.java) Generate Stub(rmic myimpl) Invoke Server(java myserver) Invoke Client(java myclient)