Object-based Distributed Systems

Transcription

1 Draft material for 3rd edition of Distributed Systems Concepts and Design Department of Computer Science, Queen Mary & Westfield College, University of London Object-based Distributed Systems CORBA, ORBIX and Java RMI Introduction The first part of this set of notes introduces object-based distributed systems, the second part discusses CORBA (a standard for distributed objects) and the third part introduces ORBIX (an implementation of CORBA). Part four gives a brief introduction to Java RMI. For a review of Distributed Object based systems, see Chin and Chanson [1991]. For up-to-date information on CORBA, see the book [Orfali et al. 96]. For information on Orbix see [Orbix 95, Orbix 95 adv.]. For the Java language, see the book Java in a Nutshell [Flanagan 97]. 1. Object Based Distributed Systems The object-based model for a distributed system introduced in CDK Section 1.3 is based on the model supported by object-oriented programming languages. In this section we discuss briefly the main ideas of object-oriented programming languages and then point out their relevance to distributed systems. Finally we discuss the requirements for object-based distributed systems that are to provide a platform for cooperative applications - that is, applications that enable users to cooperate in carrying out joint tasks. Distributed object systems generally provide remote method invocation in an object-based programming language together with operating systems support for object sharing and persistence. Note that RPC which is used for client server communication is replaced by Remote Method invocation (RMI) in distributed object systems. 1.1 Object-oriented programming languages. An object-oriented program, for example in Smalltalk, Java or C++ consists of a collection of interacting objects, each of which provides a service specified by its interface as illustrated in Figure 1. Objects communicate with one another by sending messages. A message is a request for an object to perform one of its methods (operations). It is the object that receives a message not the sender that determines how to carry out the method. The set of messages to which an object can respond is called its interface. Objects encapsulate data and the code of their methods. In other words, the sender of a message requesting a method does not know how it is carried out. Although some languages, for example Java and C++ allow programmers to define objects that don't encapsulate their data, we will assume here that objects do encapsulate their data and that the data can be accessed only via Version of December 7, 1997

2 Object-based Distributed Systems 2 interface op1 Data (instance variables) object op2 op3 implementations of methods op1, op2, op3 Figure 1. An object and its interface getter and setter methods. This has the advantage that the format of the data or the implementation of the methods can be altered without the invokers being aware. Object Identity Each object has an 'identifier' in the underlying object system, for example the value of a Java object reference is an object identifier or OID. The identifier of an object enables it to be indicated as the target of a message. Object-oriented programming systems support enquiries as to whether one OID refers to the same object as another. (e.g. equals in Java). OIDs are first class values in object-oriented programming languages and they may for example, be assigned to variables, passed as arguments and returned as results of methods. Actions Action in an object-oriented program is initiated by an object sending a message to another object requesting a method invocation. The object invoked executes the appropriate method and then returns control to the invoking object. An invocation of a method can have two effects: i) the state of the object may be changed and ii) further invocations on methods in other objects may take place. As an invocation can lead to further invocations of methods in other objects, an action is a chain of related invocations each of which eventually returns. This explanation does not take account of exceptions. A message is a request for action and can have additional information (arguments) needed to carry out the action. The receiver will perform some method (execute its code) to carry out the request. The interpretation of a message can vary with different recipients, e.g. a message to an object to draw itself would result in a different action according to whether the object is a square or a circle. Classes and instances A class describes a potentially infinite set of similar objects - objects that represent the same system component such as a stack or a bank account. A class specifies how to create new instances and the types of the arguments an result (signatures) of the methods to be provided by those instances. In addition a class must define the instance variables and the implementation of the methods. Classes are used like types for defining parameters and results in signatures. But classes differ from types in that they are used to create instances, generally by applying the new keyword to a constructor which is special sort of method whose name is the same as the name of the class and whose role is to initialise the instance variables. The new method in Java or C++ acquires storage on the heap for new instances of classes - this is known as dynamic allocation. In C++, objects may also be allocated automatically.

