Presentation is loading. Please wait.

Presentation is loading. Please wait.

Message Passing Vs Distributed Objects

Similar presentations

Presentation on theme: "Message Passing Vs Distributed Objects"— Presentation transcript:

1 Message Passing Vs Distributed Objects

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

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

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

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.

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.

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.

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.

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.

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

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.

12 Distributed Objects Each Object encapsulates State Operations

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

14 Import*; 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; }

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

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

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.

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.

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.

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.

21 Distributed Objects

22 An Archetypal Distributed Object Architecture
Original Model

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.

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

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

26 An Archetypal Distributed Object System

27 An Archetypal Distributed Object System

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

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

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

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

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

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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

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.

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

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

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.

48 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

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

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

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

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

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

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

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

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

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

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

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 and compile it. 3. Implement the interface in and compile it.

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 and compile it 6. Activate the object server Java someserver

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

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

OBJECT CLIENT DIRECTORY Someinterface.class Someinterface.class Someserver.class Someclient.class Someimpl.class Someimpl_stub.class Someimpl_stub.class

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.

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.

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.

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.

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

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.

70 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

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

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

Download ppt "Message Passing Vs Distributed Objects"

Similar presentations

Ads by Google