Toward a Semantic Event Service for Distributed Active Database ...

Toward a Semantic Event Service for Distributed Active Database Applications Christine Collet Genoveva Vargas-Solar Helena Grazziotin-Ribeiro y fChristine.Collet, Genoveva.Vargas, [email protected] IMAG-LSR, University of Grenoble, BP 72 38402 Saint-Martin d'Heres, France.

Resume

Cet article propose une approche pour la construction de services d'evenements pour des applications bases de donnees actives. Dans un premier temps, nous introduisons les dimensions qui caracterisent la de nition, la detection, la production et la noti cation d'evenements distribues. Dans un second temps, nous presentons le service d'evenements parametrique QUETZAL autorisant la speci cation de dierents modeles (de detection) d'evenements. Cette approche donne plus de exibilite dans la gestion des evenements en fonction des besoins des applications. Notre service repose sur le principe de consommationproduction facilitant ainsi la communication et la collaboration de composants distribues tels que les applications classiques, les transactions bases de donnees, les detecteurs d'evenements primitifs et les outils de noti cation d'evenements.

Mots-cles : Bases de Donnees Actives, Regles Actives, Decomposition des fonctions actives, E venements distribues, Services d'evenements distribues. Abstract

This paper proposes an approach to build event services for active database applications. It introduces dimensions to characterize distributed event de nition, detection, production and noti cation. The core of our approach is a parametric event service called QUETZAL that has three interfaces, each of them implementing the given dimensions as parameters. Therefore, dierent event (detection) models may be de ned simply by giving values to these parameters. Such an approach provides exible de nition, detection, production and noti cation of events according to application needs. Since our service is based on a consumer-producer principle, it can be combined with any producer and consumer, facilitating in this way communication and collaboration between distributed components such as classical applications, database transactions, primitive event detectors or event noti cation tools.

Key words: Active Databases, Active Rules, Unbundling Active capabilities, Distributed Events, Distributed Event services.

1 Introduction The major idea in active databases is to add a reactive mechanism as ECA rules. An ECA rule is an association of an Event type, a Condition and an Action. Event types describe situations that may occur and that have to be monitored for processing a rule. They are  y

Supported by the CONACyT of the Mexican Government. Supported by the CAPES of the Brazilian Government.

generated internally or externally with respect to the system and detected by it. Conditions are generally predicates on database states expressed with a query language. Actions can be any sequence of operations on or outside the database. Generally speaking, rule processing is handled in a speci c environment de ned as an active database application including transactions. Many active database systems models or prototypes have been proposed [WC96, Pat98]. As discussed in [CC98] it is not reasonable to provide active functionalities able to ful ll the requirements of every application. Therefore, as suggested in [GKBF98] the unbundling of active mechanisms from the DBMS should be extended to the unbundling of the active capabilities. Such an approach provides more exibility for developing applications needing active functionality and not necessary database functionality. From the wide variety of proposals for event detection and management in database systems [MZ95, Cha97, Pat98] one may nd dimensions characterizing the event speci cation and the event detection or production processes [WC96, Dia95, DGG95, Pat98]. However distribution has not been widely introduced in active database environments and particularly in event management [Lia97]. Even if rules may reference data at multiple sites, or that each site may process rules, assumptions are made on events handling. Usually, only local visibility is achieved; global visibility may be achieved either through the existence of a central event manager to which any event of the system is communicated or by the cooperation of local event managers [Cha97]. To characterize such events, one may answer questions such as: What is an event? still a point in time ... with which global time? How to extend the event speci cation language for considering the \distribution" dimension? How to compose events coming from several distributed sources? How to notify them to several sources? How to de ne the order between events and to manage the delay in receiving events? This paper tries to give answers to these questions. An event contains a certain type of information, which is valid, depending on the events producer, during a certain period of time and within a speci c context. Events allow dierent kinds of applications to interact with each other. In this context, events do not simply represent instantaneous, low level operations, they become messages containing information meaningful for a group of producers and consumers. Figure 1 illustrates event processing. It includes a de nition phase during which events concerning a given application are described using an expression (type). The detection and production processes monitor the application execution to detect and recognize events. These processes detect and produce events previously described. Usually, events are explicitly signaled or detected by a monitoring (detection) mechanism. Since we place our approach within a exible and general context, (adaptable to transactional and non transactional applications) independent from the Database Management System (DBMS) control, we consider a third operation: noti cation. It allows the noti cation of events under dierent modes and communication protocols depending on the information needs of event consumers. For the time being, only few works have appeared proposing a framework allowing the integration and the interaction of distributed active (database) applications through an anonymous event passing communication. In this paper we introduce an event model that speci es dimensions characterizing how distributed events are de ned, how they are detected and produced and also how they are noti ed. Our model extends related concepts de ned in active database management systems for a distributed and heterogeneous context. In such a context autonomous systems exchange information to accomplish cooperative tasks. Then we present the parametric event service QUETZAL, that implements

