Unbundling Active Functionality

Stella Gatziu1, Arne Koschel2, G?nter von B?ltzingsloewen3, Hans Fritschi1

1Department of Computer Science, University of Zurich {gatziu, fritsch}@ifi.unizh.ch 2Forschungszentrum Informatik (FZI), Karlsruhe {[email protected]} 3Swiss Bank Corporation, {[email protected]}?

?. This author's work was performed during his stay at FZI Karlsruhe.

Abstract New application areas or new technical innovations expect from database management systems more and more new functionality. However, adding functions to the DBMS as an integral part of them, tends to create monoliths that are difficult to design, implement, validate, maintain and adapt. Such monoliths can be avoided if one configures DBMS according to the actually needed functionality. In order to identify the basic functional components for the configuration the current monoliths should be broken up into smaller units, or in other words they could be "unbundled". In this paper we apply unbundling to active database systems. This results in a new form of active mechanisms where active functionality is no longer an integral part of the DBMS functionality. This allows the use of active capabilities with any arbitrary DBMS and in broader contexts. Furthermore, it allows the adaption of the active functionality to the application profile. Such aspects are crucial for a wide use of active functionality in real (database or not) applications.

1 Introduction

Active functionality, as it is offered today by active database management systems (active DBMS), is the ability to react not only after an explicit request from the application or the user, but also when a specific situation of interest has occurred in the DBS or its environment. The basic notion of active DBMS are Event/Condition/Action-Rules (ECA- Rules), meaning WHEN a certain event occurs and IF a given condition holds THEN a certain action is executed.

In order to offer active functionality, new components (so-called activity components) implementing tasks like rule management and execution are required in addition to the known components of a DBMS.

Today, activity components are developed for a particular DBMS. By implementing the activity components as an integral part of a DBMS, active functionality is rather tightly coupled to the DBMS behind it . Thus, the active DBMS becomes part of large monolithic pieces of software. Such software is difficult to implement, validate, maintain and adapt. Even where active DBMS have a layered system architecture with the activity components residing ?on top? of a conventional DBMS the active

functionality remains tightly interconnected and as such bound to the particular target DBMS.

In either architectural approach, a substantial effort is required to adopt active functionality for various DBMS. It is close to impossible to develop activity mechanisms that can be ported from one DBMS to the other. Today, few commercial DBMS offer restricted active mechanisms while the more expressive ones are only found in research prototypes.

Moreover, active functionality tightly coupled to a concrete environment (a particular DBMS environment) hampers its adaption to changes in the information technology scenery. Just consider the present change of information systems in environmnets with several (existing and newly developed) heterogeneous and distributed information sources. Active mechanisms, e.g., complex situation monitoring or cooperation and coordination should take into account heterogeneity and distribution.

A further weakness of the tightly coupling of active and conventional database mechanisms is that active functionality is not usable on its own, i.e., without the ?added? DBMS features. However, active functionality is also needed in applications which require either no database functionality at all or just some like persistence. Thus, active functionality should be offered not only as part of the functionality of a DBMS, but also as a separate service which can be combined with other services like a persistence service. In this way, users could develop ?lean? solutions without any overhead due to unneeded components.

In this paper, we investigate the provision of active database mechanisms as an individual service. In other words, we unbundle active functionality from the DBMS. Thus, we follow a general direction that database research is currently about to take, namely to provide individual database management services that can be used and combined in a variety of ways and in a variety of environments [1, 2, 4, 11, 24].

We first discuss the advantages of unbundling active functionality. We then show how the unbundling process may take place. We start with a domain analysis of active DBMS-style active functionality. The main task is the identification of components and the cooperation between them. This leads to several (architectural) configurations. Each of these configurations is sufficient for one (or maybe