Does Alerting have special Requirements for Query Languages? Annika Hinze Institute of Computer Science Freie Universit¨at Berlin, Germany
[email protected] Abstract Alerting Systems keep its users informed about new documents and events they are interested in. The power of such services depends on the expressiveness of the language used to define a user’s interest. In this paper, we show restrictions of existing languages and discuss additional language parameters. We will emphasize briefly the problem of different underlying time systems and propose a common profile structure that can serve as basis for a Profile Definition Language for Alerting.
1 Introduction In the last years, Alerting Systems (also called Event Notification Services) have gained strengthened attention. Several systems have been implemented, such as Springer Link Alert [13] and NiagaraCQ [3]. Users define their information need as a profile. The usability and power of alerting services heavily depends on the expressiveness of the profile definition language. Various languages have been implemented; they are often very simple and based on the Boolean model (e.g. [11]). Only some are more sophisticated and employ, e.g., an SQL-like syntax [9], or base on XML-QL [3]. The main focus of the existing services and evaluations regarding Profile Definition Languages for Alerting (PDLA) is the definition of the profile-query (cf. [2, 9]). That query part of a profile is matched against the event descriptions. Users can be interested in single (primitive) events or event combinations. Primitive events are described by event properties such as attribute value, time of event, or duration of a certain state of an object. Examples of query-profiles are QP1 Notify, if at the same time the temperature (in one of our greenhouses ) is more than humidity less than 40% for more than 20 minutes.
30Æ C
and
QP2 Notify about any three login attempts for the same user from different sites during a certain time period (e.g. 5min) The examples show that, in contrast to query languages, a PDLA has to consider time restrictions and resulting time-dependend parameters. In order to evaluate profile languages we define in Section 2 an event algebra, which describes the common features independent of a specific language syntax. The difficulties an implementation of that event algebra has to face are illustrated in Section 3. The problem sources are examined briefly in following Section 4. We conclude in Section 5 with the proposal for additional parameters to take into account.
2 Event Algebra We use an event algebra to describe the events a service offers to notify about. The coverage of that algebra is derived from the profile language considerations in [7]. An event algebra is an abstract description of the event concept of a service independent of the actual profile definition language. It enables the evaluation of the complexity of different services, supports the detection of inconsistent profile definition, and can serve as basis for an abstract implementation of a matching algorithm.
We consider primitive events and composite events that are formed by combining primitive events. Here we do not further distinguish types of primitive events. Besides other properties each event e has a time of occurrence t(e).1 In order to model composite events we employ event constructors. Here we extend the event algebra for active database systems as introduced in [5] in order to consider also the temporal demands on event compositions. The events e1 and e2 can be any primitive or composite event. The disjunction (e1 je2 ) of events occurs if either e1 or e2 occurs. As mentioned before, the composite event e3 := (e1 je2 ) also has a time of occurrence, which is here the time of the occurrence of either e1 or e2 : t(e3 ) = minft(e1 ); t(e2 )g. The conjunction (e1 ; e2 )t occurs when both e1 and e2 have occurred, regardless of the order. The conjunction constructor has a temporal parameter that describes the maximal length of the interval between e1 and e2 . (e1 ; e2 )1 refers to an event composition no matter the time of the composing events, it equals the original conjunction constructor as defined, e.g., in [5]. The time of the composite event: e3 := (e1 ; e2 ) is the time of the later event: t(e3 ) = maxft(e1 ); t(e2 )g. The sequence (e1 ; e2 )t occurs when first e1 and afterwards e2 occurs. Again, t defines the temporal distance of the events. The time of the event e3 := (e1 ; e2 ) is equal to the time of e2 : t(e3 ) := t(e2 ). The negation e1 defines a passive event; that means, that e1 does not occur for a given interval [tstart ; tend ℄ of time. The occurrence time of e1 is the point of time at the end of the period, t(e1 ) = tend (e1 ).
The model of a composite event now consists of (primitive or composite) events combined by event constructors. We additionally permit the Boolean operators of logical conjunction (^) and logical disjunction (_). Logical combinations of event compositions describe relationships among the terms. Logically combined terms form a name-space (there equal names (e.g. e1 ) identify the same event), whereas equal names combined only by event constructors define identical event descriptions and therefor a class of events. The logical conjunction (e1 ; e2 )t1 ^ (e3 ; e4 )t2 ^ (e1 ; e3 )t3 of event compositions requires that all composite descriptions have to apply. The event time of e = (e1 ; e2 )t1 ^ (e3 ; e4 )t2 ^ (e1 ; e3 )t3 is t(e) = max(t((e1 ; e2 )t1 ); t((e3 ; e4 )t2 ); t((e1 ; e3 )t3 )) and is determined by the event constructors. The logical disjunction (e1 ; e2 )t1 _ (e3 ; e4 )t2 describes that one of the given alternatives has to apply. The event time of e = (e1 ; e2 )t1 _ (e3 ; e4 )t2 is t(e) := minft((e1 ; e2 )t1 ); t((e3 ; e4 )t2 )g
The profiles given above can be modeled using the event algebra as follows: QP1 Notify immediately, if at the same time the temperature is more than 30Æ C and humidity less than 40% for more than 20 minutes. Here we define the primitive events informally: let e1 be the event that the temperature in our greenhouse raises to more than 30Æ C, e2 the event that the temperature sinks to less than 30Æ Celsius. Event e3 expresses that the humidity raises to more than 40% and e4 humidity sinks lower than 40%. We then have to observe the composed event e = ((e1 ; e2 )20min ^ (e3 ; e4 )20min ^ (e1 ; e4 )20min ^ (e3 ; e2 )20min ) QP2 Notify about any three login attempts for the same user from different sites during an interval of 5min: Define a profile for event e with e = (e1 ; e2 ; e3 )5min or e = (e1 ; e1 ; e1 )5min . 1
The time of events, that do not occur is set to
1.
3 Possible Complications Events can be observed by the Alerting System in an active or passive manner (cf. [7]). If only the query profile is given to the service, several difficulties and complications emerge. Missed Events Consider the new edition of a journal that is available via a specific URL (as done, e.g., by IDEAL-Library [12]). For the query profile ”Notify about all new articles once a week” problems occur, when short-living documents (e.g., 3 days) or files that are changed once a day have to be observed. Single steps of changes or even complete documents could be missed, e.g., if new documents appear and are deleted within one observation period length. The user is not necessarily aware of the mismatch of observation and update frequency. This problem remains undetected if users cannot express the desired granularity of event observation or on the other side the system gives no information about its observation type and frequency. The problem aggravates by use of service hierarchies. Correct time of event occurrence and completeness of the event information cannot be guaranteed. Falsified Events Several events occurring within an observation period can intensify or weaken each other. For example, at the recording of access statistics each new event can overwrite the value for the number of current users. Therefore, several changes of a document appear as sum or combination of changes. It is therefore not possible for the user to react to a single event. The falsification of the events is invisible and can lead to misinterpretation of the document development. Restricted Composite Events Users are not only interested in simple events but in composite events. That are combinations of events on objects or documents on (different) provider sites (e.g., two similar documents are published at different providers simultaneously). Composite event recognition therefore widely bases on the observation of various provider sources. This can require the interoperation of several alerting services to detect events on different sites. Composite events always base on a temporal combination of events. If event detection modes of providers and alerting services are not known to the mediating service it is impossible to recognize composite events properly. Additionally, providers and services can base on different time systems (affected by internal delays) and observation methods the mediating service has to be aware of. Restricted Interoperability Currently most alerting systems for, e.g., digital libraries are monolithic systems that do not interoperate with other systems. Most providers and publishing houses also implement their own systems. That systems often base on the assumptions that events do not have to be observed, but are reported by the invoker of the event (e.g. Elvin[11]). Future alerting systems will interoperate in a hierarchical or peer-to-peer manner (cf. [1]). In order to cover the high number of non-cooperative providers of objects and events, that will not actively inform the system of changed or new content, future services will widely base on observation of events. Examples are the Continual Queries project [10] and the Hermes Service at the Free University Berlin [4]. As already pointed out in the former paragraph interoperability of alerting systems permits detection of composed events. It also supports reuse of existing software and systems. Currently every service implements its own wrappers and observers for passive providers. The services and tools do not interoperate due to the diverse and proprietary interfaces and PDLAs. The definition of common interfaces and a common profile and source description format will support interoperability of the services. It gives services and its users the opportunity to select observers that match the user requirements best (choose the observer that provides the appropriate granularity, security, or reliability).
4 Problem Sources The problems outlined above have various causes. Here we briefly discuss a few details:
Observation Strategies Several sources can only be observed actively since the providers of the documents do not actively notify interested parties about changes within their repositories. Some providers offer a query interface that often lacks the opportunity to specify the retrieval for latest documents or even changes. The services therefore have to observe the sources on a regular basis. The observation mode does not naturally match the update frequency on the provider’s side. Timestamping Strategies Often the time of the event occurrence cannot be determined directly but has to be derived by the observer. Together with different observation modes the timestamping mode can vary widely. Conceivable is either timestamping by provider at the moment of query execution, or timestamping by observer. Depending on the observation mode the timestamp could be created, e.g., at the time of query invocation or response time. In both cases the transmission delay has to be considered. Underlying Time System Alerting Service and Providers often operate based on different time systems, such as internally or externally synchronized clocks. Many systems still base on simple system clocks that are neither synchronized internally nor externally. Each of the time systems has different accuracies and precisions. The interoperation of systems with different time systems leads to additional inaccuracies. Observers can be unreliable or base on various observation modes, some sources can provide better or faster results than others, some providers are more trustworthy than others. The influence of applied observation and timestamping strategies on the correctness of the event notification services has been evaluated in more detail in [6].
5 Parameter profiles: Controling Event Observation and Notification Besides the query part, profiles should also contain additional information that defines the methods of event observation and notification [7]. We call that part of a profile the parameter-profile. Parameterprofiles have not been studied in detail so far, even though their definition heavily influences the usability and the power of the notification service. Simple examples of parameter-profiles are PP1 Notify once a week but observe the changes twice a day PP2 Notify with an accuracy of the event time of 10ms and a maximal delay of 1s.. We propose a parameter-profile that contains the following components: Observation strategy: The observation strategy can be described by several parameters, such as the detection interval and the maximal timestamp delay and the maximal perception delay. The detection interval defines two points of time that are upper and lower boundary for the event-time, it is determined by the observation frequency and network delays. The maximal timestamp delay estimates the maximal time period between event and timestamp. The maximal perception delay measures the maximal time period between event and perception of the event by the service. Timestamping mechanism: As described before, several timestamping strategies are conceivable, such as timestamping at the start or end of the observation interval; or timestamping at the time of observation or perception. Time system: Time systems can be described by the parameters accuracy and precision. Accuracy defines the difference of local and reference clock; Precision defines the difference between local clocks using the same time system. Expected global accuracy and delay of the timestamp: These parameters depend on Observation and Timestamping Strategies as well as on the underlying time system.
Estimation of completeness of event information: This parameter specifies which portion of information about a given time interval is available.
Additional parameters are information about the used query language, time-policy for notification, content of notification, structure of notification, and the notification protocol. Solitary alerting services have to consider parameters as defined above in order to ensure a certain correctness and accuracy of the delivered information. Interoperating alerting services have to specify their operating restrictions and capabilities in order to enable mediating services the access to the event data. We therefore propose the integration of time system information into the profile languages and the definition of structured parameter information about the capabilities of a service. We plan to employ the introduced PDLA extension to develop a common interface for alerting services to enable hierarchically operating services or services interoperating within a network.
References [1] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf. Interfaces and algorithms for a wide-area event notification service. Technical Report CU-CS-888-99, Department of Computer Science, University of Colorado, October 1999. [2] S. Chakravarthy and D. Mishra. Snoop: An expressive event specification language for active databases. Technical Report UF-CIS-TR-93-007, University of Florida, Gainesville, Department of Computer and Information Sciences, March 1993. [3] J. Chen, D. DeWitt, F. Tian, and Y. Wang. NiagaraCQ: A scalable continuous query system for internet databases. In Proc. of the ACM SIGMOD Conf. on Management of Data, 2000. [4] D. Faensen, L. Faulstich, H. Schweppe, A. Hinze, and A. Steidinger. Hermes – a notification service for digital libraries. In ACM/IEEE Joint Conference on Digital Libaries, Roanoke, Virginia, USA, June 24-28 2001. [5] S. Gatziu and K. Dittrich. Events in an active object-oriented database system. In Proc. of the 1st International Workshop on Rules in Database Systems. Springer, September, 1993. [6] A. Hinze. How does the observation strategy influence the correctness of alerting services? In Proceedings of the 9. Fachtagung Datenbanksysteme in Bro, Technik und Wissenschaft, BTW 2001, March 2001. [7] A. Hinze and D. Faensen. A unified model of internet scale alerting services. In Hui and Lee [8]. [8] L. C. Hui and D. L. Lee, editors. Internet Applications. 5th International Computer Science Conference, ICSC’99, Hong Kong, China, December 1999, volume 1749 of Lecture Notes in Computer Science. Springer, 1999. [9] L. Liu, C. Pu, R. Barga, and T. Zhou. Differential evaluation of continual queries. In IEEE Proceedings of the 16th International Conference on Distributed Computing Systems, pages 458–465, Hong Kong, 27-30 May 1996. IEEE Press. [10] L. Liu, C. Pu, and W. Tang. Supporting internet applicatioons beyond browsing: Trigger processing and change notification. In Hui and Lee [8]. [11] B. Segall and D. Arnold. Elvin has left the building: A publish/subscribe notification service with quenching. In Proceedings of AUUG97, 1997. [12] IDEAL-Library. http://www.idealibrary.com/. [13] Springer Link Alert. http://link.springer.de/alert.