notify event

signal events

Production

Clients

composite events primitive events

primitive events events monitoring

Detection Notification

event types definition

Definition

Figure 1: Event Processing Phases our event model. The parametric approach introduces some semantics allowing the service to be con gured for adopting dierent event models. The remainder of this paper is organized as follows. We introduce dimensions of the sub-models composing our event model. The event de nition model speci es basic concepts related to events in a distributed environment (Section 2). The detection and production model establishes the way events are detected and communicated by producers (Section 3). The noti cation model describes the communication protocols established by event consumers (Section 4). Section 5 presents the event service QUETZAL and shows how it is used to introduce distribution and the unbundling process into an existing active system. Section 6 compares our proposal with other existing works. Finally, Section 7 concludes this paper and introduces some future research directions.

2 Event De nition Generally speaking event types are expressions for describing events and therefore events are instances of an event type. Time cannot be dissociated from events since an event occurs at a point in time. The approach to represent a point in time, is to de ne a reference moment and a unit (i.e. second, minute, hour, etc.). Active databases event models use a discrete representation: the Gregorian calendar and a discrete time domain isomorphic to this calendar. Each point of this domain is represented as a non-negative integer along an axis having 0 as the origin and 1 (the inde nite time point) as the end. In distributed environments time and events acquire another dimension due to the lack of a global view of the system. Thus, events in distributed contexts are associated to global time that should be computed using methods such as those proposed in [Sch96, LMS85]. For global time we also adopt a discrete representation. Table 1 describes dimensions associated to event de nition. Events characterization and semantics depend largely on their source (dimension 1). Events may come from internal sources, in this case they represent operations inherent to their producer (e.g. data manipulation, transaction operations ); from abstract sources such as the user (e.g. the mouse) or a program (e.g. exception raising); and from external sources such as the operating system (e.g. the clock). An event type is an expression describing a class of signi cant occurrences of interest (events) produced over a validity time interval [Col98], also called a monitoring interval (dimensions 2). An expression may describe primitive or composite events. Primitive event types characterize basic operations concerning data, the environment, operations execution, an application, etc. Composite event types characterize events produced by applying operators such as sequence, conjunction, disjunction, negation, parallel, etc. to

Dimension

Value

internal abstract external 2 event type primitive composite 3 validity time interval explicit implicit 4 event instance instantaneous duration-based 5 occurrence time implicit computed 6 event context yes no

1 event source

Table 1: Dimensions of event de nition other events. Composite event type expressions indicate the operators that are used and we assume some (classical) semantics for these operators. Our future work will consider the de nition of semantics for each operator through speci c dimensions within dimension 2. The validity time interval de nes the interval during which instances of the actual type (i.e. events) may be recognized (dimension 3). It is denoted by [sv , ev ] where sv and ev correspond respectively to the starting point in time for event recognition and the ending point for event recognition. This interval can also be speci ed as a period (i.e., every two seconds). The validity time interval can be de ned either explicitly at event type de nition or implicitly, using the points of time associated with the unit of production of events (see Section 3). Let us consider the update of the attribute salary of Employee instances, denoted by UPDATE(Employee->salary, integer). When processing such an operation for an Employee instance e, i.e update(e->salary, s), the operation might be associated with an interval [t0, t1] that corresponds to the beginning and the end of the operation. If we consider that the validity time interval includes [t0, t1 ] then three event types may be de ned depending on the granularity of signi cant situations we look for: 





(UPDATE(Employee->salary, integer), [sv , ev ]) : this event type considers events (signi cant situations) that take place during the interval [sv , ev ]. These types represent the whole operation process (methods, programs, etc.), and characterize duration-based events [Ron97]. (before, UPDATE(Employee->salary,integer), [sv , ev ])): this event type represents the fact that the processing of an update operation is requested. It depicts the transition operation update non active -> operation update in process. (after, UPDATE(Employee->salary,integer), [sv , ev ])): this event type represents the fact that the processing of an update operation has nished. It depicts the transition operation update active -> operation update nished.