3 Object-based Distributed Systems 3 int pop () void push (int n) interface 'face' of a stack int stack []; int stackpointer; public final int STACKSIZE = 20; public push(int n) { stack[stackpointer++ ]= n; ---- ; implementation 'face' of a stack Figure 2. Interface vs. Implementation. (originally from Budd 97) Since classes are used to create new objects, each object is an instance of a class. All the instances of a class use the same methods and can share the code of the implementation, but each instance has its own set of instance variables with their own values. Classes in programs can be organised as a hierarchy in which one class can make use of the code of another. Single inheritance allows a class to make use of the code of one other class - that is it can be a sub-class. A sub-class specifies that all of its instances will be the same as instances of another class (its superclass) except for differences explicitly stated. These differences may consist of simple extensions (extra data and methods) or they may consist of re-definitions (overrides) of the methods of the parent class. For example, a class Shape may define the properties common to all graphical objects and the classes Circle, Square, etc. will define the properties specific to circles and squares. Interface versus implementation. The users of an object just see the interface view of its class, whereas the implementors see the details of how the data is represented and manipulated as shown in Figure 2. Provided that the two views are independent, the implementor is free to improve the implementation at any time, either by adding functionality or by altering the data representation. Multiple inheritance Multiple inheritance (provided in C++ and in CORBA IDL) allows a class to make use of the code of several other classes. Java does not provide multiple inheritance. But it does allow classes to implement several interfaces as well as inheriting from one class. In Java, an interface is an abstract definition of the signatures of a set of methods. Java interfaces are allowed to extend one or more other interfaces. The methods of an interface may be implemented by any other class. Although people compare the ability of a class to have several interfaces with multiple inheritance, it does not provide a way of inheriting implementations from several classes. Dynamic Binding The method executed is chosen according to the class of the recipient of the message. This is called dynamic binding. For example, a graphics program might maintain a collection of shapes of different sorts (such as square, circle). Then a request to find the perimeter of each of the graphical objects in the collection could be implemented by sending a perimeter message to each object in turn as follows.

4 Object-based Distributed Systems 4 Shape *ashape; ShapeList *alist; // the collection of shapes int n = alist -> numberelements() for(int i=1; i<=n; i++) { ashape = alist -> nthelement(); // access next shape cout << "Perimeter: "<< ashape -> perimeter() << "\n"; In this C++ example, ashape is a pointer of class Shape and on each iteration, instances of the classes Circle, Square, etc. are assigned to it. The effect of the message perimeter depends on the class of the receiver assuming that perimeter was declared as a virtual method in class Shape. In Smalltalk any message can be sent to any object. The receiver carries it out provided that it or one of its superclasses has the corresponding method. The search for a matching method starts at the receiver, continues in its immediate superclass and then in the superclass of its superclass and so on until the class Object at the top of the hierarchy is reached. As soon as a matching method is found, it is carried out. If none is found, an exception is raised. Java is similar to Smalltalk in that dynamic binding applies to all messages, but it differs in that the compile-time type checking ensures that a message is not sent unless a matching method will be found in the recipient s class or one of its superclasses. In C++ messages are statically bound unless the corresponding method (e.g. perimeter in class Shape) is declared as virtual and the object receiving the message is on the heap. Garbage Collection When instances are allocated on a heap, it is necessary to provide a means of freeing the space they occupy when they are no longer needed. Languages including Java and Smalltalk can detect automatically when an instance is no longer accessible. The space occupied by inaccessible instances is recovered and made available for allocation to future instances. This process is called garbage collection. In C++ which does not have a garbage collector, the programmer must apply the delete operator to any instance that is no longer required. For some classes the programmer also needs to define a destructor that defines the rules for freeing the components of an instance. The presence of a garbage collector can avoid programming errors associated with freeing memory that is no longer allocated or with failing to free memory that is no longer accessible. We return to a discussion of the difficulties of freeing storage in C++ programs in the section on Orbix (Section 3). The extension of garbage collection to distributed objects is difficult, since references to an object may be held at several sites in addition to the one where the object is located. Object-based vs. object-oriented CDK Section 3.1 refers to the object-based model for a distributed system whereas we have been discussing object-oriented programming. The term object-based generally refers to languages with objects and classes whereas object-oriented refers to languages with inheritance as well [Wegner 1986], but the use of these terms is not very consistent.

5 Object-based Distributed Systems 5 modules classes or types inheritance Modula-2, ADA CLU [Liskov 88] Emerald [Jul et al. 1988] Simula, Smalltalk, C++,Eiffel. Java Figure 3 Language categories Figure 3 shows some examples of languages classified into sets according to whether they have modules, classes or types, or classes and inheritance. Languages that provide simple modules do not support multiple instances and therefore do not provide OIDs. 1.2 Objects in distributed systems The state of an object consists of the values of its instance variables. In the object-based paradigm the state of a program is partitioned into separate parts, each of which is associated with an object. Since object-based programs are logically partitioned, the physical distribution of objects into different processes or computers in a distributed system is a natural extension. The state of an object can be accessed only by the methods of the object, which means that it is not possible for unauthorised methods to act on the state. For example, the possibility of concurrent RMI from remote objects implies that an object may be accessed concurrently. Therefore, the possibility of conflicting accesses arises. However, the fact that the data of an object is accessed only by its own methods allows objects to provide methods for protecting themselves against incorrect accesses. For example, they may use synchronisation primitives such as condition variables to protect access to instance variables. Another advantage of treating the shared state as a collection of objects is that an object may be accessed via RMI or it may be copied into a local cache and accessed directly provided that the class implementation is available. The fact that objects are accessed only via their methods gives another advantage for heterogeneous systems in that different data formats may be used at different sites these formats will be un-noticed by clients that use RMI to access the methods of the objects. These observations apply to most sorts of distributed objects, whether they have classes or types or inheritance as well. But an essential feature is that objects have OIDs - which excludes modules. Object Identity in a distributed system The notion of OID must be extended to allow any object that can receive a RMI to have a remote object identifier (ROID). A ROID is an identifier that can be used throughout a distributed system to refer to a particular unique object. For example, Java RMI has an ObjID class that is

6 Object-based Distributed Systems 6 used to identify remote objects in a virtual machine over time. A value of a Java remote object reference consists of an endpoint (a Java virtual machine) and an identifier (instance of ObjID). In a true distributed object system, ROIDs are first class values and for example, may be assigned to instance variables, passed as arguments and returned as results. A remote method invocation is made via the ROID of an object in the same way that a local method invocation is made via the OID of an object. Collections of objects may be linked together as shown in Figure 6 where a client could obtain the ROID of object O1 could from a binder and then use RMI on O1 to obtain the ROID of O2 or O3, thus allowing the client to use RMI on O2 or O3. A distributed object system requires a service for comparing remote object identifiers to find out whether they refer to the same object. For example, in Java RMI, the class RemoteObject implements the method equals. The ability to compare the identifiers of remote objects is needed to avoid a client generating multiple proxies for the same remote object. Actions in a distributed object system As in the non-distributed case, an action is initiated by a method invocation, which may result in further invocations on methods in other objects. But in the distributed case, the objects involved in a chain of related invocations may be located in different processes or different computers. When an invocation crosses the boundary of a process or computer, RMI is used and the ROID of the object must be available to make the RMI possible. In some cases, a location service or simple binder may be needed to obtain the ROID of a remote object. The role of proxies in transparent Remote Method Invocation RMI should be transparent. That is an object should be able to send a message to another object and to receive a reply without being aware of whether the receiver is local or remote. Transparency is achieved by providing a local proxy for each remote object that can be invoked by a local object. The role of a proxy is to behave like a local object towards the message sender, but instead of executing the message, it forwards it to the remote object. The remote object performs the message and replies without being aware that its reply is sent back to a sender on a remote computer. Proxies were introduced in Distributed Smalltalk [Bennett 89] and were also used in C++ based distributed object systems such as SOS [Shapiro 89] and are used in some CORBA implementations (e.g. Orbix) and in Java RMI. Proxies should be generated automatically by the system. As the variables in Smalltalk are typeless, some Smalltalk implementations of transparent RMI allow a proxy to forward any method it receives to the corresponding remote object. But languages such as Java that associate types with variables should check that RMIs are suitable for the type of the remote object. This requires that the class of the proxy provides just the methods in the interface of the remote object. This is achieved by implementing the methods in the class of the proxy as a set of client stub procedures. A remote object one that can be accessed via RMI has a skeleton object whose class has the server stub procedures as its methods. The classes for the proxy and the skeleton used in RMI are generated automatically by an interface compiler like the client and server stub procedures in RPC. For example, in the Orbix implementation of CORBA, interfaces are defined in CORBA IDL and the interface compiler generates the classes for proxies and skeletons in C++. For Java RMI, the set of methods offered by a remote object is defined as a Java interface which is implemented within the class of the remote object. The Java RMI compiler generates the proxy and skeleton classes from the class of the remote object. Note: Smalltalk remote objects don t

7 Object-based Distributed Systems 7 X Site S proxy for A A's client stubs communication mudule Request Reply ROID module dispatcher A's skeleton A's server stubs B A C Site T Figure 4 The role of proxy and skeleton in remote method invocation. require skeletons as the dispatcher can use perform on the object containing the message and its arguments. Figure 4 shows object X (the sender) invoking a method in remote object A (the receiver). Before X can invoke a remote object (like A), there must already be a local proxy that X can use. X sends the invocation to A's proxy. The proxy knows the ROID of the object for which it is a proxy. The (stub) method invoked in the proxy has the same signature as the one to be invoked in the remote object. Note that in Java, a site corresponds to a Java Virtual Machine. The stub method of the proxy marshals the ROID of the receiver, the name (or identifier) of the method and its arguments and sends the invocation in a Request message. At the receiving end a dispatcher gets the ROID of the receiver and the name of the method from the message and uses it to invoke a method in the skeleton for the object (A). The skeleton unmarshals the arguments and invokes the corresponding method in the object A. The result of the invocation is then marshalled by the same skeleton method and sent in a Reply message to the sending proxy s method. When it arrives, the result is unmarshalled and handed over to the sender. The ROID module A remote object cannot be invoked unless the invoking object has access to a proxy. Proxies are created according to need whenever a ROID arrives in a Reply message. The ROID module shown in Figure 4 is responsible for managing proxies and ROIDs. Whenever a ROID arrives in a Reply message, the ROID module checks if a proxy for the remote object already exists if none exists, then it creates a proxy of a suitable class. The class of the proxy can be determined from the type of the return value of the method invoked by RMI. In Figure 4, suppose that X s invocation of a method of remote object A asks for an ROID for object B. A will return a local id for B via its skeleton which will ask the ROID module to provide the corresponding ROID. The ROID module checks whether B already has a ROID if not, it creates one. A ROID for B is included in the Reply message. On arrival, a proxy for B is created and an OID to the proxy is returned to X. To support this arrangement, the ROID module on each site has a remote object table' that records the correspondence between the local and the remote object identifiers. When the local object is an object that can be accessed from a remote site (e.g. A at site T), then the table records the correspondence between the local and remote identifiers of the same object (i.e. A). When the local object is a proxy (e.g. A s proxy at site S), then the table records the correspondence between the remote identifier of an object and the local identifier of its proxy.

8 Object-based Distributed Systems 8 Proxy code A proxy, like any other object is created from a suitable class. As we mentioned earlier, the proxies in Distributed Smalltalk will forward any message they receive, irrespective of the class of the corresponding remote object. In this case, every proxy is created from the same class. But an exception is raised when the remote object is unable to find a matching method and is propagated back to the proxy. The remote invocation of non-existent methods may be regarded as rather inefficient and it has been suggested that proxies should be designed to filter them out. Such filtering would require special purpose proxies to be built from class interfaces and would detract from the simplicity of general purpose proxies. However, proxies in languages with typed variables must be created from a suitable class - that is, from a class based on the class of the corresponding remote object. Therefore the class of the specific proxy needs to be available. In the case of Java, the proxy class is loaded dynamically at the time it is needed. In Orbix, the compiled proxy class implementations are loaded into the client. Arguments and results in RMI Recall that in RPC (CDK Chapter 4) arguments are passed by value in messages between client and server and may be defined as in or out according to whether they are passed from client to server or vice-versa. The type of the data to be passed in an argument can be defined in an IDL. See Section 3 on CORBA for a more detailed discussion of arguments in IDL. Note in particular that CORBA IDL allows ROIDs to be passed as arguments and returned as results of methods. When RMI is added to an object-oriented programming language, the semantics for passing of arguments requires some additional definition when method invocation is extended to include RMI. For example, in Smalltalk every entity is an object and has an OID, therefore all arguments and results are represented by OIDs. Therefore it might seem natural to decide that all arguments in the RMI that supports Distributed Smalltalk should be passed as ROIDs. But implementations of Distributed Smalltalk generally passed immutable values (e.g. integers) by value to avoid unnecessary RMI. Java RMI treats arguments and results as follows: When the type of a parameter is defined as a remote interface, the corresponding argument or result is always passed as a ROID. The use of a ROID as an argument always arises as the result of an invocation of a method in a proxy with an OID as argument. The return of a ROID arises when an invocation of a method in a remote object returns the ROID of an object and a proxy is established if necessary. Other non-remote objects may be passed by value if they are serializable that is, they implement the Serializable interface by specifying how to marshal and unmarshal themselves. Which objects can be accessed by remote method invocation? A typical object-oriented program has two characteristics that are relevant when we consider the addition of RMI to an object-oriented programming language: Objects may be implemented with a wide range of sizes, including very small ones. Objects are generally highly inter-connected and objects invoke one another via their connections. See Figures 5 and 6.

9 Object-based Distributed Systems 9 There have been several alternative approaches to deciding which objects can be accessed by RMI: i Any object can be accessed by RMI. This approach was adopted in Emerald [Jul et al. 1988] and in Distributed Smalltalk [Bennett 1989]. It has the advantage that programmers do no need to be aware of distribution when designing an application. But there are possible performance disadvantages due to excessive RMI since programmers are not concerned with whether objects are local or remote. ii Two sorts of objects are available: remote objects and local objects. This has been implemented in a variety of ways, but in all of them, programmers have to make decisions as to which objects will be remote. In languages designed for distributed programming, remote objects are represented by a special keyword (e.g. Clouds [Dasgupta et al. 1988], Argus [Liskov 1988]) In C++ based systems, remote objects may be provided in the form of classes which may be subclassed according to the needs of applications (Arjuna [Shrivastava et al. 1991]). In Java a remote object must belong to a class that implements an interface that is a subclass of the Remote interface. Therefore the programmer must define a subclass of the Remote interface and then implement it in an application class which is a subclass of RemoteObject. After this they need to use an interface compiler to generate proxies and skeletons. iii An interface definition language (e.g. CORBA IDL) is used to define the interfaces of remote objects and the programmer is responsible for using an interface compiler to generate proxies and skeletons and link them with client and server programs. An important issue in a distributed object system is to relate the unit of distribution, migration or replication to the objects in the system. Consider the first two of the above approaches (the third is discussed in the later section on CORBA): i In the first approach, the object - that is the instance of a class is the unit of distribution. With this approach, objects may be placed at any convenient node and object migration is relatively simple. ii In the second approach, only those objects that are defined as remote objects may be accessed by RMI. Generally a remote object will be connected to numerous local objects which it invokes in order to carry out its methods. Thus the unit of distribution is a remote object together with the local objects on which it depends. In some cases, local objects may even be shared by remote objects. For example, in Figure 5, O1 and O2 are remote objects and they share O3. If one of the remote objects, say O2, together with the connected local objects needs to be re-located, an immediate problem arises with respect to O3 - should it become a remote object or should it be replicated?

10 Object-based Distributed Systems 10 O1 O2 O3 Figure 5. Remote objects O1 and O2 share local object O3 Locating objects Most ROIDs are acquired as results of RMI. However, a distributed object system needs to provide at least a simple name service that records the mapping from string names to ROIDs. The result of looking up a remote object by string name is the arrival of a proxy containing a remote object identifier for use in subsequent RMI. Some systems provide a means of locating objects from their ROIDs. For example, the Clouds system (CDK Section 18.7 and [Dasgupta et al. 1991]) and the Emerald system [Jul et al. 1988] use a cache/broadcast scheme in which each workstation holds a small cache of ROID-tolocation mappings. If a ROID is in the cache, that address is tried for the invocation and will fail if the object has moved. To locate an object that has moved or whose location is not in cache, the system broadcasts a request. This scheme may be enhanced by the use of forward location pointers which contain hints as to the new location of an object. Dynamic binding Where the language itself e.g. Smalltalk or Java always uses dynamic method binding in local method invocation, dynamic method binding should also apply to RMI. Local method invocation in Smalltalk allows any message to be sent to any object, but an exception is raised when a matching method cannot be found. Distributed Smalltalk can extend this to RMI by providing the general purpose proxies described above that forward all messages to their remote objects. Java RMI provides dynamic binding as a natural extension of the local case. We now consider the remote case in an example that is similar to the C++ collection of shapes given above to illustrate dynamic binding in the local case. The method used above was to find out the number of elements in the collection and then to retrieve the perimeter of each in turn. That method is not suitable in a concurrent environment - for example where different clients may access the collection concurrently - because one client may be accessing a particular number of elements one by one, whilst another client adds or removes elements. In the following example, clients are provided with the ROID of an enumeration of the elements that is unaffected by changes made by other clients. Suppose that we have the following classes of Java Remote interfaces - that is interfaces that inherit from the Remote interface: ShapeList - whose methods include Enumerate, addcircle and addrectangle. RemoteEnumeration- an enumeration on a collection of shapes. See Figure 15. Shape and Circle, Rectangle etc which extend Shape

11 Object-based Distributed Systems 11 A client program that has the ROID of an instance of ShapeList may use remote invocation of the Enumerate method to get an ROID of an instance of RemoteEnumeration. The client program may then use RMI to invoke the operations hasmoreelements and nextelements in the remote RemoteEnumeration object e. Note that the return value of nextelements is of type Object. ShapeList ashapelist; // assign ROID to ashapelist e.g. by using a binder RemoteEnumeration e = ashapelist.enumerate(); while (e.hasmoreelements()){ Shape ashape = (Shape) e.nextelement(); float f = ashape.perimeter (); The remote invocation of the method nextelement() causes a ROID of an object in the collection to be returned and assigned to the variable ashape. The ROID may refer to a subclass of Shape, e.g. Rectangle or Circle. The remote invocation of perimeter is carried out by the method in the class of the remote object that receives the message - that is, dynamic binding applies. Dynamic binding in RMI is discussed further in the sections on CORBA and Orbix. Garbage collection in a distributed object system If a language e.g. Java or Smalltalk supports garbage collection, then any associated RMI system should allow garbage collection of remote objects. Distributed garbage collection is generally achieved by cooperation between the existing local garbage collector and an added module that carries out a form of distributed garbage collection, usually based on reference counting. The aim of a distributed garbage collector is to ensure that if a ROID is still held anywhere in a set of distributed objects, then the object itself will continue to exist, but as soon as no object any longer holds a ROID, the object will be collected. Whenever a ROID enters a site, some object there will hold it for a time (e.g. in Figure 4, Site S holds the ROID of object A). The site where the object lives (Site T in our example) should be informed of the reference at site S. Then later when there is no longer a ROID at S, Site T should be informed. The distributed garbage collector can cooperate with the ROID module by recording how many sites hold remote ROIDs for each remote object and informing other sites about the adding and removal of ROID of their objects. When an object no longer has either local or remote references, it is collected by the local garbage collector. This algorithm requires additional measures to deal with the unreliability properties of messages in distributed systems. For example, in our example, Site S sends two messages to Site T: addroid(a) followed later by removeroid (A). Potential errors are caused by the wrong ordering of these two messages or their failure to arrive at all. If a removeroid is lost, then an object survives when it is no longer needed. If an addroid is lost, then an object may be collected prematurely. See [Shapiro and Ferreira 95] and [Birrel, Nelson and Owicki 95] for details of a distributed garbage collection algorithms. In Java RMI, the ROID module in the Java Virtual Machine cooperates with the local garbage collector to provide distributed garbage collection.

12 Object-based Distributed Systems 12 Architectures Distributed object systems may adopt the client-server architecture. In this architecture, objects are managed by servers and their clients invoke their methods through proxies. To allow for chains of related invocations, objects in servers are generally allowed to become clients of other servers. Objects can be replicated in order to obtain the usual benefits of fault tolerance and enhanced performance. The replication of objects close to their point of use is particularly important for interactive applications. This may be achieved by placing object replicas in several servers and using totally ordered multicast to keep them up to date. (See CDK 11.3 and 15.4 for a discussion of object replicas which are modelled as state machines). The Clouds system and Shapiro s Larchant system [Shapiro and Ferreira 95] use distributed shared memory (CDK Chapter 17) in order to replicate objects at the point of use. The Emerald system experimented with object migration with a view to enhancing the performance and availability of objects. They even introduced call-by-move and call-by-visit in which object arguments might migrate to the caller s site (and in the case of visit, return). 1.3 Requirements of multi-user applications Multi-user applications are intended to enable users to carry out cooperative work by means of shared data. Objects are a convenient abstraction for representing shared information, for example, the contents of a document or a technical drawing on which several users are working. Object persistence, activation and passivation Information that is to be shared must be long-lived so that it survives even when no one is currently working on it. Some applications require that the information should survive for periods of several years. Therefore an important requirement is that objects are guaranteed to live between activations of processes, unlike objects in conventional object-oriented programs. Such objects are called persistent objects. Persistent objects are generally managed by persistent object stores which store them in a flattened form on disk while they are not in active use. Persistent object stores are also useful for single user applications. In general a persistent object store will manage very large numbers of persistent objects, of which only a small proportion are in use at any particular time. Persistent object stores generally manage their persistent objects by leaving them on disk until they are needed and if necessary activating them when they are invoked by other objects. Some interesting work on persistent Java is currently in progress [Jordan 1997] and [Atkinson et al. 1996]. Activation is generally designed to be transparent - that is, the sender of an invocation message should not be able to tell whether the object is already in main memory or has to be activated before it is invoked. Persistent objects that are no longer needed in main memory can be passivated - that is, they are saved on disk. In some cases, persistent objects may be copied to disk even when they are still needed in main memory so as to provide fault tolerance. Again passivation is generally designed to be transparent - the persistent object store uses some strategy for deciding when to passivate objects. For example, it may do so in response to a request in the program that activated the objects, for example at the end of a transaction or when the program exits.

13 Object-based Distributed Systems 13 Persistent object stores generally attempt to optimise passivation schemes by saving only those objects that have been modified since the last time they were saved. It is generally difficult to discover when objects are modified without either altering the interpreter as in persistent Java or by making the programmer responsible for calling a method to inform the system when an object has been modified as in Arjuna [Parrington et al. 95]. Persistent object stores generally allow collections of related persistent objects to have human readable names. The human readable name may for example, be a pathname as in Arjuna or it may be a url as in Texas [Singhal et al. 92]. In practice, each human readable name is actually associated with the POID of a particular object, which would generally be the root of a collection of objects. For example, for the collection of objects in Figure 6, the name would be associated with O1, which is the root. Each persistent object within a collection has a persistent object identifier (POID). Application programs are provided with methods for registering the correspondence between human readable names and POIDs and for looking up POIDs by name. Thus a program accesses the POID of the root of a collection of objects by name and may then access the other objects indirectly via the root object. Identifiers for persistent objects A POID contains sufficient information to locate the corresponding persistent object within a persistent object store, which is generally organised as a set of partitions stored in files. The POID might for instance contain two parts - one to identify the partition containing the object and another to identify it within the partition. The design of POIDs should allow partitions to be moved between files and persistent objects to be moved within a partition. For example, both parts of the POID could be logical identifiers rather than actual partition names and offsets in partitions. For example, a persistent object store can map logical partition identifiers onto actual offsets in files and each partition can contain a table that maps each logical object number to its offset within the partition. When objects are activated, POIDs are translated to OIDs and when objects are passivated, OIDs that they contaain are translated to POIDs. This translation process is sometimes referred to as pointer swizzling. It is supported by a POID table that relates local OIDs to POIDs. The table ensures that there is a one-to-one correspondence between OIDs and POIDs. As an example of the use of the POID table during activation, suppose that a program uses a name to look up object O1 in Figure 6 and then invokes one of its methods. The following steps are carried out: i) check whether its POID is already in the POID table, ii) if not create a new uninitialised object and add its (OID, POID) pair to the POID table, iii) initialise the instance variables of the new object from the values acquired by unflattening the corresponding instance variables in the persistent object store. Two of the instance variables of O1 contain references to O2 and O3. Each of these is represented by a POID in the persistent object store and the corresponding instance variable must be given an OID, so steps (i) and (ii) are repeated for each of them. By this stage, O1 is completely initialised, but two of its instance variables contain the OIDs of uninitialised objects. Activation is generally performed on demand, in which case, step (iii) of activating object O2 or O3 will not be performed until one of its methods is invoked. Flattening and unflattening persistent objects The process of flattening a persistent object is similar to marshalling in that the instance variables need to be written out in a flattened form that can be unflattened at a later stage to produce an

