Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine

4.1 Distributed Object Model  RPC vs. RMI: The remote procedure call (RPC) approach extends the common programming abstraction of the procedure call to distributed environments, allowing a calling process to call a procedure in a remote node as if it is local. Remote method invocation (RMI) is similar to RPC but for distributed objects, with added benefits in terms of using object-oriented programming concepts in distributed systems and also extending the concept of an object reference to the global distributed environments, and allowing the use of object references as parameters in remote invocations.

4.1 Distributed Object Model  The commonalities between RMI and RPC: They both support programming with interfaces. They are both typically constructed on top of request-reply protocols and can offer a range of call semantics such as at-least-once and at- most-once. They both offer a similar level of transparency.  The differences between RMI and RPC: The programmer is able to use the full expressive power of object- oriented programming in the such as the use of objects, classes and inheritance, and can also employ related object-oriented design methodologies and associated tools. Building on the concept of object identity in object-oriented systems, all objects in an RMI-based system have unique object references (whether they are local or remote). RMI allows the programmer to pass parameters not only by value, as input or output parameters, but also by object reference.

4.1 Distributed Object Model  Design issues for RMI: In an object-based system, its state is logically divided into parts with each part associated with a specific object. Thus, the physical distribution of such objects on different remote processes is a natural extension. The distributed object model borrows the basic object- oriented concepts such as: ⁻Object references. ⁻Interfaces (e.g. classes). ⁻Actions, method invocations on objects. ⁻Exceptions. ⁻Garbage collection.

4.1 Distributed Object Model  Design issues for RMI: distributed objects system can uses a client-server architecture where in this case: ⁻Objects are created and managed by servers. ⁻Clients issue remote method invocations on the servers’ objects to use their services. Any of the variations of the client server architecture can be implemented using the distributed object model.

4.1 Distributed Object Model  Remote and Local Method Invocations :

4.1 Distributed Object Model  Design issues for RMI: Remote Object References: ⁻Extended from the concept of object reference in the object- orientation model where: Any object that can receive a remote method invocation must have a remote object reference. Remote object references can be passed as arguments and results to remote method invocations. ⁻A remote object reference is an identifier that is used in a distributed system to refer to a particular unique remote object.

4.1 Distributed Object Model  Design issues for RMI: Remote Interfaces: ⁻The class of a remote object implements the methods of its remote interface. ⁻Objects in other processes can only invoke the methods specified in the remote interface. ⁻Remote interfaces do not have constructors, I.e. cannot construct objects directly through interfaces. ⁻The CORBA system provides an interface definition language (IDL), which is used for defining remote interfaces. ⁻The classes of remote objects and the client programs may be implemented in any language for which an IDL compiler is available, such as C++, Java or Python. ⁻In Java RMI, remote interfaces are defined in the same way as any other Java interface.

4.1 Distributed Object Model

 Design issues for RMI: Actions: ⁻As in an object-based non-distributed system, action is initiated by a (remote) method invocation, which may cause further method invocations on other objects. ⁻The chain of remote method invocations are across a set of objects in different computers. ⁻In such invocations, the remote object reference is used to invoke the methods.

4.1 Distributed Object Model

 Design issues for RMI: Garbage Collection: ⁻A typical garbage collector ensures that if there are no references still held to an object, such object is removed and memory is recovered. ⁻A distributed garbage collector not only checks local references to an object but also remote object references from other parts of a distributed system, in order to decide whether to remove an object or not. ⁻Garbage collection is carried out through cooperation between local garbage collectors

3.1 Distributed Object Model  Design issues for RMI: Exceptions: ⁻Remote method invocations can fail due to distribution problem or failure in the execution of the method itself. ⁻Thus, remote method invocations should be able to raise exception on each of the above type of problems occur.

4.1 Distributed Object Model  Implementation of RMI: A number of objects and modules are required to achieve remote method invocation as shown in the figure on the next slide. This diagram illustrates the operations and components involved when an application-level object A invokes a method in a remote application-level object B. Object A holds a remote object reference for object B. Several modules are required in a remote method invocation including: ⁻Communication modules. ⁻Remote reference modules. ⁻RMI software including a proxy, a dispatcher and skeleton. The two cooperating communication modules at the client and server implement the request-reply protocol which forms the basis of communication.

4.1 Distributed Object Model

 Implementation of RMI: The two modules exchange request and reply messages which include the following fields: ⁻The message types. ⁻A requestID. ⁻A remote object reference. The methodId and the marshalling and unmarshalling is handled by the RMI software components. The remote reference module is responsible for translating between local and remote object references.

4.1 Distributed Object Model  Implementation of RMI: Each remote reference module in a process contains a remote object table which record the correspondence between local and remote object references. It includes: ⁻An entry for the remote objects maintained by the process (e.g. remote object B). ⁻An entry for each local proxy, e.g. the proxy for object B will be recorded in the table at the client. When a remote object is to be passed as an argument or result for the first time, a new remote object reference is created and added to the remote object table. When a remote object reference arrives in a request or reply message, the remote object table is queried to find the corresponding local object reference which could be a proxy or a remote object.

4.1 Distributed Object Model  Implementation of RMI: It Proxy component is responsible for making remote method invocation transparent to the client as if the call is made to a local object: The proxy receives the method invocation request. Instead of executing the invocation, it forwards it in a message to the remote object. It hides the remote object reference, the marshalling of arguments, unmarshalling of results. There is one proxy for each remote object the process is holding a remote object reference for. The class of the proxy implements the methods in the remote interface of the remote object it represents. The implementation of each proxy method marshals the remote object reference, its own methodId and arguments. These items are packaged in a request message and sent to the remote object. On the return of the reply message, the proxy method unmarshals the message and return the result to the invoker (client).

4.1 Distributed Object Model  Implementation of RMI: The Dispatcher is a server component where: There is a dispatcher object for each remote object maintained by the server (I.e. there is a dispatcher for each class representing a remote object). The dispatcher receives a request messages from the communication module (of the server which received the message through the client’s communication module). It uses the methodId to forward the request to the right method in the skeleton. The dispatcher and proxy use the same methodIds for the methods in the remote interface.

4.1 Distributed Object Model  Implementation of RMI: The Skeleton implements the methods of the remote interface and thus there is a skeleton for each class representing a remote object. The skeleton umarshals the arguments in the request message and invoke the corresponding method on the remote object. After completion of the remote method invocation, the skeleton marshals the result, together with any exceptions and send a reply message to the sending proxy’s method.