Replication of CORBA Objects

ions. The OMG has published guidelines for designing object services and their interfaces [OMG97]. The service approach has also been adopted in the Distributed Object-Oriented Reliable Service (DOORS) [CHY+98], currently in development at Bell Labs. Our work on CORBA fault-tolerant services has signi cantly in uenced many of the proposals that have recently been made to the OMG in the context of its undergoing standardization e ort towards fault-tolerant CORBA [OMG98b]. 4 The Object Group Service 4.1 Overview The Object Group Service (OGS) is a CORBA service that provides group management and communication facilities in a CORBA environment. It is composed of a set of generic IDL-speci ed interfaces. With OGS, clients can send invocations to object groups without knowing the number and identities of group members. In addition, OGS provides support for transparent group invocations, allowing clients to invoke operations on object groups as if they were invoking singleton objects. OGS is based only on standard CORBA mechanisms and is thus portable to any compliant ORB implementation. OGS may be used from any programming language that is supported by CORBA, or from any system that supports the CORBA Internet Inter-Orb Protocol (IIOP). More precisely, the OGS environment speci es an architecture and a set of IDL interfaces for object group support, as well as a set of object services that provide various facilities for reliable distributed computing. OGS uses a component-oriented approach. Basic units of functionality are packaged as CORBA services, which represent distributed components. These services, which include distributed agreement protocols and detection of remote component failure, are used in the implementation of the group communication primitives (see Sect. 4.3). Note that the relationship between these di erent services are implementation dependencies, and are not expressed in the IDL interfaces. 4.2 Transparency A common goal of object-oriented middleware environments is to hide the lowlevel mechanisms used for remote invocations and object management as much as possible, to let the developer focus on the application-speci c problems. Similarly, when working with object groups, a desirable property is to hide the complex mechanisms used for group communication. This section describes the concept of transparency in the context of OGS and the underlying mechanisms used to provide it. Transparency in OGS. Transparency is the property of a system to be invisible, i.e., the degree to which application programs are unaware of the system. Transparency appears at di erent levels in the OGS architecture [GFGM98] and may be classi ed as follows: { Plurality transparency: the application objects have the illusion that they deal with singleton objects, although they interact with object groups. { Behavior transparency: the application objects are not aware of the replication policy and the protocols run by OGS in order to make the system behave consistently. { Type transparency: requests are performed via direct method invocations on the server's interface, rather than by explicit calls to a group communication API (e.g., via a multicast() operation), and explicit packing and unpacking of operation parameters into and from messages. Type transparency means that the application does not need to perform type conversions. Full transparency is achieved if the application program is completely unaware of the group service. OGS provides full client-side transparency, without even requiring the client code to be recompiled [Fel98]. The Bene ts of Transparency. Transparency provides a number of facilities which make it useful, if not necessary, to develop distributed applications with object groups. Some of the bene ts of transparency are outlined below. { Ease of use. Applications do not need to be written with replication in mind. { Less error prone. Application programmers do not need to write error prone code for inserting and extracting data into and from requests. { Reuse of existing code. Existing client code can be reused without modi cation. Server code requires only minor modi cations. Objects from existing frameworks can be made groupable by using multiple inheritance of interfaces and implementations. { Encapsulate behavior in the group. OGS knows about the operations invoked on object groups, and can associate di erent semantics to distinct requests on behalf of the object group. The protocols may vary depending on the invoked operation without the client's knowledge. The Limitations of Transparency. Client transparency is generally considered as a \good thing" for object replication. However, server transparency has several drawbacks for complex systems. When dealing with replica con guration, failure detection mechanisms, or advanced synchronization between replicas, explicit group management support is required. In some cases, transparent replication can make systems su er reduced performance due to the lack of control over how replication is performed. 4.3 OGS Components OGS implements group communication using a set of CORBA services. These services are not organized in a layered architecture, but as a set of orthogonal components with usage relationships between each other (component-oriented approach). Figure 5 presents an abstract view of the major components dened in the OGS architecture. Although this is not clearly visible on the gure, each component is speci ed independently and they all interact with each other through the ORB. The application may use any of these components directly. These components are: Join/leave groups Remove failed members Notify upon view change Reach agreement between a set of objects Distributed Consensus Group Multicast Unreliable group multicast Reliable group multicast Total order group multicast • • • • • • • Group Membership • • • • Monitor remote objects Notify upon failure Reliable asynchronous communication FIFO channels Monitoring Messaging Object Request Broker Operating System and Network Services Application Objects O G S C o m p o n e n t s Fig. 5. Overview of the OGS architecture 1. A Messaging Service that provides non-blocking reliable point-to-point and multicast communication. 2. A Monitoring Service that monitors objects and provides failure detection mechanisms in CORBA. 3. A Consensus Service that allows a set of application objects to solve the so-called distributed consensus problem [CT96]. This service is used to implement group multicast and membership protocols. 4. A Group Service that provides both group multicast and group membership. The dependencies between these components are implementation-speci c, and do not appear in the IDL interfaces of the services. All these components are described in details in [Fel98]. In the following, we focus on the group service only. 4.4 The Group Service The group service is the core of the OGS environment. It is the service that actually provides object group support, and which the application programmer has to deal with. It implements two functionalities: { Group membership manages the life cycle of object groups. It maintains the updated list of all correct group members. It provides support for joining and leaving groups, view change noti cation, and state transfer. A group membership service is generally associated with a failure detection mechanism for detecting group member failures. { Group multicast provides support for sending multicast invocations to all the members of a group, with various reliability and ordering guarantees. The group multicast and group membership services interact closely. In particular, multicast operations are de ned on object groups rather than on sets of unrelated objects, thus involving group membership. Therefore, both services are contained in the set of interfaces forming the group service. Group Membership. The role of a group membership service is to manage memberships in a distributed system on behalf of the processes that compose it. OGS supports dynamic groups, i.e., the composition of the groups can change over time. New members can join an existing group, explicitly leave it, or may be implicitly removed from the group because of a failure. Objects that wish to join a group do so by contacting the membership service, which updates the list of group members. Once admitted to the group, an object may interact with other group members. Finally, if the object fails or leaves the group, the membership service will again update the list of group members. Dynamic group membership involves two kinds of protocols: { A view change protocol, which is run each time the composition of a group changes. It ensures that every correct member of the group receives a view change noti cation, indicating the new composition of the group as a list of group members with mutually consistent rankings. View changes are totally ordered with each other. { A state transfer protocol, which is an atomic operation occurring during view change, when a new member joins an existing group. It consists in obtaining the state from a current group member, and giving it to the new member. This protocol ensures that the state of all group members is kept consistent upon membership changes. The view change protocol can terminate only after a state transfer is completed. The group membership interfaces de ne how OGS and group members interact. They are essentially composed of two types of objects (Fig. 6): (1) servicespeci c4 group administrator objects that enable group members to change their status in the group (e.g., join and leave the group); and (2) application-speci c groupable objects that enable OGS to call back to the application for view change and state transfer protocols. The GroupAdministrator interface is implemented by the service, and is used as a black box by the application. A group administrator is assigned to a single group at creation time, but there may be several 4 We disting