Distributed Objects Message Passing Vs Distributed Objects.

Click here to load reader

  • date post

    26-Mar-2015
  • Category

    Documents

  • view

    229
  • download

    0

Embed Size (px)

Transcript of Distributed Objects Message Passing Vs Distributed Objects.

  • Slide 1

Distributed Objects Message Passing Vs Distributed Objects Slide 2 Message Passing The message-passing paradigm is a natural model for distributed computing in the sense that it mimics interhuman communications. Slide 3 Message Passing It is an appropriate paradigm for network services where processes interact with each other through the exchange of messages. Slide 4 Message Passing The abstraction provided by this paradigm may not meet the needs of some complex network applications for the following reasons: Slide 5 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. Slide 6 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. Slide 7 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. Slide 8 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. Slide 9 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. Slide 10 Distributed Object The distributed object paradigm is a paradigm that provides abstractions beyond those of the message-passing model. Slide 11 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. Slide 12 Distributed Objects Each Object encapsulates State Operations Slide 13 Distributed Objects Example Consider the objects of the DatagramMessage class as shown Slide 14 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;} } Slide 15 Distributed Objects Each object instantiated from this class contains three state and three operations. Slide 16 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 Slide 17 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. Slide 18 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. Slide 19 Distributed Objects The method is executed on the remote host, and the response is sent back to the requesting process as a return value. Slide 20 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. Slide 21 Distributed Objects Slide 22 An Archetypal Distributed Object Architecture Archetypal Original Model Slide 23 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. Slide 24 ADOA In reality, there are differences because remote method invocations involve communication between independent process. Slide 25 ADOA The issues such as data marshalling and event synchornization need to be addressed. Slide 26 An Archetypal Distributed Object System OBJECT REGISTRY CLIENTSERVER Slide 27 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 Slide 28 ADOA A distributed object is provided or exported by a process, here called object server A distributed object is registered in the object registry Slide 29 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 Slide 30 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 Slide 31 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 Slide 32 Remote Procedure Calls Remote Method Invocation (RMI) has its origin in a paradigm called Remote Procedure Call. Procedural Programming predates object-oriented programming. Slide 33 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. Slide 34 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. Slide 35 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. Slide 36 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. Slide 37 Java RMI Architecture Client-Side Architecture Stub Layer Remote Reference Layer Transport Layer Server-Side Architecture Skeleton Layer Remote Reference Layer Transport Layer Slide 38 Client Side Architecture Stub Layer: A client processs remote method invocation is directed to a proxy object, known as a stub. Slide 39 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. Slide 40 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. Slide 41 Server-Side Architecture Skeleton Layer: It lies just below the application layer and serves to interact with the stub layer on the client side. Slide 42 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. Slide 43 Server Side Architecture Transport Layer: This layer is a connection oriented layer based on TCP in the TCP/IP suite. Slide 44 Object Registry The RMI registry a simple directory service, is provided with the JSDK. When active it runs on TCP port 1099 by default. Slide 45 RMI Architecture Object Registry OBJECT CLIENT STUB Remote reference Layer Transport Layer OBJECT SERVER SKELETON Remote reference Layer Transport Layer Physical path Logical path Slide 46 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 Slide 47 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. Slide 48 RMI Stub and RMI Skeleton CLIENTSTUBSKELETONREMOTE METHOD Remote method call Marshal reques Unmarshal request Execute Remote Method Marshal reply Unmarshal reply Return value TIME Slide 49 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 Slide 50 RMI API Remote Interface: Normal java interface which extends Remote class for coping up with RMI Syntax. Slide 51 Example: Import java.io.*; Public interface add extends Remote{ Public int addition(int,int); } Slide 52 Remote Method(interface) Implementation of remote interface by supplying the functionality of method Slide 53 Example: Import java.io.*; Class myadd extends UnicastRemoteObject implements add{ Public additon(int x,int y){ Return (x+y); } Slide 54 Remote Server Remote server binds the instance of implementation object to remote registry Slide 55 Example: Class myserver { Public static void main(String args[]) {myadd ma=new myadd(); Naming.bind(myobj,ma); } Slide 56 Client Remote Client Looks up the rmi registry for the object reference and fetches the reference to access remote method Slide 57 example Import java.rmi.*; Class client{ Public class client{ Public static void main(String args[]){ ref=Naming.lookup(myobj) } Slide 58 Steps for Building an RMI Algorithm for Developing the server- side software: Algorithm for Developing the Client- side software Slide 59 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. Slide 60 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 Slide 61 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 Slide 62 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. Slide 63 LOCATION OF FILES CLIENT SERVER Someinterface.class Someclient.class Someimpl_stub.class Someinterface.class Someserver.class Someimpl.class Someimpl_stub.class OBJECT CLIENT DIRECTORY OBJECT SERVER DIRECTORY Slide 64 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. Slide 65 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. Slide 66 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. Slide 67 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. Slide 68 TESTING AND DEBUGGING 5.Distribute the programs on separate machines. Test and debug Slide 69 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. Slide 70 RMI API vs SOCKET API Socket API doesnt provide abstraction for developing the application and hence difficult to debug RMI API provides abstraction for developing the application and hence easy to debug Slide 71 RMI API vs SOCKET API SOCKET API is typically platform and language independent. RMI API is platform and language dependent Slide 72 Execution Start Registry(start rmiregistry) Compile all java files(javac *.java) Generate Stub(rmic myimpl) Invoke Server(java myserver) Invoke Client(java myclient)