Note that we may characterize the whole update operation process (methods, programs, etc.), i.e a duration-based event, or the fact that the processing of an update operation is requested ( nished), i.e. an instantaneous event (dimension 4). As we already said an event is associated with a point in global time called the occurrence time (dimension 5). This point in time belongs to the validity interval of the

Dimension

Value

session local transaction global transaction program basic operation continuous recent 8 production mode chronological cumulative none 9 event detection protocol pull push 10 event detection mode synchronous asynchronous

7 unit of production

Table 2: Dimensions of events detection and production corresponding event type. For example, (before, UPDATE(e->salary,s), ti ) is an instance of the type (before, UPDATE(Employee->salary,integer), [t0, t1])); [t0, t1] de nes the interval of update processing and ti 2 [t0, t1] is the point in time when the processing of the update starts. Due to the characteristics of time in distributed environments, the occurrence time has to be computed in terms of global time. The above event example is an instantaneous event as it represents the fact that an update of the salary of Employee e is requested and does not represent the corresponding update process. The occurrence time of a composite event corresponds to the moment in which it is produced. The occurrence time of a composite event ec is by de nition the occurrence time of the last primitive event that makes ec happen. It depends on the production mode and on events production order. Next section gives more details on these aspects. Further, we consider that the occurrence time of duration-based events corresponds to the interval [sv , ev ]. When an event is detected or produced, runtime information is collected: event type, occurrence time and actual parameters values. This information de nes the event context (dimension 6).

3 Event Detection and Production In general, to characterize event detection and production it is necessary to state - in which conditions events are produced, - how often they have to be detected, - under which protocol they are detected and produced, - what kind of operations they represent, and - for how long these events are representative. Table 2 shows the dimensions associated with event detection and production. Events are produced under a unit of production, that corresponds to a source (application) granularity (dimension 7). Possible granularities are session, transaction, basic operation, and composed operation (program). The session corresponds to the complete execution of an application. For an object system, an operation can be a method call that can be composed by basic operations (objects creation, attributes updates, etc.). Events can be produced within ACID centralized transactions or within distributed or non classical transactions [HGM87, Mos85]. In most active systems, the validity time interval (dimension 3) is the same as the one associated with the unit of production. Primitive events are all \detected", they are not subsumed to production modes. The

Dimension

11 event visibility 12

13 14 15

Value

restricted unrestricted transaction commit noti cation time detection with con rmation detection with(out) con rmation derived validity time interval unit of production persistence scope until consumed until next detected no noti cation protocol pull push noti cation mode synchronous asynchronous

Table 3: Dimensions of events noti cation production mode of events was introduced by Snoop [Cha97] under the name of parameter context (dimension 8). Dierent production modes depict possible compositions of primitive events with dierent semantics, according to application needs (dimension 8). There are four modes: recent, chronicle, continuous, cumulative which are largely treated in [Cha97]. Combining events in dierent production modes is directly concerned with event ordering and consequently with global time. This can be achieved assuming that local clocks can be synchronized with a  precision. Events can then be totally ordered, provided that the granularity g of the global time-base is greater than  [Sch96]. To achieve detection it is necessary to establish interaction protocols depending on producers characteristics (dimensions 9 and 10). Events are detected under pull and push communication protocols, with a synchronous or an asynchronous event detection mode. The synchronous (asynchronous) mode implies that producer executions are (not) interrupted by the detection mechanism.

4 Event Noti cation Basically, noti cation is characterized by noti cation modes, used to deliver and store event instances. Table 3 presents the dimensions associated to these operations. Event noti cation takes place with respect to event visibility (dimension 11). The visibility of event types (also called event granularity) speci es the scope of events consumption. Events can be consumed in an unrestricted way: consumers are noti ed about all instances of an event type (e.g. every instance of UPDATE(Employee->salary, integer)). Consumers may impose restrictions over the noti cation of the instances of a speci c event type (restricted) (e.g., all instances of UPDATE(Employee -> salary, integer) produced 1 hour before my login). This is achieved through lters that may be speci ed as masks such as in [Ron97]. These lters are conditions including predicates and temporal expressions that events should verify. The noti cation time dimension characterizes the time when events can be noti ed to consumers. Event noti cation can take place at:  transaction commit: events of type E produced within a transaction T are noti ed at commit time (validated events). In this case events may be characterized with

