Section 29.1. INTRODUCTION

29.1. INTRODUCTION

Today, database systems are central to the operation of most businesses. The volatile nature of business, especially in domains such as banking and telecommunication, implies that database systems need customization and evolution in line with changes in organizational and application requirements. Often, the concerns that need to be customized are crosscutting in nature. For instance, the transaction model governs the transformation of the database from one consistent state to another. The transaction policy is intertwined with locking, recovery, cache management, and synchronization policies [16, 28]. Similarly, the schema evolution model governing the modification of the conceptual structure of the database crosscuts the transaction model, the data storage and access mechanisms, and the version management policy [28, 29]. Organizations and applications have highly specialized, "local" requirements for such concerns. For example, one application might need a conventional isolation-based transaction model [8], while for another, a cooperative transaction model [36] might be the right choice. Similarly, for one organization or application, it might be desirable to only simulate data conversion on schema evolution [33], while for another, physical data conversion might be better [19].

In the presently dominant "one solution fits all" database design, such customizations can be expensive: systems lack the modularity necessary to localize the impact of changes. Trade-offs between modularity and efficiency, and granularity of services and number of inter-service relationships result in these concerns being spread across many parts of the database management system (DBMS) [31]. This results in systems with a largely fixed set of features, which compromises customizability. Organizations find themselves choosing either the costly and risky strategy of developing a new database system or revising their organizational and business practices to be compatible with their current database [23].

Layered architectures for database systems [12, 22] provide only a partial solution to the customization problem [31]. The intra-layer and inter-layer interactions in such systems simply shift the code-tangling problem to a different dimension [20]. For example, in the layered architecture proposed by Haerder and Reuter [12], concurrency control is spread across two different layers, with lock management and recovery mechanisms in the lower layer and transaction management in the higher layer. Consequently, customizing the locking or recovery mechanism in the lower layer has an impact on the transaction management component in the higher layer [31].

Aspect-oriented programming (AOP), with its inherent support for modularization and composition of crosscutting concerns, is an obvious solution to these customizability and evolution issues. This chapter discusses the application of AOP concepts to database systems and highlights how this can transform the way we develop and employ such systems. We focus on the potential of AOP techniques to improve customizability, extensibility, and maintainability of database systems. Like all other systems, database systems will benefit from an improved separation of crosscutting concerns throughout the software lifecycle. However, this chapter only provides an in-depth view of the role of aspect-oriented programming techniques in this context.

Section 29.2 introduces a general database model for an object-oriented database. We use the model as a basis for examples of crosscutting concerns at two levels: the DBMS level and the database level. We demonstrate how the crosscutting nature of these problems can adversely affect the customizability, extensibility, and maintainability of the database system. Section 29.3 offers a description of how aspect-oriented programming techniques can be employed to modularize and compose such concerns. The discussion draws mainly on concrete examples from the SADES object database evolution system [24, 30, 31]. SADES was built using a combination of three aspect-oriented programming techniques: an aspect language, composition filters, and adaptive programming [25]. Several examples are also derived from AspOEv: a customizable aspect-oriented evolution framework for object-oriented databases [11, 29]. Section 29.4 offers a discussion of the pros and cons of the proposed uses of AOP in database systems. Section 29.5 discusses other approaches to modularization of crosscutting concerns in database systems. We conclude in Section 29.6 by outlining how existing database systems may be incrementally evolved to incorporate the aspect-oriented approach.