1 Distributed Objects and Remote Invocation – 5.1 Introduction  Foci: –Communication among distributed objects via RMI  Recipients of remote invocations are remote objects, which implement remote interfaces for communication –Reliability  Either one or both the invoker and invoked can fail, and status of communication is supported by the interface (e.g., notification on failures, reply generation, parameter processing – marshalling/unmarshalling) –Local invocations target local objects, and remote invocations target remote objects –Distributed even-based systems - ‘subscription’ to events as they occur at remote sites of interest; and receipt of ‘notification’ therefrom  Subscription/notification paradigm supports heterogeneity and asynchrony (e.g., the Jini distributed event-driven specification)

2 Distributed Objects and Remote Invocation – 5.1 Introduction  Programming models for distributed programs/applications –RPC – client programs call procedures in server programs, running in separate and remote computers (e.g., Unix RPC) –RMI – extensions of object-oriented programming models to allow a local method (of a local object) to make a remote invocation of objects in a remote process (e.g., Java RMI) –EBP (event-based programming) model – allows objects anywhere to receive notification of events that occur at other objects of which interests have been registered (e.g., Jini EBP)  Chapter 5 – focus on RMI and EBP paradigms –Issues  Distributed object communication  Design and implementation of RMI and RPC  EBP – design and implementation

3 Distributed Objects and Remote Invocation – 5.1 Introduction  Middleware –A suite of API software that uses underlying processes and communication (message passing) protocols to provide its abstract protocol – simple RMI request-reply protocol –The middleware provides location transparency, protocol abstraction, OS, and hardware independence, and multi-language support

4 Distributed Objects and Remote Invocation – 5.1 Introduction  Middleware –Location transparency: RPC – client calls appear to be local and remote procedure could be on any remote server; RMI remote objects’ location is transparent; and in EBP models sources of object event/notification is transparent –Protocol transparency: the middleware request-reply protocol can be built on top of lower-level TCP or UDP –Hardware transparency: Issues with different data representations, conversions, and instruction set are transparent –OS: all three paradigms could run on top of any OS platform

5 Distributed Objects and Remote Invocation – 5.1 Introduction  Remote Object Interfaces –Interfaces hide the details of modules providing the service; and access to module variables is only indirectly via ‘getter’ and ‘setter’ methods / mechanisms associated with the interfaces  (e.g., call by value/reference for local calls through pointers vs. input, output, and inout paradigms in rmi/rpc through message-data and objects) –An interface is a set of language facilities (syntax/semantics) or notation for mapping input/output parameters in a remote invocation/call onto native normal handling of parameters –Such API’s allow uniformity of both local and remote invocation (same syntax and denotational semantics) –IDL: Provide a ‘generic’ template of interfaces for objects in different languages to perform remote invocation among each other  E.g., CORBA IDL (Fig 5.2), Sun XDR for RPC, Jave RMI, OSF DCE for RPC in C

6 Distributed Objects and Remote Invocation – 5.2 Communication  By means of RMI: –The object model –Distributed objects (object-based distributed systems) –The distributed object model (extensions of the basic object model for distributed object implementation) –The design issues (of RMI) (local once-or-nothing invocation semantics vs. remote invocation semantics – similarities or differences) –The implementation issues (mapping the middleware to lower-layer facilities) –Distributed garbage collection issues (an application – algorithmic)

7 Distributed Objects and Remote Invocation – 5.2 Communication  The object model –Objects (in classes) encapsulate methods and data variables, with some variables being directly accessible; and communication via passing arguments and receiving results from (locally) invoked objects –Object references: objects or variables holding instances of objects are accessed via references. Accessing target/receiver objects requires – reference.methodname(args); and references can be passed as args, too. –Interfaces: the signature of a set of object methods – arg type, return values, and exceptions. Objects providing interfaces typically offer ‘internal’ implementations of methods of the interfaces. E.g., a class may implement several ‘interfaces,’ and an interface may be implemented by any class –Actions: effect of method invocation – may affect receiver/target or cause chain reaction to complete, including results and exception propagation –Exceptions: For clarity and cleanness of code, object methods lists exception conditions that can be thrown and handlers/blocks-of-code written to handle/catch the exceptions as they occur –Garbage collection: reclaiming freed object spaces – Java (automatic), C++ (user supplied)