14 Object-based Distributed Systems 14 activation of the object. The paper [Hamilton et al. 1993] on the Spring System discusses the difficulties of flattening objects and alternative approaches to this problem. If the language provides a facility to enable the programmer to find out the structure of a given class, then flattening can be done automatically by the persistent object store. Some languages, including Java 1.1 and Smalltalk provide reflection. Reflection makes it possible to enquire about the structure of a class with a given name, for example to get the names and the types of its methods, constructors and instance variables. Reflection also makes it possible to invoke the constructors and methods of a class with a given name and to assign values to its instance variables Reflection is provided in Java 1.1 and is also available in Smalltalk. The procedure that flattens objects will obtain the class of the object, then obtain each of the instance variables in turn and serialise it according to its type. Whenever it encounters an OID in an instance variable, it treats it in a special way as follows. It consults the POID table to see whether there is an entry for the OID, if there is one, then it uses the corresponding POID. If there is no such entry, then it creates a new POID and makes a new entry in the POID table for what is a new persistent object. During the flattening process, the POID table is used to ensure that if collections of objects share some common objects, there is only one copy of each of the shared objects. For example, if O1 and O2 in Figure 5 are both persistent objects, then there should be only one copy of O3 in the persistent object store. Without the POID table, there would be two copies. For languages with reflection, objects can be reconstructed provided that their class is available. The instance is created from the class and then the value of each instance variable is unserialised according to its type. Persistent object systems based on languages without reflection require the programmer to implement procedures for flattening and unflattening objects. This is the case for the Arjuna system which is based on C++. Arjuna provides a pair of virtual marshalling methods (restore_state and save_state) that need to be over-ridden by the programmer in terms of methods provided for the basic data types. When an object needs to be activated, the restore_state method is called. When a transaction commits, the method save_state is called for any objects that have been modified. Even in C++, flattening can be done automatically if debugger information is used to obtain the types of the instance variables of objects. Which objects are persistent? Passivation should be applied only to new persistent objects or to those whose values have changed during the running of the program. There are basically two approaches to deciding whether an object is persistent or not: the persistent object store maintains some persistent roots and any object that is reachable from a persistent root is defined to be persistent; the persistent object store provides some classes on which persistence is based - persistent objects belong to their subclasses. The first approach is used by persistent Java and by Larchant [Shapiro and Ferreira 95]. Persistent object stores that use this approach make use of a garbage collector to dispose of objects that are no longer reachable from the persistent roots.

