Distributed Objects & Remote Invocation Chapter 4: Distributed Objects & Remote Invocation

Distributed Objects & Remote Invocation Introduction Communication between distributed objects Remote procedure call Events & notification

Objectives To study communication between distributed objects and the integration of remote method invocation into a programming language. To explore the extension of the event-based programming model in order to apply to distributed event-based programs.

Introduction Introduced communication between distributed objects by means of remote method invocation (RMI) Objects that can receive remote method invocation are called remote objects ~ implement a remote interface RMI have different semantic from local call because of possibility of independent failure of invoker & invoked objects Remote procedure call ~ RMI as procedure call to object invocation

Introduction (cont). Concern with programming model in DS: Remote procedure call model: ~allow client program to call procedure in server program running in separate process and generally in different computer from client. Object based programming model: ~ allow objects in different processes to communicate with one another by means of RMI.

Introduction (cont). - extension of local method invocation Remote method invocation (RMI) - extension of local method invocation - allows an object living in one process to invoke the methods of an object living in another process

Introduction (cont). Distributed event-based programming model: ~ allow objects to subscribe to event occurring at remote objects of interest & in turn to receive notifications when such event occur. ~ events and notification provide a way for heterogeneous objects to communicate with one another asynchronously.

Figure 5.1 Middleware layers Applications Middleware layers Request reply protocol External data representation Operating System RMI, RPC and events Software that provides a programming model above the basic building blocks of processes and message passing is called middleware.

Middleware Programming Models Distributed objects & remote object invocation is model explained as illustrated by Java RMI CORBA: ~ it provides remote object invocation between a client program written in one language and a server program written in another language ~ another language commonly used is C++ Other programming models ~ remote event notification ~ remote SQL access ~ distributed transaction processing

Interface To control the possible interactions between module-explicit interface is designed for each module. Specifies the procedures and variables that can be access from other module. 2 types of interface in DS : Service interfaces ~ Used in client-server model ~ Refer to the specification of procedures offered by server and define input and output arguments. ~ Each server provides a set of procedures for client use

Fig. 5.2: CORBA IDL Example Remote interface: struct Person { string name; string place; long year; } ; interface PersonList { readonly attribute string listname; void addPerson(in Person p) ; void getPerson(in string name, out Person p); long number(); }; CORBA has a struct remote interface remote interface defines methods for RMI parameters are in, out or inout Remote interface: ~ specifies the methods of an object available for remote invocation ~ Can pass object as arguments and result of methods ~ an interface definition language (or IDL) is used to specify remote interfaces. Ex: the above in CORBA IDL. ~Java RMI have a class for Person, but CORBA has a struct Person structure (type used in arguments in the interface) in Java RMI it would have been defined as a class But CORBA may be used by non object-oriented languages e.g. C that don’t have classes. interface PersonList specifies methods available for RMI note in and out on parameters note attribute - really like another method, can get the value from it

Communication Between Distributed Object Model

Communication between Distributed Object Object based model for DS extend oriented programming language to make it apply the to distributed objects. We address communication between distributed objects by mean RMI. The material is presented under: ~ the object model ~ distributed objects ~ the distributed object model ~ design issue ~implementation ~ distributed garbage collection

Communication between Distributed Object (Cont.) Object Model Communicate with other by invoking their methods Can encapsulate(summarize) their data and code Consists of collection of interacting object : - Object references - object can be accessed via object ref. - first class values, assigned to variables, pass as arguments, and return as result. - Interfaces - definition of the signatures of a set of methods without specifying their implementation. - object provide interface if its class contains code that implement the method of that interface.

Communication between Distributed Object (Cont.) - Action - is initiated by an object invoking a method in a another object. - Invocation included additional info needed to carry out the method. - Exception - provide the clean way to deal with error without complicating the code. - throw and catches – define a block of code - Garbage collection - freeing the space occupied by object when they are no longer needed.

Communication between Distributed Object (Cont.) ~ the state of an object consist of the value of its intense value. ~ adopt the client server architecture ~ objects are managed by server ~ clients invoke method by using RMI ~ in RMI, client’s request to invoke a method of an object is sent in a message to the server managing the object. ~ execute method of object at server – result is return to client in a another message ~ object in server are allowed to become client of object in other server.