8 Distributed Objects and Remote Invocation – 5.2 Communication  Distributed objects –State of an object: current values of its variables –State of an object (in OO context): depends of how the objects are partitioned or distributed in the program space and the programming model –CS: objects reside with client and server processes or computers –RMI: method invocations and associated messages are exchanged by c/s depending on where the objects reside –When objects are replicated for performance and fault-tolerance, or migrated for performance and availability, objects are thus distributed –Distributing objects require ‘encapsulation’ for effective, secure, protected object state (All data are accessed directly by their respective methods, and requires authorization.) –Concurrent access to distributed objects is protected (due to encapsulation, and use of, e.g., condition variables for synchronization) –Heterogeneity (of data types) is supported via interface-methods

9 Distributed Objects and Remote Invocation – 5.2 Communication  The distributed object model  extensions to the basic object model – supporting both local and remote method invocation of objects (with transparency) in processes. Some objects can effect only local invocation, and others remote invocation, and others can have both  RMI: invocations between objects in different processes (either on same or different computers) is remote. Invocations within the same process are local  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  objects need to know the remote object reference of an object in another process in order to invoke its methods. How do they get it?  the remote interface specifies which methods can be invoked remotely

10 Distributed Objects and Remote Invocation – 5.2 Communication invocation remote invocation remote local invocation A B C D E F –Objects receiving remote invocations (service objects) are remote objects, e.g., B and F –Object references are required for invocation, e.g., C must have E’s reference or B must have A’s reference –B and F must have remote interfaces (of their accessible methods) Figure 5.3

11 Distributed Objects and Remote Invocation – 5.2 Communication  Remote object references –An unique identifier of a remote object, used throughout a distributed system –The remote object reference (including the ‘interface’ list of methods) can be passed as arguments or results in rmi  Remote interfaces –Remote objects have a class that implement remote methods (as public). –In Java, a remote interface class extends the Remote interface –Local objects can access methods in an interface plus methods implemented by remote objects (Remote interfaces can’t be constructed – no constructors)

12 Distributed Objects and Remote Invocation – 5.2 Communication  Actions in distributed object systems –Local activations plus remote invocations that could be chained across different processes/computers. Remote invocation activate the RMI interface using the remote object reference (identifier) –Example of chaining: In Figure 5.3 Object A received remote object reference of object F from object B  Distributed garbage collection –Achieved by cooperation between local (language-specific) collectors and a designated module that keeps track of object reference-counting (See details and examples in 5.2.6, using an algorithm based on pairwise request-reply comm with at-most-once invocation semantics between the reference modules in the processes using proxies.)  Exceptions –Possible problems: remote process is busy, dead, suspended to reply, or lost reply; which will require timeout-retry in an exception handler implemented by the invoker/client –Usually, there are standard exceptions which can be raised plus others users implement

13 Distributed Objects and Remote Invocation – 5.2 Communication  Design Issues of RMI –Local invocations have at-most-once or exactly-once semantics –Distributed RMI, there alternative semantics are:  Retry request message – retransmit until reply is received or on server failure – at-least-once semantics  Duplicate message filtering – discard duplicates at server (using seq #s or ReqID)  Buffer result messages at server for retransmission – avoids redo of requests (even for idempotent ops) – at-most-once semantics

14 Distributed Objects and Remote Invocation – 5.2 Communication  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 - if no reply, the client does not know if method was executed or not –omission failures if the invocation or result message is lost  At-least-once - the client gets a result (and the method was executed at least once) or an exception (no result) –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  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)

