1. IS473 Distributed Systems CHAPTER 5 Distributed Objects & Remote Invocation

2. Dr. Almetwally Mostafa2 OUTLINE Applications Middleware layers request-reply protocol marshalling and external data representation UDP and TCP This chapter RMI, RPC, and events

3. Dr. Almetwally Mostafa3 OUTLINE  Distributed Programming Models.  Distributed Module Interfaces.  Distributed Objects Model.  Remote Procedure Call.  Events and Notifications.  Java RMI Case Study.

4. Dr. Almetwally Mostafa4 Distributed Programming Models  A distributed programming model is as an abstraction layer above communication protocols details.  Different Programming models provided by middleware to support distributed applications include: Remote Procedure Call (RPC): Client programs call procedures in server programs running in separate remote hosts but in the same way as local procedure call. Remote Method Invocation (RMI): Client objects may invoke methods of remote objects residing in another process running on another host also in the same way as local method invocation. Event-based processing and event notification: The behavior of the system is driven by events, which represent local state changes within objects. Objects receive notifications of events at other objects in which they have registered interest.

5. Dr. Almetwally Mostafa5  Middleware is the provision of transparency and heterogeneity challenges: Location transparency: RMI and RPC invoked without knowledge of the location of invoked method/procedure. Transport protocol transparency: e.g., request/reply protocol used to implement RPC can use either transport protocols (UDP or TCP). Transparency of computer hardware and operating system: e.g., use of external data representations. Transparency of programming language used e.g., by use of programming language independent Interface Definition Languages, such as CORBA IDL. Distributed Programming Models

6. Dr. Almetwally Mostafa6 Distributed Module Interfaces  Allow interaction between modules of distributed programs.  Specify procedures and variables that can be accessed from other modules.  Modules are implemented to hide all information about them except the available through their interfaces. Module implementation can be changed without affecting its users.  Specifics for interfaces in distributed systems: No direct access to remote variables: Use message passing mechanism to transmit data variables. Local parameter passing mechanisms (by value, by reference) not applicable to remote invocations. Specify input or output as parameters attribute. Input parameters are transmitted with request message and output parameters are transmitted with reply message. Pointers are not valid in remote parameter passing.

7. Dr. Almetwally Mostafa7  RPC and RMI interfaces are often seen as: Service interface (in client/server model for RPC) Each server provides a set of procedures available for use by clients Defining the types of input and output arguments for each procedure. Remote interface (in distributed object model for RMI) Specify the methods of an object that can be invoked by objects in other processes. Defining the types of input and output arguments for each method. Methods can receive objects or object references (not pointers) as arguments and may return objects as results. Distributed Module Interfaces

8. Dr. Almetwally Mostafa8 Distributed Interface Definition  Language-specific approach: The RMI/RPC mechanism is integrated with a particular programming language if its notation can be used to define the interfaces and deal with input and output parameters. Allows the distributed applications programmers to use a single language for local and remote invocation. Example: Java RMI.  Interface definition language approach: Allows objects implemented in different languages to invoke useful objects implemented in one another. Uses a general IDL notation for defining interfaces including input and output parameters with their types. Example: CORBA IDL.

9. Dr. Almetwally Mostafa9 Distributed Objects Model  The logical partition of object-based programs into objects is naturally extended by the physical distribution of objects into different processes or computers in a distributed system.  Distributed object systems adopt the client-server architecture: Objects are managed by servers and their clients invoke their methods using remote method invocation. The client’s RMI request is sent in a message to the server managing the invoked method object. The method of the object at the server is executed and its result is returned to the client in another message. Objects in servers are allowed to become clients of objects in other servers.  Distributed objects can be replicated and migrated to obtain the benefits of fault tolerance, enhanced performance and availability.  Having client and server objects in different processes enforces encapsulation due to concurrency and heterogeneity of RMI calls.

10. Dr. Almetwally Mostafa10 Distributed Objects Model invocation remote invocation remote local invocation A B C D E F Remote and local method invocations

11. Dr. Almetwally Mostafa11 Distributed Objects Model  Each process contains a collection of objects, some of which can receive both local and remote invocations and others can receive only local invocations.  Objects that can receive remote invocations are called remote objects.  Other objects need to know the remote object reference in another process in order to invoke its methods. A remote object reference is an identifier that can be used through a distributed system to refer to a particular unique remote object.  Every remote object has a remote interface to specify which of its methods can be invoked remotely. Objects in other processes can invoke only the methods that belong to the remote interface of the remote object. Local objects can invoke the methods in the remote interface as well as other methods of the remote object.

