A Metaobject Protocol for Fault-Tolerant CORBA Applications M.-O. Killijian, J.-C. Fabre, J.-C. Ruiz-Garcia LAAS-CNRS, Toulouse S. Chiba University of Tsukuba, Japan Abstract: The use of meta-level architectures for the implementation of fault- tolerant systems is today very appealing. Nevertheless, all existing fault-tolerant systems based on this approach have used a general-purpose metaobject protocol (MOP) or are based on restricted reflective features of some object-oriented language. According to our past experience in this field, we define in this paper a suitable metaobject protocol, called FT-MOP, for the implementation of fault- tolerant meta-level architectures. The use of FT-MOP for building a fault-tolerant system or for the implementation of fault tolerance strategies is left open to the system designer. We explain in this paper how to realize a specialized runtime MOP using compile-time reflection and describe FT-MOP in details. Because of the unavoidable use of CORBA in distributed object systems and its interesting properties, this MOP is CORBA compliant: it enables the execution and the state evolution of CORBA objects to be controlled and enables the fault tolerance meta- level to be developed as CORBA software. 1 Introduction The implementation of fault tolerance in object-oriented systems has been investigated using various approaches, either based on the use of inheritance [Detlefs et al. 1988, Shrivastava et al. 1991] and reflection [Agha et al. 1993, Garbinato et al. 1995, Fabre & Pérennou 1998]) or investigating their implementation on/within CORBA runtime supports [Landis & Maffeis 1997, Moser & Melliar-Smith 1997, Felber et al. 1997]. Reflective architectures have been developed in various application fields and research areas [Stroud and Wu 1996], in particular regarding dependability issues. The use of reflective ideas [Maes 1987] and metaobject protocols (MOPs) [Kiczales et al. 1991] provides many interesting properties, such as transparency and separation of concerns. Reflection enables an object-oriented application to be controlled at a higher level of abstraction, the meta-level. Mechanisms previously developed as standard and object- oriented libraries or else integrated into an operating system or into an ORB are developed at the user level as meta-level software with this approach. Beyond transparency and separation of concerns, this approach also provides visibility of the mechanisms that can be easily customized for a given application or system configuration using object-oriented techniques. Nevertheless, to our knowledge, most of the examples are based on existing general-purpose metaobject protocols or restricted reflective features of some object-oriented languages. They have thus to cope with their limits. The corner stone of a fault-tolerant reflective architecture is the MOP. We thus propose a special purpose MOP to address the problems of general-purpose ones. The definition and the implementation of an appropriate runtime metaobject protocol for implementing fault tolerance into CORBA applications is the main contribution of the work reported in this paper. The proposed solution takes advantage of both reflective ideas and CORBA for implementing fault tolerance. We show that compile-time reflection is a good approach for the development of a specialized runtime MOP. This MOP, called FT-MOP (Fault Tolerance MetaObject Protocol), is sufficiently general to be used for other aims (mobility, adaptability, migration, security). FT- MOP provides a mean of dynamically attaching fault tolerance strategies to CORBA objects as CORBA metaobjects, enabling thus these strategies to be implemented as CORBA software. The first objective of FT-MOP is to control the object behaviour and state. However this MOP cannot cope with all non-functional requirements; hard real-time aspects for instance, as discussed in [Mitchell et al. 1997], cannot be handled with this MOP. Although, FT-MOP is very language dependent (C++ today) it can be adapted to other object-oriented languages, e.g. Java. In practice, the fact that such a MOP is language-dependent is mandatory in fault-tolerant computing as explained in the paper. In Section 2, we describe the basic concepts for implementing a given runtime MOP using compile-time reflection. We describe in section 3 the distributed object model we consider and the requirements for implementing fault tolerance using a runtime MOP. Section 4 mainly describes the design and the implementation of FT-MOP. Section 5 briefly describes other approaches and related work. 2 Building a Runtime MOP The main objective of this section is to describe how to build a specialized runtime MOP for fault-tolerant systems. We describe first our motivations according to past experience in building fault-tolerant systems using meta-level architectures and we introduce both compile- time and runtime reflection for the implementation of FT-MOP. 2.1 Motivations The implementation of fault tolerance was previously done in FRIENDS [Fabre & Pérennou 1998] using a general purpose runtime MOP. We have shown that the use of a meta-level architecture is very attractive for implementing flexible fault-tolerant systems; the FRIENDS system provides very interesting properties such as transparency, separation of concerns, composability, etc. Because of these properties, application objects can gain fault tolerance (and/or communication security) according to their needs and metaobjects (i.e. fault tolerance strategies) can be developed independently and easily customized according to different fault assumptions and system configurations. Although runtime reflection is often costly in terms of performance, it has been shown in previous experiments reported in [Fabre 1998] that the inherent cost of fault tolerance mechanisms by replication is several orders of magnitude higher than the cost of handling the object-metaobject interaction at runtime. However a general purpose MOP is not always satisfactory. With the general purpose runtime MOP used in FRIENDS (OpenC++ V1), we have been faced to some limits. For instance, handling sub-objects in open C++ V1 was a problem; an object attribute defined by a class and previously declared as reflective (// MOP reflect declaration) imposes the definition of the appropriate packing function to be handled at the meta-level (e.g. for checkpointing). A second drawback of Open C++ V1 was the inability to control inherited methods in application objects. For instance, inherited methods cannot be trapped by this MOP. All these problems relates mainly to the lack of important meta-information; this was in particular true for handling the state of objects. Actually, the handling of the object state is an important issue. In most of object-oriented fault tolerant systems (reflective or not) the state of application objects is not obtained automatically by the system software. In all these examples, two virtual functions are provided by inheritance to the application programmer (e.g. SaveState and RestoreState). The programmer is responsible for implementing these two functions (overriding them) later called by fault tolerance mechanisms. It is thus assumed implicitly that the state of application objects is correctly defined by the application programmer. The correct behavior of the fault tolerance mechanisms relies thus on this assumption. One of the aims of FT-MOP is to tackle the problem of user-defined (inherited) functions for handling the state of application objects. Although some restrictions apply in the current implementation (our objective is not to cover all possible features of a given object-oriented language, C++ presently), according to some programming conventions, FT-MOP is able to handle this state information automatically. Another drawback in FRIENDS is the link between objects and metaobjects which is statically defined at compile-time; metaobjects cannot be changed at runtime. Due to the MOP used in FRIENDS, an application object is encapsulated in a metaobject, together within a single runtime entity. The dynamic adaptation of the fault tolerance strategy according to different operational conditions and fault assumptions was not possible with this MOP. Having the object and the metaobject in separated runtime entities connected by a runtime MOP is the approach investigated here. The metaobjects can thus be changed now at runtime without compiling again the application objects. Additionally, another drawback of the FRIENDS system is that it is not CORBA compliant. These are the main reason for the development of a customized runtime MOP for fault tolerance, compliant with CORBA and able to handle the internal state of objects (variables and objects). Similar limits with general purpose MOPs or reflective features can be observed in other reflective fault-tolerant systems, e.g. GARF [Garbinato et al. 1995] based on reflective features of Smalltalk and MAUD [Agha et al. 1993] based on the actor model and the Hal language. 2.2 Compile-time and runtime MOPs Metaobject protocols are a reflection-based technique to make a compiler (or an interpreter) extensible. For example, a C++ compiler with a MOP takes two C++ programs to produce a single object file. One is an ordinary source program, and the other is a C++ program that customizes the compiler and makes extended language mechanisms, such as distribution and fault tolerance, available from the source program. To distinguish the two programs, we call the former one a base-level program, and the