the following composite event type (sequence): ((begin transaction T1 , E , commit transaction T2) where T1 = T2).  detection without con rmation: events are noti ed as soon as they are detected. If events are produced within a transaction they are noti ed even though the transaction has not yet committed.  detection with con rmation: events are noti ed as soon as they are detected and then they are validated by a con rmation event (i.e. a transaction commit event from the producing transaction).  derived: noti cation mode for composite events depends on the nature of the producing event. It is the last component that determines its production and its noti cation mode. Note that the dierence between transaction commit noti cation mode is that it only considers the noti cation of events produced within a transactional context i.e intratransactional events, conversely detection with con rmation considers that events may be con rmed by events comming from dierent contexts i.e inter-transactional, or interapplication case. Noti cation semantics at transaction commit time relies upon the transaction model or on the protocol adopted. Distributed operations delimited by transactions can be achieved by a two (three) phase commit protocol. In this case, noti cation at transaction commit is done after the second phase. Under other transaction models [HGM87, Mos85] this noti cation mode corresponds to the end of a component transaction (SAGA). Events can be either persistent or fugitive. Events may persist for a given period of time (persistence scope) after their detection/production and noti cation or they may \disappear" after noti cation. The persistence scope may encompass the unit of production, the validity time interval, the period of time comprised from detection until consumption, or until a newer instance does not arrive. In the latter case, newer instances substitute older ones. Finally, events are noti ed under the pull and the push communication protocols, with a synchronous or an asynchronous event noti cation mode.

5 Toward QUETZAL This section presents the main characteristics of our semantic event service QUETZAL. The service follows a producer-consumer principle, where producers and consumers exchange events anonymously under the CORBA pull and push communication protocols [OMG97]. Producers and consumers can be processes, objects, transactions, applications, operating systems. With such an approach, our service achieves the homogeneous conciliation and integration of non transactional contexts with transactional ones. Also, it may ful ll dierent information needs. QUETZAL implements the models described in previous sections by turning dimensions into parameters. Dierent event management models may be speci ed by giving a value to some parameters. Parameter domains have been de ned as subsets of values for the corresponding dimensions because we only consider those values that cannot be expressed in terms of others. The general architecture of QUETZAL is given in Figure 2. It shows that our service provides an event type de nition language as well as interfaces for specifying event management models and for allowing subscriptions of clients (producers and consumers)

Subscription

Notification

Event Type

Consumers

Producers

Production

Detection

Figure 2: General architecture of QUETZAL to prede ned event types. Such an approach allows exible and parametric de nition, detection, production and noti cation of events according to application needs. Figure 3 shows how the QUETZAL service has been used to introduce distribution into the Native Active Object System (NAOS)[Col98] and to participate in the unbundling process of this system. It replaces the Event Manager and allows the de nition and execution of distributed active rules. Rules may be triggered by inter-transaction and inter-applicative events. Also, the event service introduces the interaction of (non) O2 applications running on dierent (same) O2 server. signals events QUETZAL notifies events

Event Manager

notifies events signals events

signals events

Execution Engine

conditions and actions execution O2API

Application

notifies events

Event Detector

O2C

O2Engine O2system

connection

connection O2 Application

O2 Application

network communication previous event handling communication with the DBMS

Figure 3: Unbundling NAOS The NAOS event type de nition [CC96] is supported by the event de nition language of QUETZAL. Further, the NAOS event detection process is based on two principles: i) as primitive event detection must be ecient and ne-grained, it is therefore placed inside the database it is supposed to monitor ii) detection is based on a subscription mechanism; only events for which an event type subscription has been submitted are signaled. Therefore, events are detected in an asynchronous mode. Those events concerning DBMS and transaction operations, and time are detected using the pull communication protocol via the event detector (i). On the other hand, abstract events have to be signaled by their producers under the push protocol. NAOS introduces detection contexts that allow computation of validity intervals [CC96]. The intervals are not given explicitly and depend on the unit of production of events. This unit is the (triggering) transaction, except for temporal and user events for which it is a session. Futher, composite event detection depends on semantics of operators and on production modes. NAOS adopts a continuous production mode.

