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

3

Runtime structure of RPC (recap)

client Request Reply Communication Communication module module dispatcher service client stub server stub procedure procedure client process server process procedure program

Stub procedures marshal and unmarshal parameters. Client stub marshals input parameters (and unmarshals return paramter). Server stub unmarshals input parameters and marshals return parameter.

4

Passing Parameters (recap)

2-8

parameter marshaling

Steps involved in doing remote computation through RPC

5

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!

7

Writing a Client and a Server

2-14 The steps in writing a client and a server in DCE RPC.

8

Binding a Client to a Server

Semantic options for performing RPC:  At-most-once operations  Idempotent operations

9

Types of Communication

Viewing middleware as an intermediate (distributed) service in application-level communication.

10

Asynchronous RPC (1)

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)

• ne-way RPC (not even receipt confirmed)

2-12

11

Asynchronous RPC (2)

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)

• ne-way RPC (not even receipt confirmed)

(c)

12

Asynchronous RPC (3)

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

14

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!

Lecture 3: Communication (Part 2)

 Remote Procedure Call (cont’d)  Remote Method Invocation  Message-oriented communication  Stream communication

16

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.

17

Distributed Objects

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

18

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,...)

19

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

20

Binding a Client to an Object

a) Example with implicit binding using only global references b) Example with explicit binding using global and local references

Distr_object* obj_ref; //Declare a systemwide object reference

• bj_ref = …

; // Initialize the reference to a distributed object

• bj_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

• bj_ref = …

; //Initialize the reference to a distributed object

• bj_ptr = bind(obj_ref);

//Explicitly bind and obtain a pointer to the local proxy

• bj_ptr -> do_something();

//Invoke a method on the local proxy (b)

21

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)

22

CORBA Object References

The organization of an IOR with specific information for IIOP.

23

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

24

Parameter Passing

2-18

The situation when passing an object by reference or by value.

26

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)

27

Java RMI Interface

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

28

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...."); } }

29

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

31

Java RMI Behind the Scenes

Client Security Manager Stub Server Security Manager Naming 1 2 3 4 5 6 7 8 9

32

Summary of Distributed Objects

 Distributed objects support invocation of remote objects transparently  A globally unique “address” is needed as an

• bject 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

Lecture 3: Communication (Part 2)

 Remote Procedure Call (cont’d)  Remote Method Invocation  Message-oriented communication  Stream communication

34

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

• r persistent, synchronous or asynchronous

35

Types of Communication

Viewing middleware as an intermediate (distributed) service in application-level communication.

36

Persistent vs. Transient

 Persistent communication: Message is stored in the communication system.  Transient communication: Message is stored

• nly as long as sender an receiver are

executing

37

Synchronous vs. Asynchronous

 Asynchronous: Sender continues immediately after submission  Synchonous: Sender is blocked until:

 Buffer at receiving host  Delivered to receiver  Receiver has processed

  various combinations

38

Persistence and Synchronicity

a) Persistent asynchronous communication b) Persistent synchronous communication

2-22.1

39

Transience and Synchronicity (1)

c) Transient asynchronous communication d) Receipt-based transient synchronous communication

2-22.2

40

Transience and Synchronicity (2)

e) Delivery-based transient synchronous communication at message delivery f) Response-based transient synchronous communication

41

Discussion

 RPC and RMI start from (f) and may provide weaker types  Message passing systems start from (c) and may provide stronger types  Persistent communication for large-scale dispersed systems required (access restrictions or temporarily out of service): Slower solutions for failure masking and recovery are acceptable!   in practice, all types are needed!

45

Object-Based Messaging (1)

CORBA’s callback model for asynchronous method invocation.

46

Object-Based Messaging (2)

CORBA’s polling model for asynchronous method invocation.

47

Message-Queuing Model

 Four combinations for loosely-coupled communications using queues (for persistent communication).  (email is a message queuing system.)

48

Message-Queuing Model Primitives

Install a handler to be called when a message is put into the specified queue. Notify Check a specified queue for messages, and remove the first. Never block. Poll Block until the specified queue is nonempty, and remove the first message Get Append a message to a specified queue Put

Meaning Primitive

Basic interface to a queue in a message-queuing system.

49

Architecture of Message-Queuing

The relationship between queue-level addressing and network-level addressing.

50

Routing in a Message-Queuing System

The general organization of a message-queuing system with routers/relays: topology, multicasting and secondary processing.

52

Message Oriented Middleware

 MOM (message queuing systems)  Persistent (asynchronous) communication  Intermediate term storage capacity for messages in the communication network  May take minutes (not ms)  Basic idea: insert message into queue  Only guarantee: recipient’s queue!   loosely-coupled systems and EAI

53

Message Format

 Enterprise Application Integration (Legacy systems)  Each approach to replace N technologies by one technology usually ends with N+1 technologies   learn to live with different formats and provide the means to make conversion as easy as possible

54

Message Brokers

The general organization of a message broker in a message- queuing system. Message broker can “adapt” format of messages before delivering them.

Lecture 3: Communication (Part 2)

 Remote Procedure Call (cont’d)  Remote Method Invocation  Message-oriented communication  Stream communication

60

Stream-oriented communication

 Multimedia applications are increasingly popular  Continuous media (e.g. audio and video) impose new requirements on communication

 Temporal order of delivery  Timeliness of delivery (time-dependent information)  Regularity (constancy) of delivery times (low jitter)

 The stream abstraction captures these requirements

61

Stream Definitions

 Continuous vs. discrete representation media  Data stream: sequence  Transmission:

 Asynchronous  Synchronous  Isochronous

 Simple vs. complex stream (substreams)  synchronization issues

62

Data Stream

A general architecture for streaming stored multimedia data over a network.

66

Streams and Quality of Service

 Properties for Quality of Service:  The required bit rate at which data should be transported.  The maximum delay until a session has been set up  The maximum end-to-end delay .  The maximum delay variance, or jitter.  The maximum round-trip delay.

68

Enforcing QoS (1)

Using a buffer to reduce jitter.

69

Enforcing QoS (2)

The effect of packet loss in (a) non interleaved transmission and (b) interleaved transmission.

71

Setting Up a Stream

The basic organization of ReSerVation Protocol for resource reservation in a distributed system.

74

Summary Communication

 Communication is the distinguishing characteristic of distributed applications  Communication mechanisms may be explicit or implicit  Different models of communication exist  Synchronization and persistence  Discrete and continuous media have distinct communication requirements  Remote procedures, distributed objects, message queues, and streams are just four types of abstractions that can be used