2. Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: authors@cdk2.net This material is made available for private study and for direct use by individual teachers. It may not be included in any product or employed in any service without the written permission of the authors. Viewing: These slides must be viewed in slide show mode. Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001. Distributed Systems Course Topics in distributed objects Ideas needed to understand CORBA Revise 1.4 heterogeneity 4.3 external data representation 5.4 distributed objects & RMI 5.5 Java RMI case study

3. 2 Heterogeneity  Applies to all of the following: –networks  Internet protocols mask the differences between networks –computer hardware  e.g. data types such as integers can be represented differently –operating systems  e.g. the API to IP differs from one OS to another –programming languages  data structures (arrays, records) can be represented differently –implementations by different developers  they need agreed standards so as to be able to interwork  Middleware provides a programming abstraction and masks the heterogeneity of networks etc.

4. 3 Middleware programming models  Distributed objects and remote object invocation is the model explained in Chapter 5 –illustrated by Java RMI  CORBA is in Chapter 17. We will study it shortly. –it provides remote object invocation between a client program written in one language and a server program written in another language –our book uses Java CORBA to illustrate the use of CORBA –another language commonly used in CORBA is C++  Other programming models –remote event notification –remote SQL access –distributed transaction processing

5. 4 External data representation  This was presented in Chapter 4. It masks the differences due to different computer hardware.  CORBA CDR –only defined in CORBA 2.0 in 1998, before that, each implementation of CORBA had an external data representation, but they could not generally work with one another. That is:  the heterogeneity of hardware was masked  but not the heterogeneity due to different programmers (until CORBA 2) –CORBA CDR represents simple and constructed data types (sequence, string, array, struct, enum and union)  note that it does not deal with objects –it requires an IDL specification of data to be serialised  Java object serialisation –represents both objects and primitive data values –it uses reflection to serialise and deserialise objects– it does not need an IDL specification of the objects

6. 5 CORBA IDL example 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(); };  Remote interface: –specifies the methods of an object available for remote invocation –an interface definition language (or IDL) is used to specify remote interfaces. E.g. the above in CORBA IDL. –Java RMI would have a class for Person, but CORBA has a struct Figure 5.2 parameters are in, out or inout remote interface remote interface defines methods for RMI CORBA has a struct

7. 6 Distributed object model invocation remote invocation remote local invocation A 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  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 Figure 5.3

8. 7 Invocation semantics  Local invocations are executed exactly once  Remote invocations cannot achieve this. Why not? –the Request-reply protocol can apply fault-tolerance measures 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 procedure Retransmit replyAt-most-once At-least-once Maybe Figure 5.5

9. 8 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)

10. 9 The architecture of remote method invocation 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

11. 10 Representation of a remote object reference Internet addressport numbertimeobject number interface of remote object 32 bits  a remote object reference must be unique in the distributed system and over time. It should not be reused after the object is deleted. Why not?  the first two fields locate the object unless migration or re-activation in a new process can happen  the fourth field identifies the object within the process  its interface tells the receiver what methods it has (e.g. class Method)  a remote object reference is created by a remote reference module when a reference is passed as argument or result to another process –it will be stored in the corresponding proxy –it will be passed in request messages to identify the remote object whose method is to be invoked Figure 4.10

12. 11 Shared whiteboard example (p 194)  In the RMI and CORBA case studies, we use a shared whiteboard as an example –this is a distributed program that allows a group of users to share a common view of a drawing surface containing graphical objects, each of which has been drawn by one of the users.  The server maintains the current state of a drawing and it provides operations for clients to: –add a shape, retrieve a shape or retrieve all the shapes, –retrieve its version number or the version number of a shape

13. 12 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

14. 13 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

15. 14 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

16. 15 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

17. 16 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.