Verteilte Systeme (Distributed Systems) Karl M. Gschka - PowerPoint PPT Presentation

Verteilte Systeme (Distributed Systems) Karl M. Göschka Karl.Goeschka@tuwien.ac.at http://www.infosys.tuwien.ac.at/teaching/courses/ VerteilteSysteme/

Lecture 3: Communication (Part 2)  Remote Procedure Call (cont’d)  Remote Method Invocation  Message-oriented communication  Stream communication

Runtime structure of RPC (recap) client process server process Request Reply client stub server stub procedure procedure service client Communication Communication program procedure dispatcher module module Stub procedures marshal and unmarshal parameters. Client stub marshals input parameters (and unmarshals return paramter). Server stub unmarshals input parameters and marshals return parameter. 3

Passing Parameters (recap) parameter marshaling 2-8 Steps involved in doing remote computation through RPC 4

Interface Definition Language (recap)  An IDL supports the definition of procedures that may be called remotely  It provides a set of “universal” types  IDL compiler generates client and server header files and stubs  Client code includes client header file and links to client stub  Server code includes server header and links to server stub  Caller and callee need not be in same language! 5

Writing a Client and a Server 2-14 The steps in writing a client and a server in DCE RPC. 7

Binding a Client to a Server Semantic options for performing RPC:  At-most-once operations  Idempotent operations 8

Types of Communication Viewing middleware as an intermediate (distributed) service in application-level communication. 9

Asynchronous RPC (1) 2-12 a) The interconnection between client and server in a traditional (synchronous, blocking) RPC b) The interaction using asynchronous (non-blocking) RPC (e.g., when no reply needed) c) one-way RPC (not even receipt confirmed) 10

Asynchronous RPC (2) (c) a) The interconnection between client and server in a traditional RPC b) The interaction using asynchronous (non-blocking) RPC (e.g., when no reply needed) c) one-way RPC (not even receipt confirmed) 11

Asynchronous RPC (3) 2-13 A client and server interacting through two asynchronous RPCs (deferred synchronous RPC) 12

Summary of RPC  RPC is an end-to-end service implemented on top of transport layers; it allows a procedure to be called in a different process  An interface definition language supports the definition of interfaces and the generation of stubs to be used by clients and servers  RPC is supported by a directory service at runtime to register and locate remote procedures (binding)  RPC is a form of one-to-one communication  Problem with passing parameters by reference! 14

Lecture 3: Communication (Part 2)  Remote Procedure Call (cont’d)  Remote Method Invocation  Message-oriented communication  Stream communication

Distributed objects  Extend OO model for remote references and invocation (e.g. obj.meth() where obj is remote)  Objects reside around the network (not on a single system)  Object references may refer to local and remote objects  Calls may be made to methods of local or remote objects. 16

Distributed Objects 2-16 Common organization of a remote object with client-side proxy. 17

Compile-time vs. run-time objects  Compile-time objects:  Instance of a class (type + interface)  Easy, but language dependent  Run-time objects  Constructing distributed objects during run-time  Multiple languages  Objects are only defined in terms of their interface   Object adapter (wrapper)  Interface implementation can then be registered at an adapter (e.g., C-lib plus data file,...) 18

Persistent vs. transient objects  Persistent objects:  Continues to exist independent of server processes  Object state is stored (serialized) to stable storage (file, database)  Transient objects  Exists only as long as the server that manages it  Some controversy about persistent objects and (more recently) component persistence  Object seems to be wrong granularity to manage persistence 19

Binding a Client to an Object Distr_object* obj_ref; //Declare a systemwide object reference obj_ref = … ; // Initialize the reference to a distributed object obj_ref-> do_something(); // Implicitly bind and invoke a method (a) Distr_object* obj_ref; //Declare a systemwide object reference Local_object* obj_ptr; //Declare a pointer to local objects obj_ref = … ; //Initialize the reference to a distributed object obj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxy obj_ptr -> do_something(); //Invoke a method on the local proxy (b) a) Example with implicit binding using only global references b) Example with explicit binding using global and local references 20

Implementation of object references  Network address + endpoint (+ object)  Network address + server ID (daemon)  Location server + unique server ID  Plus information for:  Binding protocol, flow control, error handling  Paramter marshalling (format, data)  Implementation handle  Reference to a complete proxy implementation dynamically loaded during binding  Object specific proxies, but more effort  Reflection (and dynamic class loading) 21

CORBA Object References The organization of an IOR with specific information for IIOP. 22

Static vs. dynamic RMI  Static invocation  Predefined interface definition (IDL or programming language)  Interface change  client re-compiled  myobject.doSomething(in1, in2, out1, out2)  Dynamic invocation  Compose the method invocation at run-time  invoke (object, method, inparams, outparams)  Needs lookup for method-name (repository or reflection)  Applications: object browser, run-time inspection, batch processing, frameworks 23

Parameter Passing 2-18 The situation when passing an object by reference or by value. 24

Java RMI  Integrated into the language  interface construct used to define remote objects  remote interface indicates remotely callable object  Objects are passed between JVMs  Marshaling = serialization (homogeneous)  rmic = IDL compiler  rmid = daemon listening for rmi incoming calls  rmiregistry ~ directory service (supports binding)  Similar to CORBA but supports only one language  Subtle differences local/remote: Cloning (server only), synchronize (proxy only)  Remote object passed by reference (refers to proxy implementation) (implementation handle) (  only one language + class loader facility) 26

Java RMI Interface // MyService Interface import java.rmi.*; public interface MyService extends java.rmi.Remote { public int mymethod (int param) throws RemoteException; } 27

Java RMI Server // MyServiceServer import java.rmi.*; import java.rmi.server.*; public class MyServiceServer extends UnicastRemoteObject implements MyService { public MyServiceServer () throws RemoteException { super(); } public Integer mymethod (int param) throws RemoteException { return (param); } public static void main (String args[]) throws Exception { if (System.getSecurityManager() == null) System.setSecurityManager ( new RMISecurityManager() ); MyServiceServer svr = new MyServiceServer(); //create server instance Naming.bind ("MyService", svr); //register with naming service (bind with registry) System.out.println ("Service bound...."); } } 28

Java RMI Client // MyServiceClient import java.rmi.*; import java.rmi.Naming; import java.io.*; public class MyServiceClient { public static void main(String args[]) throws Exception { if (System.getSecurityManager() == null) { System.setSecurityManager (new RMISecurityManager()); } MyService service = (MyService) Naming.lookup ("rmi://my.host.edu/MyService"); //obtain reference System.out.println (service.mymethod(17)); } } Implicit binding 29

Java RMI Behind the Scenes Security Security Manager Naming Client Stub Server Manager 1 2 3 4 5 6 7 8 9 31

Summary of Distributed Objects  Distributed objects support invocation of remote objects transparently  A globally unique “address” is needed as an object reference  A “directory service” is needed to help find and bind remote objects  Parameters may be passed to remote methods by value or by reference 32

Lecture 3: Communication (Part 2)  Remote Procedure Call (cont’d)  Remote Method Invocation  Message-oriented communication  Stream communication

Message oriented communication  RPC and DO extend familiar (single-process) programming model to the distributed environment. They make communication transparent or implicit.  Message oriented middleware (MOM) introduces a different model for programming distributed applications, based on explicit communication.  Communication mechanisms may be transient or persistent, synchronous or asynchronous 34

Types of Communication Viewing middleware as an intermediate (distributed) service in application-level communication. 35

Persistent vs. Transient  Persistent communication: Message is stored in the communication system.  Transient communication: Message is stored only as long as sender an receiver are executing 36