29.2. CROSSCUTTING CONCERNS IN OBJECT-ORIENTED DATABASE SYSTEMSThe various concerns in an object-oriented database system are illustrated in Figure 29-1. Usually, an object database programmer or maintainer writes code in an object-oriented programming language for persistent objects and their class/type definitions in the same fashion as transient objects and classes/types. The exception to this style is that operations on persistent objects are encapsulated within transaction boundaries. The DBMS-level concerns are responsible for keeping the persistent and transient space consistent, both during database operation and its maintenance and evolution, in a fashion that is transparent to the application. Figure 29-1. Concerns at the DBMS level and database level in an object-oriented database system.The concerns in Figure 29-1 are divided into two levels, driven by the desire to separate data management concerns from the data itself. Some concerns such as distribution and security have been omitted for simplification:
Figure 29-1 also illustrates the intertwined nature of concerns at the two levels. The crosscutting relationship between the concerns tends to be multi-dimensional in nature. For instance, the evolution model cuts across the instance adaptation approach, the transaction model, and the version management policy. At the same time, the instance adaptation approach crosscuts the evolution model, the version management policy, and the locking scheme. Furthermore, at times, there is a dependency between the two levels (shown by the dashed lines in Figure 29-1) with a crosscutting concern at one level influencing its counterparts at the other level. 29.2.1. Crosscutting Concerns at the DBMS LevelEvolution of object databases imposes its own set of crosscutting concerns. The evolution problems are amplified by the close integration of object databases with object-oriented programming languages and the existence of complex user-defined data types. Changes to a class definition can invalidate not only its own objects but also definitions of its subclasses, their instances, and application behavior bound to the older class definition. Let us consider two examples of crosscutting evolution concerns at the DBMS level in detail: instance adaptation during object database evolution and the evolution model itself. 29.2.1.1 Instance Adaptation ApproachInstance adaptation is the process of simulated or physical object conversion across compatible class definitions on schema evolution. Instance adaptation is a crosscutting concern at both the DBMS level and the database level. It is essential to distinguish the instance adaptation approach from an instance adaptation routine. The former exists at the DBMS level. It is the code that bears a close relationship with the schema evolution model and defines the instance adaptation strategy for the system. The latter exists at the database level. It is the code specific to a particular class or its historical representation (depending on whether the evolution model supports change histories) and defines adaptation semantics for instances of the particular class definition. It can be an error handler [33], an update or backdate method [19], or a transformation function [20]. In other words, the instance adaptation approach identifies the type of routines to be used for instance adaptation and, on detection of interface mismatch between the accessed object and the class definition, invokes the appropriate routine with the correct set of parameters. Figure 29-2 shows the various elements in an object-oriented database system over which the instance adaptation approach needs to quantify (i.e., interface mismatch messages from the objects) and those with which it is tightly integrated (i.e., the evolution model, the version management approach, and the instance adaptation routines). This illustrates the crosscutting nature of the instance adaptation approach and how parts of it, for example, the detection of interface mismatches, are scattered across other concerns. Figure 29-2. Sequence of operations leading to instance adaptation in an object-oriented database.An instance adaptation approach simulating object conversion might be suitable for one system, while one that physically converts objects might be more appropriate for another [32]. At times, a hybrid approach might be desirable. However, the closely knit relationship with the evolution model and the instance adaptation routines (refer to Figure 29-2) results in a "fixed" instance adaptation approach whose customization or replacement by a new approach to suit local needs is expensive because
29.2.1.2 Evolution ModelThe second example of a crosscutting concern at the DBMS level is the evolution model. An object-oriented database system can employ one of several different evolution models:
Similarly to the requirements for instance adaptation, organizations can have highly specialized needs for evolution models. For one organization, it might be inefficient to keep track of change histories, hence making schema modification ideal. For another, maintenance of change histories and their granularity might be critical. The requirements can be specialized to the extent that custom variations of existing approaches might be needed. As shown in Figures 29-1 and 29-2, the schema evolution model is intertwined with other concerns, for instance, the instance adaptation approach and the version management mechanism. This makes such customizations virtually impossible. Even if the evolution model were decoupled from the instance adaptation approach and other overlapping concerns, most database system regard the schema evolution model and the schema implementation model as being mutually integral. Consequently, there is no clear distinction between the two. Customization of the evolution model can invalidate the whole schema and, in fact, the whole database. 29.2.2. Crosscutting Concerns at the Database LevelAnalysis of two crosscutting concerns at the database level, instance adaptation routines and links among persistent entities, illustrates how lack of modularization can adversely affect the customizability, maintainability, and extensibility of a database system. 29.2.2.1 Instance Adaptation RoutinesConsider the instance adaptation routines in an object database evolution system that employs a class versioning model for evolution and a simulation-based instance adaptation approach. This is the approach taken by the ENCORE system [33]. As illustrated in Figure 29-3, all the versions of a class are members of a version set. When the addition of an attribute or method generates a new class version, error handlers are introduced into all the previous class versions in the version set. These error handlers are triggered when an interface mismatch is detected between an object instantiated using an older class version (e.g., Person_V1) but accessed using a newer definition (e.g., Person_V3). The handlers simulate a conversion by returning a default value. Now consider the scenario where the behavior of the address handler in Figure 29-3 (c) needs to be modified. Since the handlers are introduced into the class versions directly, such a change impacts both Person_V1 and Person_V2. Figure 29-3. Crosscutting instance adaptation routines at the database level: (a) Initial class version; (b, c) Derivation of new class versions due to additive changes.The example in Figure 29-3 presents a very simple scenario that does not take inheritance of handlers from versions of superclasses into account. The situation is complicated by the fact that a large number of hierarchically related class versions can come into existence over the lifetime of the database. Let us assume that the instance adaptation approach at the DBMS level can be customized, for example, to use update/backdate methods [19] that physically convert the objects to bring them in line with schema changes. Such transitions produce a large ripple effect on the version sets of all classes as the handlers are removed and update/backdate methods introduced. 29.2.2.2 Links Among Persistent EntitiesAnother example of crosscutting concerns at the database level is that of links among persistent entities. Examples of such links are association and aggregation relationships among objects, version derivation links among object or class versions, inheritance relationships among classes (or their versions), and scoping relationships between classes and their members. Traditionally, information about links is embedded within the entities themselves. For example, following the database evolution theme, consider the meta-class that defines the structure and behavior of class objects in an object-oriented database. As shown in Figure 29-4 (a), the inheritance links are implemented as collections of references to superclass and subclass objects. Figure 29-4 (b) shows a simplified schema evolution scenario from a case study of a database central to the functioning of an adult education organization [23]. Prior to evolution, the class Person has two subclasses: Tutor and Principal. The subclasses collection in the Person class object contains references to the two subclass objects, while the superclasses collections in the subclass objects include references to the Person class object. When a new non-leaf class Staff is introduced, we must
Figure 29-4. (a) Traditional structure of a meta-class in an object database. (b) Modification of inheritance links in a schema evolution scenario.The number of entities affected on modification of a connection is m + n, where m and n represent the number of participating entities at each edge of the relationship (in this case, superclasses edge and subclasses edge). Consequently, introduction of new links or removal of existing links among entities (in the schema or otherwise) is expensive. Similarly, extensions to the set of metaclasses to include new types of entities in the system can also have a huge impact on existing data and meta-data, as metaclasses are often also linked using the same mechanism. |