Distributed active rules consume events coming from dierent transactions and applications consume events coming from other applications. For this reason, includes global transaction and program values. This allows the detection of inter-transaction events as well as events produced during programs execution. The unrestricted visibility allows the construction of inter-transaction events, as well as the consumption of events coming from dierent transactions (by active rules) and the noti cation of events coming from dierent applications. Distribution adds the notion of information reliability to events consumption (by active rules). How are we sure that an event consumed by a rule was produced by a transaction that nally commits? Depending on performance and information needs, events can be noti ed at detection time with(out) con rmation or at transaction commit. Internal events are noti ed either at commit transaction time or at detection time with validation. In this way, we ensure data consistency after the execution of distributed active rules. User and applicative events are noti ed at detection time without validation because they are not directly related to data consistency. Due to performance needs (of active rules execution), events are noti ed under the push communication protocol. Event noti cation supports both synchronous or asynchronous noti cation modes in order to ful ll rules execution modes (e.g. for immediate rules executed in the same transaction noti cation is synchronous; for diered ones noti cation may be asynchronous).

6 Related Work Even though events manipulation is largely extended across dierent domains, the event service concept has come up recently. Event services intend to answer to information exchange needs present in cooperating systems, with autonomy and generality. The range of approaches is wide, it goes from simple routing of low level signals to message delivering, respecting dierent communication protocols and messages processing. We do not intend to make an exhaustive list of relevant approaches, concepts and services. We focus our attention on two types of approaches : those that intend to open the scope of active functionalities to non database applications and those that are oriented towards the adding of distribution to active DBMS. In [GKBF98] functional components of active DBMS are broken up into a number of autonomous cooperative services. They de ne an event service and a rule service that cooperate establishing a policy of interaction. Selected individually and con gured independently, services enable the use of active functionalities in dierent environments. The event service records events, maintains a (persistent) event history and detects composite events. The C2oein [KKB+ 97] proposes a widely con gurable service set for active functionality in CORBA-based heterogeneous, distributed systems. The system is con gurable with respect to services types and features, services interaction protocols, distribution parameters, etc. The FRAMBOISE project [FGD97] proposes a construction system for the development of ECA-services, that are decoupled from a particular DBMS. TriGS Active Database System (Trigger system for GemStone) [KRR98] supports composite event detection. Composite events are produced independently of the origin of its components. Events that occur within an application transaction are immediately signaled, independently of a proper termination of the producing transaction. [Lia97, Cha97] propose and implement a Global Event Detector for Sentinel. This system detects and manages events across applications. It communicates with local event detectors through RPC and socket-based communication to detect global events.

The OMG event services [OMG97] speci cation de nes an asynchronous communication with multiple event suppliers and consumers under the pull and the push communication models. Multiple interaction of consumers and suppliers is achieved using an event channel. Sophisticated event channel implementation is needed to provide a kind of event router or some additional event semantics. A general analysis shows that existing works may be classi ed into two groups. The rst group focuses on unbundling active capabilities into extensible services. The second group oers concepts and mechanisms for distributed active databases. Our approach tries to integrate both aspects. It oers event management for dierent environments and frameworks and at the same time it introduces distribution into active database systems.