15 Object-based Distributed Systems 15 The second approach is used by Arjuna where the persistent objects are based on C++ subclasses that provide recovery and transactions. As its language is C++, there is no garbage collector and unwanted objects must be explicitly deleted. Location of persistent objects In the simplest cases, persistent objects can be accessed only by looking them up by name as described above. If the name is a url then its location is included and the persistent object store can be accessed without further ado. If the name does not include a location, then we need some form of distributed name service which maps names onto their current locations (see Chapter 9 for a general discussion of Name Services). The Spring Name Service [Mitchell et al. 1994] maps names to objects in directorylike structures called contexts. Concurrency control and transactions The fact that users are sharing objects in order to perform cooperative tasks implies that a shared object may be invoked concurrently on behalf of different users. When methods run concurrently there is a risk that their effects may cause inconsistency in the object. A simple way to ensure that an object keeps consistent is to make its methods atomic. CDK Section 12.1 explains atomic methods in the context of a simple server. The Java language provides synchronized methods if an object has synchronized methods, then only one of synchronized method may be executed at a time. In Section 1.1, we explained that an action in an object-based program generally consists of a several related invocations on a set of objects, resulting from a single initial invocation. Thus, as in Figure 6, O2 O4 O1 O5 O3 Figure 6. A related set of remote method invocations in which we assume that each object executes a serial program, object O1 invokes a method in O2, which then invokes methods in O4 and then O5. Finally, O1 invokes a method in O3. The possibility of such sets of related nested invocations suggests that consistency may require that sets of nested invocations should be atomic. CDK Section 14.2 discusses nested transactions which were originally designed as part of the Argus distributed object system [Liskov 1988]. Some distributed object systems, for example Arjuna, [Shrivastava et al. 1991, Dixon et al. 1989]] provide an explicit transaction facility by means of C++ classes. For example a class Transaction has separate subclasses to deal with concurrency control and recovery. Object protection Like any shared data, objects need to be have suitable protection mechanisms enabling their secrecy and integrity to be maintained as necessary. Access control and authentication can be