Communication between Distributed Object (Cont.) The distributed object model: ~each process contains a collection of object. ~can receive both ; local & remote invocation. RMI = method invocation between object in different process, whether in comp or not LMI = method invocation between object in same process

Fig. 5.3: Remote & local method invocations B C D E F each process contains objects, some of which can receive remote invocations, others only local invocations those that can receive remote invocations are called remote objects. - Object B and F are remote object. - Object C must have reference to object E to invoke their methods. objects need to know the remote object reference of an object in another process in order to invoke its methods. - A remote object for B must be available to A. remote interface specifies which methods can be invoked remotely. - Object B and F must have remote interface.

Communication between Distributed Object (Cont.) Remote Interface specifies the methods of an object that are available for invocation by remote objects in other processes. Interface definition languages (or IDLs) are designed to allow objects in different languages to invoke one another. Object in other process can remote only the method belong to it remote interface. The semantics of parameter passing are adjusted to suit the separation of client and remote object. Input and output parameters are used, and pointers cannot be passed.

Communication between Distributed Object (Cont.) Remote Object Object that can receive remote invocations. one that can be invoked from another process. Remote Object Reference - an identifier for a remote object - used to refer to a particular remote invocation. - Diff from local object references. can be passed as an argument or result of a remote invocation. clients need it in order to invoke remote objects. may be obtained from a binder or as the result of an RMI.

Fig. 5.4: A remote object & its remote interface Data implementation object { of methods Object in other processes can invoke only the methods that belong to it remote interface

Communication between Distributed Object (Cont.) Actions in distributed object system: Object involved in a chain of related invocations may be located in different process or different computer When invocation crossed boundary of a process or computer, RMI is used and remote references of the object must available to invoker. Object A needs to hold a remote object reference to object B.(refer to Fig 5.3) Object A may obtain a remote reference to object F from object B.(refer to Fig 5.3)

Fig. 5.5: Instantiation of remote objects Distributed application may provide remote object with method for instantiating objects which can be accessed by RMI. Example: ~ Object L contains a method for creating remote object ~ Remote invocation from method C and K could lead to instantiation of the object M and N respectively.

Communication between Distributed Object (Cont.) Garbage collection distributed object system: - Allow garbage collection of remote object - Cooperating existing local garbage collector & added module. Exception: - process contains remote object – crashed/to busy/result message lost -must be able to raise exception.

Design issues for RMI The choices of invocation semantic The level of transparency that is desirable for RMI

RMI Invocation Semantics Apply request-reply protocol. DoOperation implemented in different way to provide different delivery guarantees are: Retry request message – retransmit the request message until either a reply is received or the server is assumed to have failed Duplicate filtering – when retransmission, it filter out duplicate request at server. Retransmission of result – keep history of result message, to enable lost result to be retransmitted without executing the operation at server.

Fig. 5.6: Invocation Semantics Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Yes Not applicable Retransmit reply At-most-once At-least-once Maybe Local invocations are executed exactly once The Request-reply protocol can apply fault-tolerance measures

Invocation Semantics: Failure Model Maybe, At-least-once and At-most-once can suffer from crash failures when the server containing the remote object fails. Maybe - remote method my be executed once or not at all - arise when none of the fault tolerance measures is applied - if no reply, the client does not know if method was executed or not ~ omission failures if the invocation or result message is lost - no retries after timeout ~ 2 situation (invocation message lost, method not executed or method executed, result message lost) give impact to crash failure. - use fro apps which occasional failed invocation acceptable

Invocation Semantic: Failure Model At-least-once - the client gets a result (and the method was executed at least once) or an exception (no result) - suffer from arbitrary failures. If the invocation message is retransmitted, the remote object may execute the method more than once, possibly causing wrong values to be stored or returned. - if idempotent operations are used, arbitrary failures will not occur - idempotent operations, one that can be performed repeatedly with the same effect although it have perform exactly once. - use in Sun RPC At-most-once - the client gets a result (and the method was executed exactly once) or an exception (instead of a result, in which case, the method was executed once or not at all) - achieved by using all fault tolerance measure ~ prevent arbitrary failure – ensure each RMI method execute only once. - applied in JAVA RMI and CORBA, but CORBA allows maybe – requested method that do return result.

Call semantics cannot be `exactly once'. The semantics achieved (e. g Call semantics cannot be `exactly once'. The semantics achieved (e.g. `at-most-once') depends on the approach to dealing with failures of processes and communication.