15 RMI Implementation: The architecture of remote method invocation (with transparency) 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 Figure 5.6 RMI software - between application level objects and communication and remote reference modules Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests and unmarshals results. Forwards request. Dispatcher - gets request from communication module and invokes method in skeleton (using methodID in message). 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

16 Distributed Objects and Remote Invocation – 5.3 RPC RPC Similar to RMI but calls are made to remote ‘procedures’ and can have chain-reaction effect Server process defines the callable procedures in its service interface, have at-most-once or at-least-once invocation semantics Implemented using request-reply protocol (without ROR) There is one stub procedure for each procedure in the interface (like RMI proxy – marshalls procedure id and arguments into message, and unmarshalls results on return) Server has dispatcher (like RMI) with one server stub procedure and its service procedure for each procedure in the interface Server stub procedure (like RMI skeleton method) – unmarshalls arguments in calls, calls corresponding procedure, and marshalls results in a reply message

17 Distributed Objects and Remote Invocation – 5.3 RPC

18 Distributed Objects and Remote Invocation – 5.4 Events & Notification

19 Distributed Objects and Remote Invocation – 5.4 Events & Notification

20 Java Remote interfaces Shape and ShapeList import java.rmi.*; import java.util.Vector; public interface Shape extends Remote { int getVersion() throws RemoteException; GraphicalObject getAllState() throws RemoteException; } public interface ShapeList extends Remote { Shape newShape(GraphicalObject g) throws RemoteException; Vector allShapes() throws RemoteException; int getVersion() throws RemoteException; } Note the interfaces and arguments GraphicalObject is a class that implements Serializable. Figure 5.11

21 Java class ShapeListServer with main method import java.rmi.*; public class ShapeListServer{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); try{ ShapeList aShapeList = new ShapeListServant();1 Naming.rebind("Shape List", aShapeList );2 System.out.println("ShapeList server ready"); }catch(Exception e) { System.out.println("ShapeList server main " + e.getMessage());} }  Probably skip this one Figure 5.13

22 Java class ShapeListServant implements interface ShapeList import java.rmi.*; import java.rmi.server.UnicastRemoteObject; import java.util.Vector; public class ShapeListServant extends UnicastRemoteObject implements ShapeList { private Vector theList; // contains the list of Shapes1 private int version; public ShapeListServant()throws RemoteException{...} public Shape newShape(GraphicalObject g) throws RemoteException {2 version++; Shape s = new ShapeServant( g, version);3 theList.addElement(s); return s; } public Vector allShapes()throws RemoteException{...} public int getVersion() throws RemoteException {... } }  Probably skip this one Figure 5.14

23 Java client of ShapeList import java.rmi.*; import java.rmi.server.*; import java.util.Vector; public class ShapeListClient{ public static void main(String args[]){ System.setSecurityManager(new RMISecurityManager()); ShapeList aShapeList = null; try{ aShapeList = (ShapeList) Naming.lookup("//bruno.ShapeList");1 Vector sList = aShapeList.allShapes();2 } catch(RemoteException e) {System.out.println(e.getMessage()); }catch(Exception e) {System.out.println("Client: " + e.getMessage());} }  Probably skip this one Figure 5.15

24 Summary  Heterogeneity is an important challenge to designers : –Distributed systems must be constructed from a variety of different networks, operating systems, computer hardware and programming languages.  The Internet communication protocols mask the difference in networks and middleware can deal with the other differences.  External data representation and marshalling –CORBA marshals data for use by recipients that have prior knowledge of the types of its components. It uses an IDL specification of the data types –Java serializes data to include information about the types of its contents, allowing the recipient to reconstruct it. It uses reflection to do this.  RMI –each object has a (global) remote object reference and a remote interface that specifies which of its operations can be invoked remotely. –local method invocations provide exactly-once semantics; the best RMI can guarantee is at-most-once –Middleware components (proxies, skeletons and dispatchers) hide details of marshalling, message passing and object location from programmers.