16 Object-based Distributed Systems 16 applied to distributed objects. An example is Secure Network Objects, [Leendert van Doorn et al. 1995]. Access control could be applied at the level of remote objects. For example each principal could be allowed access to a particular subset of the methods of a particular remote object. However, the inter-connectedness and sharing of objects can lead to problems in the definition of security. For example in Figure 5, O1 and O2 are remote objects that share access to the local object O3. There is a danger that O3 can become a covert channel between O1 and O2 since there is no guarantee that the access rights specified for O1 and O2 will provide consistent access to O3. 2 CORBA The OMG (Object Management Group) was formed in 1989 with a view to encouraging the adoption of distributed objects systems in order to gain the benefits of object-oriented programming for software development and to make use of distributed systems which were becoming widespread. By this time, client-server architectures were very widely used. (See CDK Figure 1.10). To achieve their aims, the OMG advocated the use of open systems based on standard object-oriented interfaces. They introduced a metaphor: the object request broker whose role is to help a client to invoke a method on an object. This role involves locating the object, activating the object if necessary and then communicating the client's request to the object which carries it out and replies. The CORBA specification includes an IDL (interface definition language). Object interfaces are defined in IDL, thus enabling clients and objects to be implemented in different languages. Note that interface languages were already widely used to enable clients to communicate by means of RPC with servers in different languages. See CDK Section 5.2. A major difference between CORBA and earlier RPC systems such as Sun RPC is that CORBA IDL is intended for defining interfaces to remote objects whereas the earlier IDLs were designed for specifying interfaces to servers. Therefore CORBA IDL provides a type allowing ROIDs to be passed as arguments and results in RMI. Another difference is that CORBA IDL provides a special client interface which allows client messages to be bound dynamically at run time. In 1991, a specification for an object request broker known as CORBA (Common Object Request Broker Architecture) was agreed by a group of companies including DEC, HP, Hyperdesk, NCR, Object design and Sun [CORBA 1991]. The CORBA 2.0 Specification is available on the OMG Web site Web at the following url: The OMG home page and a list of technical reports can be accessed from there. 2.1 CORBA's Object model The CORBA specification defines an abstract object model similar to the one described in Section 1.1, but their model has clients as well as objects. Thus, clients send request messages to remote objects which carry out methods. Objects, like servers, are encapsulated and therefore the data representation and the code of an object is hidden from clients. Clients in CORBA are not necessarily objects. They can be any program.