Transparency originator aimed to make RPC same as LPC Hide marshalling, message passing, task of locating and contacting a remote object RMI more vulnerable to failure than local invocation .Why? RMI latency is greater than local- to minimize, caller able to abort RPC that taking a lot of time. To differentiate the syntax of RMI with LMI

Implementation of RMI Roles of components that involve in implementation of RMI

Implementation of RMI(cont.) Communication Module - Define the client and the server - Use only first 3 items – specify msg type, requestID and remote reference. - Responsible to provide a specified invocation semantics Remote reference module - responsible to translate between local and remote object references - create remote object reference - each process have remote object table

Implementation of RMI(cont.) Servant - an instance of class which provide the body of remote object - handles the remote request pass and live within a server process - deleted after being used. The RMI software - consist a layer of software between apps level object- communication- remote reference modules - Proxy ~ make RMI transparent to client- behave like local object and hide details - Dispatcher ~ receive request msg from comm. module ~ use methodID to select appropriate method in skeleton

Fig. 5.7: The role of proxy & skeleton in remote method invocation object A object B skeleton Request proxy for B Reply Communication Remote Remote reference module reference module for B’s class & dispatcher remote client server Dispatcher - gets request from communication module and invokes method in skeleton (using methodID in message). Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests & unmarshals results.Forward request Skeleton - implements methods in remote interface. Unmarshals requests and marshals results. Invokes method in remote object. carries out Request-reply protocol translates between local and remote object references and creates remote object references. Uses remote object table describe animation - First just shows the figure 5.6 then bring in descriptions of communication and remote reference modules then text on RMI software then proxy, skeleton and dispatcher RMI software - between application level objects &communication & remote reference modules

Distributed Garbage Collection To ensure a local or remote reference to an object remain exist if still in use As soon no object any longer hold a reference to it, the object will be collected and memory uses is recovered.

Remote Procedure Call Very similar to remote method invocation Generally implemented in request-reply protocol Client program calls a procedure in another program running in server process Its service interface have lack of ability to create new instance of object – do not support remote object references Implemented over request –reply protocol- same content but object reference field is omitted(lost).

Remote Procedure Call Client Stub procedure - Similar to proxy method - Behave like local procedure to client - Marshall procedure identifier and the argument in request msg Server stub procedure - similar to skeleton method - unmarshals argument in the request msg, call coresponding service procedure and marshal return value for reply msg

Fig. 5.8: Role of client & server stub procedures in RPC in the context of a procedural language Request Reply Communication module dispatcher service client stub server stub procedure client process server process program

Events And Notification Distributed event-based systems use the publish-subscribe paradigm event-generating object publishes type of events that will be available for other objects. - Object that receive notification of publishes event subscribe the types of their interest event. 2 main characteristics: i) heterogeneous; ii) asynchronous useful for communication between heterogeneous components their asynchronous nature allows publishers and subscribers to be decoupled. Generally implemented in request-reply protocol

Fig. 5.10: Dealing Room System Dealer’s computer Information provider Dealer External source Notification The figure shows an example of distributed event-based systems.

Dealing Room System Allows user to see the latest info about the market price Market price are represent by an object with instance variables. Info have been updated and collected by information provider. 2 different task create here : i. - information provider update to the appropriate stock object - update to stock object regards as an event - notify all the dealer who have subscribe - for each external source there will be separate info provider process ii. - dealer create object to represent named stock - local object subscribe to the relevant info provider object - receive info sent to it in notification and display to user

Fig. 5.11: Architecture for distributed event notification subscriber observer object of interest Event service 3. 1. 2. notification

Distributed event notification The object of interest – an object that experience change of state Event – occur at an object of interest as the result of completion of method execution Notification – an object that contain info about an event Subscriber - an object that subscribe to some type of event in another object. Observer object – to decouple an object of interest of its subscriber. Publisher – declare it will generate notification of particular types of an event. can be object of interest or an observer. An object of interest inside the event service without an observer. It send notifications directly to the subscribers. inside the event service with an observer. The object interest send notification via observer. outside the an event service. observer queries the object of interest to discover when event occur and observer sends notification