Chapter 5: Distributed objects and remote invocation From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 4, Addison-Wesley 2005 Figure 5.1 Middleware layers Applications RMI, RPC and events Request reply protocol Middleware layers External data representation Operating System 1
Topics Remote method invocations Events and notifications Remote Method Invocations The object model Distributed objects The distributed object model Design issues Implementation Distributed garbage collection 2
The Object Model Objects have data and methods Data should be accessible only via its methods Objects can be accessed via object references Interfaces Provide signatures of methods without implementation Serve as contracts Actions Exceptions GC Distributed Objects Objects located in different processes, not necessarily different computers Remote vs. local Objects Method invocation Distributed objects collaborate via remote method invocations, which enforces encapsulation The state of an object can be accessed only via methods 3
Figure 5.3 Remote and local method invocations A remote invocation B local C invocation local E invocation local invocation D remote invocation F The Distributed Object Model Remote object reference Invoked remote objects are identified by reference Reference vs. pointer Remote object references can be passed as arguments and results of RMIs Remote interface Every remote object has a remote interface May be specified by IDL, e.g. CORBA IDL Passing parameters can be described as input and output Input parameters serves as arguments Output parameters will be returned and used as results or to replace the values of the corresponding variables in the calling environment 4
Figure 5.2 CORBA IDL example // In file Person.idl 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(); }; Figure 5.4 A remote object and its remote interface remoteobject Data remote interface m1 m2 implementation { m3 of methods m4 m5 m6 5
Figure 5.5 Instantiation of remote objects L C remote invocation instantiate instantiate M N remote invocation K The Distributed Object Model (con t) Actions After invocation request received, an action is initiated and may result further invocations on other objects Remote GC Reclaim the unused space Cooperation between existing local GCs and a coordinator Exceptions Errors may occur and raise exceptions Client programs need to be able to handle exceptions, e.g. C++ 6
Design Issues Invocation semantics Local: exact once Remote: maybe, at-least-once, at-most-once Transparency Should local and remote invocations have the same syntax? Remote invocations may have many failures that local invocations don t have The difference should be revealed in remote interfaces Figure 5.6 Invocation semantics Fault tolerance measures Invocation semantics Retransmit request message Duplicate filtering Re-execute procedure or retransmit reply No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once 7
Figure 5.7 The role of proxy and skeleton in remote method invocation client object Aproxy for B Request server skeleton & dispatcher for B s class remote object B Reply Remote Communication reference module module servant Communication Remote reference module module Implementation Communication module: carry out the request-reply protocol Remote reference module: translating between local and remote object references Proxy: make RMI transparent to clients by behaving like a local object to the invoker Dispatcher: use method id to find the appropriate method Skeleton: implement the method interface, but its actual duty is to unmarshal arguments and marshal result 8
Implementation (con t) Remote object interfaces do not have constructors; how a remote object can be created via its remote interface? Factory method: a method can be used to create a remote object Recall how you can create a local object, their syntaxes are different Activation: a remote object may be passivated to save resources, and activated when one of its methods is invoked An object that is guaranteed to live between activations of process is called a persistent object. Figure 5.8 Role of client and server stub procedures in RPC in the context of a procedural language client process server process Request client program client stub procedure Communication module Reply server stub procedure Communication module dispatcher service procedure 9
Distributed Garbage Collection Goal: to reclaim the memory of unreferred objects Reference count A remote object has a list that maintains all the processes have reference to itself When a client process invoke its method for the first time, the proxy will be created and inform the server to add the client to the list When the client s GC notifies that the proxy of the server is no longer reachable; the proxy will be deleted and inform server to remove the client from the list When the list is empty, the server s GC will reclaim its space unless it is referred by local objects Events and notifications Use of event: an object can react to a change occurring in another object s of events are essentially asynchronous and determined by the receivers Publish-subscribe paradigm Two main characteristics of distributed event-based systems Heterogeneous Event notifications can be used as means to coordinate two components that are not designed to work together Asynchronous Publishers and subscribers do not need to synchronize; they are decoupled 10
Figure 5.10 Dealing room system Dealer s computer External source Dealer s computer Dealer Dealer Information provider Dealer s computer Dealer Information provider External source Dealer s computer Dealer Figure 5.11 Architecture for distributed event notification object of interest Event service subscriber 1. notification object of interest observer subscriber 2. notification notification object of interest observer subscriber 3. notification 11
Distributed Event The object of interest: the object that experiences changes of state as a result of its method being invoked, and the change may be of interest to other objects Event: An event occurs at an object of interest as the result of the completion of a method execution : an object that contains information about an event Subscriber: an object has subscribed to some type of events in another object. It receives notifications about such events Distributed Event (con t) Observer objects: Its main purpose is to decouple an object of interest from its subscribers. Since a subscribe may subscribe very complicated patterns of events and then the object of interest needs to implement the patterns for sending the notification, such tasks could be done by observers and thus decoupling them Publisher: an object that will generate notifications of events. It could be an object of interest or observer 12
Distributed Event (con t) Event service: a set of objects that maintains a database of published events and of subscriber s interests Roles of observers Forwarding Filtering of notifications Patterns of events mailboxes 13