17 . Object-based Distributed Systems 17 Each remote object has an IDL interface specifying the methods that may be requested by clients. The interface specifies the signature of each method, giving the types of its parameters and results. Each remote object has an ROID which is used by clients when making requests to perform its methods. A request message specifies the identifier of a recipient remote object, a method, and some parameters *. The reply conveys results and sometimes exceptions. CORBA IDL interfaces are unlike class interfaces in that they do not provide methods (like constructors) for creating objects or methods (like destructors) for destroying objects. But objects can be created or destroyed as part of the effect of a method in the interface. Clients can be provided with ROIDs of new objects as the results of remote method invocations. Servers generally contain a collection of objects, one or more of which is a remote object. As a server runs, it may creat new remote objects and return their ROIDs to clients. Objects in servers are allowed to become clients of other remote objects, thus enabling clients to perform invocations that cause chains of related actions on distributed objects, as illustrated in Figure 7. CORBA does not state anything about the semantics of remote objects or how they are implemented because it was designed to provide services based on existing software, for example, the so-called legacy applications and object-oriented databases. It achieves this by using an IDL interface and a suitable object adaptor. The role of an object adaptor is to make an object suitable for its methods to be invoked by clients. Client ROID ROID Server A B C ROID Server D E F Figure 7. Clients and objects in servers Each of the distributed objects systems mentioned in the first section of these notes defines an execution model for all objects, making no distinction between client and server. For example, Clouds uses DSM, thus enabling object sharing with copies located close to the point of use. Emerald makes its objects the unit of distribution and migration. Argus and Arjuna provide objects with concurrency control and recovery. CORBA does not provide transactions or any form of concurrency control or recovery. Nor does it provide any form of object replication, which limits the effectiveness of interactive programs. Client software can be designed with caches, but the design of a cache is difficult when the semantics of server objects are unspecified. In particular, CORBA IDL does not support the ability to provide a copy of an object. According to the authors of [Orfali et al.] OMG has defined 16 services of which 11 now have agreed standards. The standards for these services are described fully in their book. One of these services (POS - the persistent object service) allows objects to be passivated and activated using * CORBA states that an optional parameter can contain a context. We omit this from our discussion.