12. Dr. Almetwally Mostafa12 Distributed Objects Model interface remote m1 m2 m3 m4 m5 m6 Data implementation remote object { of methods A remote object and its remote interface

13. Dr. Almetwally Mostafa13 Distributed Objects Model Design Issues  Although local invocations are executed exactly once, remote invocations cannot achieve this. Why not?  RMI usually applied via request/reply protocol which can suffer from many types of failure: Message omission and duplication can occur if implemented over UDP. Process failures (crash or arbitrary) are also possible.  Therefore, different choices of fault-tolerance measures can be applied: Retransmit request message until a reply is received or the server is assumed to be failed Filter out duplicate requests at the server if retransmit is used. Re-execute the operation when retransmitted request arrives or result retransmission (requires keeping a history at the server).  Combinations of fault-tolerance choices lead to a variety of invocation semantics for the reliability of remote invocation.

14. Dr. Almetwally Mostafa14 Distributed Objects Model Design Issues Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Yes Not applicable No Yes Not applicable Re-execute operation Retransmit replyAt-most-once At-least-once Maybe Invocation semantics

15. Dr. Almetwally Mostafa15 Distributed Objects Model Design Issues  Maybe invocation semantics: No fault-tolerance measure is applied. The invoker cannot tell if a remote method has been executed or not. Suffer from the following types of failure: Omission failures if invocation or result message is lost. Crash failures if the server containing the remote object fails. Useful only for application accepting occasional failed invocations.  At-least-once invocation semantics: Uses only retransmission of request messages – masks omission failures. The invoker receives either a result (after at least one execution) or an exception informing no result was received. Suffer from the following types of failure: Crash failure if the server containing the remote object fails. Arbitrary failures when re-execute the method more than once which causing wrong values to stored or returned (non-idempotent operations). Applicable only if all the remote methods are idempotent operations.

16. Dr. Almetwally Mostafa16 Distributed Objects Model Design Issues  At-most-once invocation semantics: Uses all the fault-tolerance measures. The invoker receives either a result (after exactly one execution) or an exception informing no result was received. Prevents arbitrary failures by ensuring that a method is never executed more than once for the same RMI.  CORBA and Java uses at-most-once invocation semantics.  COBRA allows maybe invocation semantics to be requested for methods without results.  Sun RPC provides at-last-once call semantics.

17. Dr. Almetwally Mostafa17  Several separate objects and modules are involved to achieve a remote method invocation: Communication modules: Responsible for providing a specified invocation semantics. Carry out the request-reply protocol to transmit request and reply messages between the cooperating server and client. Use only the first three items of the request and reply messages: message type, request id, and the invoked remote object reference. Select the dispatcher software for the invoked object class in the server. Distributed Objects Model RMI Implementation

18. Dr. Almetwally Mostafa18 Distributed Objects Model RMI Implementation object A object B skeleton Request proxy for B Reply Communication Remote Remote reference Communication module reference module module for B’s class & dispatcher remote client server The proxy and skeleton role in remote method invocation

19. Dr. Almetwally Mostafa19 Remote reference modules: Translate between local and remote object references and create remote object references. Have a remote object table in each process to support the translation. An entry for all the remote objects held by the server in its table. An entry for each local proxy held by the client in its table. Create a remote object reference and add it to the table when a remote object is passed in a request or a replay message for the first time. Translate the remote object reference to the corresponding local object reference which refer either to a remote object (in the server) or to a proxy (in the client). Distributed Objects Model RMI Implementation

20. Dr. Almetwally Mostafa20 RMI Software: Proxy: Make remote method invocation transparent to clients by behaving like a local object to the invoker. Forward the call in a message to the remote object and hiding all in- between operations (send, receive, marshalling, and unmarshalling) from the client. A client has one proxy for each remote object to hold its remote reference and implement the methods in its remote interface. Marshal a reference to the target object, its own methodId and its arguments into a request message and send it to the target then await the reply message to unmarshal it and return the result to the invoker. Dispatcher: A server has one dispatcher for each class representing a remote object. Receive the request message from the communication module and use the methodId to select the appropriate method in the skeleton and passing on the request message. Distributed Objects Model RMI Implementation

21. Dr. Almetwally Mostafa21 RMI Software: (cont.) Skeleton: Each class representing a remote object has a skeleton in the server to implement each method in the remote interface. Unmarshal the argument in the request message and invoke the corresponding method in the remote object. Await the invocation to complete to marshal the result in the reply message to the client proxy’s method. The classes of the proxy, skeleton, and dispatcher used in RMI are generated automatically by an interface complier. The server program contains the classes for the dispatchers and skeletons together with the implementations of the classes of all remote objects that it supports – servant classes. The client program contains the classes of the proxies for all the remote objects that it will invoke and use a binder to look up remote object references. Distributed Objects Model RMI Implementation

22. Dr. Almetwally Mostafa22  Free resources occupied by objects that have no more reference to it in the system.  Work in cooperation with the local garbage collector in each process in the system.  Java Distributed Garbage Collection algorithm: Each server maintains a list of clients that hold remote object references for each of its remote objects. When a client C first receives a remote reference to a particular remote object X, it makes an addRef(X) invocation to the server of that remote object and then the server adds C to the list of object X. When a client C’s garbage collector notices that a proxy for a remote object X is no longer referenced, it sends removeRef(X) invocation to the corresponding server which deletes C from the list of object X. When the list of a remote object X is empty and there are no local references to it, the server’s local garbage collector collect resources held by the object X. Distributed Objects Model Distributed Garbage Collection

23. Dr. Almetwally Mostafa23  Java algorithm fault tolerance: Carried out by request/reply communication with at-most-once invocation semantics between the remote reference modules in processes. Toleration of communication failures: addRef and removeRef are indempotent. If addRef(X) returns exception, then client will not instantiate proxy but will send removeRef(X). Effect of removeRef(X) is correct no matter whether addRef(X) succeeded or not. Failure of removeRef(X) is masked by the use of leases. Leases Servers lease their objects to clients for limited periods of time, starting with addRef. Helps tolerate failures of removeRef as well as client failures. Avoids problem of having to maintain lists of remote object references if all object references are handled through leases. Distributed Objects Model Distributed Garbage Collection

24. Dr. Almetwally Mostafa24  Very similar to a remote method invocation A client process calls a procedure in a server process. Servers may be clients of other servers to allow chains of RPCs. Implemented to have one of the choices of invocation semantics. Implemented over a request-reply protocol. The contents of request and reply messages are the same as RMI except that the object reference field is omitted. The supported software is similar except that no remote reference modules are required and client proxies and server skeletons are replaced by client and server stub procedures.  The service interface of the server defines the procedures that are available for calling remotely.  The client and server stub procedures and the dispatcher are generated by an interface compiler from the definition of the service interface. Remote Procedure Call (RPC)

25. Dr. Almetwally Mostafa25 Remote Procedure Call (RPC) client Request Reply Communication module dispatcher service client stub server stub procedure client process server process procedure program Role of client and server stub procedures in RPC

26. Dr. Almetwally Mostafa26  Distributed event-based systems allowing multiple objects at different locations to be notified of an event occurrence at a particular object.  The publish-subscribe paradigm is used: An object generating events publishes the list of events available for observation by other objects. Objects requiring notifications subscribes to the notification service at an object offering notification for this particular event through its publication list.  When a publisher experiences an event, subscribers that expressed an interest in that type of event will receive notifications.  Events and notifications can be used in a wide variety of different applications: A piece of equipment or an electronically tagged book is at new location. A client has entered participation in a collaborative work environment. An electronic document has been modified. Events and Notifications

27. Dr. Almetwally Mostafa27  Allow dealers using computer to see the latest information about the market prices of the stocks. The market price for a single named stock is represented by an object with several instance variables. The information is arrived from different external sources in the form of updates to some or all instance variables of the stock objects and collected by information providers. Dealers are interested only in their specialist stocks.  Modeled by processes with two different tasks: An information provider process continuously receives information from a single external source to apply it to the appropriate stock objects as an event and notifies all the dealers subscribed to the corresponding stock. A dealer process creates a local object to represent each named stock to subscribe the stock object at the relevant information provider and receive all information sent in notifications to display it to the user. Events and Notifications Dealing Room System

28. Dr. Almetwally Mostafa28 Events and Notifications Dealing Room System

29. Dr. Almetwally Mostafa29  An event source can generate events of one or more different types.  Each event has attributes to specify information about that event: the name of object generated it, the operation, its parameters and the time.  Types and attributes are used in subscribing to events and in notifications.  Whenever an event of a specific type that matches the attributes occurs, the interested parties will be notified.  In dealing room system example: There is one type of event – the arrival of an update to a stock. The attributes might specify the name of a stock, its current price, and latest rice or fall. Dealers may specify the interesting in all the events of a particular stock. Events and Notifications Event Types