7 Conclusions and Future Work We presented here an approach to build a exible and semantic event service for distributed and heterogeneous systems. We rst de ned our event model with several dimensions that characterize event de nition, detection, production and noti cation. This model extends event concepts used in active databases in three ways: (i) it handles dierent event management semantics, (ii) it considers the distribution dimension and, (iii) it opens the event model scope towards domains such as the integration of cooperative applications, interaction of heterogeneous applications, data warehousing, etc. Then, we introduced our parametric event service named QUETZAL a powerful event broker suited for adopting dierent event models. The service oers dierent interfaces, each of them proposing parameters coming from the dimensions of our model. Event service interfaces are concerned with event speci cation, detection, production and noti cation processes. Event management for some producers and consumers can be speci ed simply by choosing a value for each proposed parameters among a set of already de ned values. The interaction between clients and the event service is achieved via a subscription interface. We conducted an experimentation with the NAOS prototype. We speci ed and implemented its event manager using our event service approach. Furthermore, we showed in which way the event service introduces the distribution dimension into NAOS. In conclusion, our main contribution is the de nition of a general event service that encompasses event characterization and management in various contexts { i.e. (non) transactional, centralized, distributed, etc. Further research directions include pursuing the implementation of our event service and extend this service in order that it can cooperate with a rule execution service [CRVS98] for the processing of distributed active rules and also with other kind of tools that necessitate event monitoring. We are also interested in de ning an algebra for distributed events. Another important research direction is to prove that our model is consistent { i.e., that it is de ned completely, with no ambiguities nor contradictions { by formally de ning it. Then, we think that it will be easier (using such a formal model) to identify several levels of event services depending on the characterization of application needs.

Acknowledgements Thanks to M. Adiba and N. Henry for their careful reading. Thanks also to P. Habraken, T. Coupaye and C. Roncancio for useful discussions about our work.

References [CC96] [CC98] [Cha97] [Col98] [CRVS98] [DGG95]

[Dia95] [FGD97] [GKBF98] [HGM87] [KKB+ 97] [KRR98] [Lia97] [LMS85] [Mos85]

C. Collet and T. Coupaye, Primitive and Composite Events in NAOS, Actes des 12iemes Journees Bases de Donnees Avancees (Cassis - France), September 1996. C. Coupaye and C. Collet, Semantics Based Implementation of Flexible Execution Models for Active Database Systems, les actes des 14iemes Journees Bases de Donnees Avancees (Hammamet- Tunisie), october 1998. S. Chakravarthy, Sentinel : An Object-Oriented DBMS with Event-Based Rules, Proc. of the SIGMOD (AZ, USA), ACM, 1997. C. Collet, NAOS, In Active Rules for Databases (Norman W. Paton, ed.), Springer Verlag, 1998, to be published. C. Collet, H. Ribeiro, and G. Vargas-Solar, Towards a Flexible Execution Model for Distributed Active Rules, In preparation, March 1998. K. R. Dittrich, S. Gatziu, and A. Geppert, The Active Database Management System Manifesto: A Rulebase of ADBMS Features, Proc. of the 2nd Int. Workshop on Rules in Database Systems, RIDS'95 Lecture Notes in Computer Science 985 (Athens, Greece) (T. Sellis, ed.), Springer Verlag, Athens, Greece, September 1995, pp. 3{17. O. Diaz, Dimensions of active database systems, Actes des 11emes Journees Bases de Donnees Avancees (Nancy, France), septembre 1995, pp. 3{22. H. Frithschi, S. Gatziu, and K.R. Dittrich, Framboise { an approach to construct active database mechanisms, Technical Report 97.04, Department of Computer Science, University of Zurich, Zurich, April 1997. S. Gatziu, A. Koschel, G. Bultzingsloewen, and H. Fritschi, Unbundling Active Functionality, ACM SIGMOD RECORD (1998). K. Salem H. Garca-Molina, Sagas, Proc. of the SIGMOD International Conference on Management of Data, May 1987, pp. 249{259. A. Koschel, R. Kramer, G. Bultzingslowen, T. Bleibel, P. Krumlinde, S. Schmuck, and C. Wein, Con guration Active Functionality for CORBA, Proc. of the ECOOP97 Workshop (Jyvaskula, Finnland), June 1997. G. Kappel, S. Rausch-Schott, and W. Retschitzegger, A Tour on the TriGS Active Database System - Architecture and Implementation, Tech. report, Johannes Kepler Univ. of Linz, Austria, 1998. H. Liao, Global events in Sentinel : Design and Implementation of a global event detector, Master's thesis, ECE University of Florida, Gainsville, USA, March 1997. Lamport L. and P.M Melliar-Smith, Synchronizing Clocks in the Presence of Faults, Journal of the ACM 32 (1985), no. 1, 52{78. J.E.B. Moss, Nested transaction. an approach to reliable distributed computing, MIT Press, Cambridge, MA, 1985.

[MZ95]

I. Motakis and C. Zaniolo, Composite Temporal Events in Active Database Rules: A Logic-Oriented Approach, DOOD'95 (Singapore), December 1995. [OMG97] OMG (ed.), The Common Object Request Broker Architecture and Speci cation, 1997, Object Management Group. [Pat98] N. W. Paton, Active Rules for Databases, Springer Verlag, 1998, to be published. [Ron97] C.L. Roncancio, Toward duration-based, constrained and dynamic event types, "Workshop on Active, Real-Time and Temporal Databases (ARDBT'97)" (Como, Italy), September 1997. [Sch96] S. Schwiderski, Monitoring the behavior of Distributed Systems, Ph.D. thesis, University of Cambridge, April 1996. [WC96] J. Widom and S. Ceri, Active Database systems - Triggers and Rules for Advanced Database Processing, Morgan Kaufmann Publishers, San Francisco, California, 1996.