Chapter 5: Distributed objects and remote invocation Introduction Remote procedure call Events and notifications

Introduction Programs need to be able to invoke operations in other processes, often running in different computers. Programming models: Remote procedure call model : it was the extension of the conventional procedure call model and it allows the client programs to call procedure in server programs running in separate processes. Object-based programming model : was extended to allow objects in different processes to communicate with one another by means of RMI Event-based programming model: it allows objects to receive notification of the event at other objects in which they have registered interest.

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 5.1 Middleware layers Applications Middleware layers Request reply protocol External data representation Operating System RMI, RPC and events

Middleware: software that provides a programming model above the basic building blocks of processes and messages passing. The remote method invocation abstraction is based on the request-replay protocol The middleware provide location transparency and independence from : the details of communication protocols Operating systems Computer hardware Programming languages Some forms of middleware allow the separate components to be written in different programming languages. Introduction (con.)

Interfaces: Interfaces in distributed systems The modules in a distributed program can run in separate processes It is not possible for a module running in one process to access the variables in a module in another process. The interface of a module that is intended for RPC or RMI cannot specify direct access to variables. The differences between calling local procedure and remote procedure are shown in: Parameter passing “call by reference and call by value “ Pointers Introduction (con.)

Example void by_value(int a){ a+=10; } void by_ref(int *a){ (*a)+=10; } int main() { int x=40; by_value(x); //x==40 by_ref(&x); //x==50 return 0; }

The interfaces used in the original client-server model for RPC and in the distributed object model for RMI: Service interface : oeach server provides a set of procedures that are available for use by clients. oIt is used : To refer to the specification of the procedures offered by a server Defining the types of the input and output arguments. Remote interface: oSpecifies the methods of an object that are available for invocation by objects in other processes oDefining the types of the input and output arguments of them Introduction (con.)

The difference between service interface and remote interface: oIn remote interface, the methods can pass objects as arguments and results of methods oThe references to remote objects may also be passed Interface definition languages Are designed to allow objects implemented in different languages to invoke one another It provides a notion for defining interfaces in which each of the parameters of a method may be described as for input or output in addition to having its type specified Introduction (con.)

Remote procedure call When client program calls a procedure in another program running in a server process It is possible to have a chain of RPC (when?) A server process defines in its service interface the procedures that are available for client to be called This service is like a single remote object which has state and methods RPC does not support remote object reference

RPC ( con.) Invocation semantics: Retry request message Duplicate filtering Retransmission of results At-least-once invocation semantics : the method executed at least once or no result was received : Omission failure Arbitrary failure What are idempotent and non-idempotent operations? At-most-once invocation semantics : the method executed exactly once or no result was received

Figure 4.16 Request-reply message structure messageType requestId methodId arguments int (0=Request, 1= Reply) int int or Method array of bytes

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 Figure 5.8 Role of client and server stub procedures in RPC in the context of a procedural language client Request Reply Communication module dispatcher service client stub server stub procedure client processserver process procedure program

In RPC, the client that accessed a service includes one stub procedure for each procedure in the service interface Client Stub procedure in RPC=proxy method in RMI Client Stub procedure marshals the procedure identifier and arguments into a request message Unmarshals the results What is the proxy? The role of the proxy is to make remote method invocation transparent to client by behaving like a local object to the invoker, but instead of executing an invocation it forwards it in a message toa remote object RPC ( con.)

In RPC, the server contains the following elements : Dispatcher: selects one stub procedure according to procedure identifier Server stub procedure = skeleton method in RMI Unmarshaled the arguments in the request Calls the corresponding service procedure Marshals the return values for the replay message Service procedures: implement the procedures in the service interface The client and server stub procedures and the dispatcher can be generated by an interface compiler from the interface definition of the service RPC ( con.)

RPC jan.newmarch.name

RPCRMI NO remote object referenceRemote object reference Client stubProxy method Server stubSkeleton method Procedural programmingObject oriented programming languages RPC ( con.)

Case study: Sun RPC It was designed for client-server communication in the Sun NFS. RPC can be used over TCP or UDP. When using UDP, the length of the messages is restricted It uses at-least-once call semantics It provides an interface language called XDR and an interface compiler called rpcgen

linuxjournal.com Sun RPC

techpubs.sgi.com Sun RPC

Sun XDR: It was designed for specifying external data representation It may be used to define a service interface for Sun RPC by specifying a set of procedure definitions together with supporting type definitions. In Sun XDR, both program and version number are passed in the request message. A procedure definition specifies a procedure signature and procedure number. Only single parameter is allowed. The output parameters of a procedure are returned via a single result. Procedure signature = result type + procedure name + input parameters type

The interface compiler rpcgen can be used to generate the following form of interface definition: Client stub procedures Server main procedures Server dispatcher Server stub procedures XDR marshalling and unmarshalling procedures Sun RPC

Binding Sun RPC runs a local binding service called the port mapper. Each instance of a port mapper records the program number, version number and port number in use by each service running locally Sun RPC docs.oracle.co m

Authentication The request message contains the credentials of the user running the client program Several different authentication protocols can be supported. These include: None UNIX style “ uid and gid of the user” a shared key Kerberos style of authentication Sun RPC vorlesungen.uni- osnabrueck.de

Events and notifications What is the idea behind the use of events? one object react to a change occurring in another object Example: Manipulating a button with the mouse or entering text in a text box via the keyboard is an event which is followed by a notification to the objects that are responsible for displaying a view of current state.

More examples: Communicate a shape added to a drawing Modification to a document Person has entered or left room Piece of equipment or an electronically tagged book is at a new location Events and notifications

Publish-subscribe paradigm : The generator publishes the type of events that it will make available for observation by other objects The receivers subscribe to the types of events that are of interest to them The receivers receive notification of events when they occur Events and notifications

Events: Are the action performed on objects Different event types may refer to the different methods executed by the object of interest. Notifications: Objects that represent events. They may be: Stored Sent in message Queried Events and notifications

Distributed event-based systems They extend the local event model by allowing multiple objects at different locations to be notified of event taking place at an object. They have two main characteristics: Heterogeneous components in a DS that were not designed to interoperate can be made to work together Asynchronous prevent publishers needing to synchronize with subscribers Publishers and subscriber need to be decoupled Events and notifications

Mushroom: Is a distributed event-based system designed to support collaborative work, in which the user interface displays objects representing users and information objects such as documents and notepads within shared workspaces called network places. The state of each place is replicated at the computers of users currently in that place Events are used to describe changes to objects and to a user’s focus of interest. Events and notifications

Simple dealing room system: Its task is to allow dealers using computers to see the latest information about the market prices of the stocks they deal in. It could be modelled by processes with two different tasks: An information provider process A dealer process Events and notifications genuwiki.genuco.c om

An information provider process It receives new trading information from a single external source It applies the information to the appropriate stock object Each of the updates to a stock object is regarded as an event The stock object notifies all of the dealers who have subscribed to the corresponding stock There is a separate information provider process for each external source Events and notifications

A dealer process It creates an object to represent each named stock that the user asks to have displayed The local object subscribes to the object representing that stock at the relevant information provider The local object then receives all the information sent to it in notification and displays it to the user. Events and notifications

Figure 5.10 Dealing room system Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005

Events and notifications Event types An event source can generate events of one ore more different types Each event has attributes such as : name or identifier of the generator, the operation, parameters and the time ( or seq#) Types and attributes are used in subscribing and notifications. Attributes example: Name of stock Current price Least rise or fall

The participants in distributed event notification The object of interest its changes of state might be of interest to other objects Event An event occurs at an object of interest as the completion of a method execution Notification an object that contains information about an event ( types and attributes) Subscriber an object that has subscribed to some type of events in another object Observer objects the main purpose is to decouple an object of interest from its subscribers. Avoid over-complicating the object of interest. Publisher an object that declares that it will generate notifications of particular types of event. May be an object of interest or an observer.

Figure 5.11 Architecture for distributed event notification Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 © Pearson Education 2005 subscriberobserverobject of interest Event service object of interest observer subscriber notification

Delivery semantics: It depends on the requirements of applications Application does not need reliable delivery : later state of a player in an internet game Applications have stronger requirements ( reliable delivery): dealing room application Applications have real-time requirements : a nuclear power station or a hospital patient monitor The participants in distributed event notification

Roles of observers: Forwarding send notifications to subscribers on behalf of one or more objects of interests Filtering of notifications according to some predicate Patterns of events Notification mailboxes notification be delayed until subscriber being ready to receive The participants in distributed event notification

Jini distributed event specification The main objects are: Event generator : is an object that allows other objects to subscribe to its events and generates notification Remote event listener : is an object that can receive notifications Remote event : is an object that is passed by value to remote event listener (notification) Third-party agents interpose between an object of interest and a subscriber equivalent of observer