Distributed Systems Course Topics in distributed objects

1. Distributed Systems CourseTopics 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

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. • 2

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 • 3

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 • 4

5. CORBA has a struct remote interface remote interface defines methods for RMI parameters are in, out or inout 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(); }; Figure 5.2 • 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 • 5

6. local C remote E local invocation invocation remote invocation invocation F B local A invocation D Distributed object model Figure 5.3 • 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 • 6

7. Invocation Fault tolerance measures semantics Retransmit request Duplicate Re-execute procedure message filtering or retransmit reply Figure 5.5 No Not applicable Not applicable Maybe Yes No Re-execute procedure At-least-once Yes Yes Retransmit reply At-most-once Invocation semantics • Local invocations are executed exactly once • Remote invocations cannot achieve this. Why not? • the Request-reply protocol can apply fault-tolerance measures • 7

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 - theclient 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) • 8

9. server client remote skeleton object A proxy for B object B & dispatcher Request for B’s class Reply Remote reference Communication Communication Remote carries out Request-reply protocol module reference module module module Proxy - makes RMI transparent to client. Class implements remote interface. Marshals requests and unmarshals results. Forwards request. translates between local and remote object references and creates remote object references. Uses remote object table 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. The architecture of remote method invocation Figure 5.6 RMI software- between application level objects andcommunication and remote reference modules • 9

10. 32 bits 32 bits 32 bits 32 bits interface of Internet address port number time object number remote object Representation of a remote object reference Figure 4.10 • 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 • 10

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 • 11

12. Java Remote interfaces Shape and ShapeList • Note the interfaces and arguments • GraphicalObject is a class that implements Serializable. Figure 5.11 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; } • 12

13. Java class ShapeListServer with main method • Probably skip this one 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());} } } Figure 5.13 13

14. Java class ShapeListServant implements interface ShapeList • Probably skip this one 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 Shapes 1 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 { ... } } Figure5.14 14

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 15

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 networksand 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. • 16