A Model of Alerting Services in Wide Area Networks

A Model of Alerting Services in Wide Area Networks Annika Hinze Institute of Computer Science Freie Universit¨at Berlin, Germany [email protected]

1 Introduction Since the number of scientific publications doubles every 10 - 15 years [8], there is strong need for the use of alerting services. An alerting service keeps the users informed about new documents and events they are interested in. An alerting service can be build on top of a low-level event notification service as used for distributed control mechanisms or device monitoring. Conceivable techniques are CORBA Event and Notification Service, Java Distributed Events and Messaging Service and others. The underlying model of these services differs from the conditions found in applications suitable for wide area networks, such as digital libraries. Here we provide a model for alerting services that considers the special constraints of this application area. The remainder of this paper is structured as follows: Section 2 introduces the main concepts of data dissemination services, Section 3 provides an overview of related research topics and existing notification services. Section 4 outlines the new model of alerting services. In Section 5, we conclude with the direction for future work.

2 Data Dissemination The application domain we consider covers such applications as stock tickers, common weather report channels, notification about new items in digital libraries or traveler information systems. The range of services for data dissemination reaches from awareness services (to keep replicated data consistent) to event-based infrastructure for distributed control. Alerting services connect providers of information and interested clients, they inform the clients about the occurrence of an event on provider side. Clients define their interest in personal profiles. The information about the events is filtered according to these profiles and notifications are send to the interested users. Figure 2 depicts the data-flow in an high-level architecture of an alerting service. (Keep in mind that the data-flow is independent from the delivery mode.) The tasks of an alerting service subdivide subscribe

publish Object of Interest

Event Data

Profile Alerting Service

Interested Party Notification notify

Figure 1: Data-flow in an alerting service

into the following steps: First the observable event classes are to be determined and offered to the clients. Then the clients profiles have to be defined and stored. The occurring events have to be observed. Before creating notifications the events have to be integrated in order to detect event patterns. After duplicate recognition the event messages have to be stored in order to enable efficient notification. According to a

given schedule, the clients have to be notified with acknowledgment handling, if possible. Besides single alerting services a growing number of unifying middleware services are being implemented. There, the user can subscribe and get access to diverse resources, the various notification schemes of the different provider services are unified for the user and the client’s privacy is protected. Within the mediating alerting service as proposed one can distinguish two data delivery components, between provider and service and between service and client. This components can be described as autonomous basic alerting services, Figure 2 displays this concept. The client registers at the mediating alerting service and defines register()

register()

Provider

Client

Alerting Service alert()

alert() subsribe

publish

Profile Object of Interest

Event Data

Alerting Service

Interested Party Notification notify

subsribe

publish

Profile Object of Interest

Event Data

Alerting Service

Interested Party Notification notify

Figure 2: Basic services within the mediating alerting service

the personal profile. The alerting service in turn registers at the alerting service provided by the cooperating provider. It defines a profile that contains all profiles given by clients to the service. In case of an event, the providers service informs the mediating alerting service and the service informs all clients whose profiles matched to the event.

3 Related Work Event Services support the asynchronous message exchange between objects. They depend on an eventbased infrastructure (such as JEDI [3]). Examples are event notification services (such as SIENA [2]) or the CORBA Event Service [9]. Alerting services can be build upon event services. This is especially use-full in the handling of asynchronous events. Event Action Systems are software systems in which events occurring in the environment of the system trigger actions. The reaction is performed according to some action specification defined by the users. The triggered actions may generate other events, which trigger other actions, and so on. The actions are, in contrast to common event-based infrastructures, relevant to human beings rather than notifications to other software components [2]. The alerting services considered here are closer related to event action systems than to common event-based infrastructures. An example of an event action system is Yeast [6]. Existing Models. The underlying models of event notification services and event action systems differ from the conditions in wide area network alerting services as found in digital libraries. As an example the events considered in the mentioned models belong to objects of interest that have limited numbers of states. An event can then be defined as a state transition. In the context of services such as digital libraries the events are state transitions of the repository that contains the objects of interest (e.g. the journals and articles). Existing models for alerting systems have the following drawbacks: The modeling of hierarchical data structures common in services such as digital libraries are missing. The consideration of data objects without a set of predefined states is crucial for the modeling of events in the context of databases. Event detection and handling according to a given time policy and handling of event patterns and duplicates is necessary. A general model for event-based architectures has been proposed by Rosenblum et al. [10]. The involved parties are considered as objects, the model introduces four types: object of interest, invoker, observer and the interested party (see Figure 3). An evaluation of different event models can also be found in [2, 11].

Invoker

Object of Interest

Observer

Interested Party

Figure 3: General event-based architecture

4 Event Handling and Notification Model In this section, an evaluation of some basic modeling principles under the special constraints of the considered application area will be provided. Then, we introduce the new model for alerting services.

4.1 Basic Principles Events. For Event Action Systems [6], events can be divided into two classes: time events and object events. Time events involve clock times, dates, and time intervals. Object events involve changes of nontemporal objects. For Alerting Services as considered here time events have no influence and therefore all observed events of these services are object events. We additionally distinguish active and passive events. Active events are state transitions of the database at a particular time; they are observer independent. State transitions in databases can be actions such as insert, delete or change of a data-object. In contrast, a state in the context of control systems is a defined attribute of an object that has a finite number of predefined values (e.g. the output of a logic circuit can be high, low or high-Z, an interrupt can be set or not). A state transition occurs if the attribute value is changed. In the context of databases1 the notion of state transition is in close relation to integrity constraints. Each transaction on the database underlies several constraints (such as the key of a tuple has to be unique) and the operations are accepted only if the constraints are fulfilled. Allowed operations transfer the database from a valid state to another valid state. This process is called a state transition. As final consequence both constraints and given set of values ensure an invariant state space. Passive events involve counters and object properties at a specified time, they have to be observed. Examples for event profiles are: ‘Send notification when the Z share has a value of X Euro for longer than Y days’ or ‘Send notification if the price of product Z has not changed for 10 days’. These passive events are appropriate for particular applications such as remote monitoring and control or stock tickers. In the context of digital libraries passive events are negligible. For active events we distinguish four types of profile definitions: (a) a set of identifiers for documents, journals in particular, (b) a set of keywords which can be either selected arbitrarily or from a thesaurus given by the alerting service, (c) a set of predefined groups of objects, such as scientific subjects, and (d) a query in a full-fledged retrieval language, that could even support relevance feedback or documents as queries (‘Find all documents like this one’). Additionally, it is possible to choose a database, either by defining the data-source in the profile or by subscribing to services from special suppliers. The simple case of profiles consisting only of object identifiers (so not all new data objects are observed) has been covered in the model in [5]. Additional parameters can be specified in a profile: the document parts the profile query terms should be matched against (e.g. full-text, abstract, metadata); time policy (scheduled or notification on event), notification medium (e.g. e-mail, desktop-icon) and content of notification (e.g. URL of full-text, abstract or complete document). Channel. The term channel is used by different models and applications. In the CORBA model, the event services decouples the bidirectional communication between the objects supplier and consumer. An event channel is an intervening object, that allows multiple suppliers to communicate with multiple consumers asynchronously [9]. CDF channels [4] are similar to television broadcast channels. They are 1

The datasets of the considered applications are handled here similar to databases.

a connection between one provider and a number of clients to submit data from providers to clients. In contrast to CORBA channels CDF channels have an observer function for the related objects. Other examples of the channel concept are Netcaster channels [7], that are very similar to CDF. Further evaluation of the implementation of alerting services with channels can be found in [5].

4.2 Model In this section, the new model for alerting services in wide area networks is described. An alert relation describes a relation between suppliers of data objects, clients and events the client wants to get notified about. A supplier can provide various databases. Clients define their interest in profiles P , where they specify the events on the databases they are interested in. The alert relation A is a relation between a set of databases B , offered by the suppliers, a set of clients C , and a set of profiles P . Customers may register or unregister for certain events happening on certain databases, the corresponding tuples are inserted into or deleted from the relation

A  B  C  P:

(1)

Clients can register for events for instance by subscribing to an event channel, such as CDF channels. According to this model a CORBA channel is only a communication medium and not covered by the following definition. An event channels is a projection2

E=

B;P

(A):

(2)

Active Events. Events can happen at any time t, they are caused by invokers that perform actions on the database. Observers detect events at discrete time ti . Invokers and observers are often part of the supplier, as the data reside on the supplier’s side, but other services could have that function as well (conceivable are active alerting services that search for information on supplier side). Observers can be triggered by the invoker or by the profile schedule. In connection with Carzaniga [1], we define that an object o matches an profile p as relation po (3) Let Oti

be a set of objects that is affected by the state transition in database b in the time interval (ti 1 ; ti℄. The clients which must be notified are Cti 1 ;ti = C (Ati 1 ;ti ) where 1 ;ti

A

ti

1 ;ti

=

A:B =b

(O

ti

1 ;ti

o

(

(A:P )

Ot

i

1 ;ti :o)

A):

(4)

An object can match a profile in the following ways: In the simple case the profile specifications, such as object-id or query terms match the object properties. Objects also can be composed of other objects, such as journals consist of articles. The matching of the compound objects can require further data inquiries or calculations. Databases of digital libraries often do not contain the full-text of journals but hyper-links to the providers (e.g. the publishing houses) and alerting services have therefore additionally to query the providers database. Passive Events. Let Pti 1 ;ti be a set of profiles that triggers an observer by its time policy in the time interval (ti 1 ; ti ℄ and are matched by time, counter or other profile conditions. The clients which must be notified are Cti 1 ;ti = C (Ati 1 ;ti ) where

A

ti

1 ;ti

= (P

ti

1 ;ti

o A):

(5)

Notification. Clients are notified according to the time policy given in their profiles, either scheduled or depending on the number of events. Therefore, event notifications have to be stored for a particular time. They also have to be evaluated to discover patterns or duplicates. Before sending notifications, they should be merged, in order to ensure that clients get only one notification at the time. 2

We employ the well known notation of the relational algebra.

As an example, we choose scheduled profiles, the clients want to be notified after an interval of 4t = k . Then the set of channels affected by the events that happened in (ti k; ti ℄ is

E

ti

k;ti

=  (A B;P

ti

k;ti

):

(6)

In the push model of alerting, the supplier is the active part. It has to inform all customers that have registered for event channels the supplier’s database participates. As described in Section 2, an alerting service can act as supplier. In the pull model the customers regularly check the event channels for which they are registered.

5 Summary and Outlook The model proposed here is a first step within a research project which evaluates different techniques for alerting services in wide area networks. The next step is to evaluate the several non-cooperating services on various abstraction levels. This gives the opportunity to compare the various implementational techniques and to classify them. There are already criteria and classifications for Internet-based services such as scalability and delivery methods, but they are not commonly used or commonly defined. Our research project will provide a set of classifications and criteria to evaluate implemented alerting services. These criteria are based on one hand on the theoretical model and on the demands of the providers and users. With the help of the criteria various techniques will be made comparable. The development of a design tool that supports implementational decisions is planned.

References [1] A. Carzaniga. Architectures for an Event Notification Service Scalable to Wide-area Networks. PhD thesis, Politecnico di Milano, Milano, Italy, December 1998. [2] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf. Design of a scalable event notification service: Interface and architecture. Technical Report CU-CS-863-98, Department of Computer Science, University of Colorado, August 1998. [3] G. Cugola, E. Di Nitto, and A. Fuggetta. Exploiting an event-based infrastructure to develop complex distributed systems. In Proceedings of the 20th International Conference On Software Engineering (ICSE98), Kyoto, Japan, April 1998. available at http://ftp.elet.polimi.it/people/ cugola/abstract.html#ICSE98. [4] C. Ellermann. Channel Definition Format (CDF). Technical report, W3C, Microsoft, 1997. submitted to the W3C on 09 March 97, available at http://w3.org/tr/NOTE-CDFsubmit.html. [5] D. Faensen, A. Hinze, and H. Schweppe. Alerting in a digital library environment – do channels meet the requirements? Technical Report Number tr-b-98-08, Freie Universit¨at Berlin, 1998. available at http: //www.inf.fu-berlin/inst/pubs/tr-b-98-08.abstract.html. [6] B. Krishnamurthy and D. S. Rosenblum. Yeast: A general purpose event-action system. Transactions on Software Engineering, 21(10), Oct.1995. [7] Netscape Netcaster. http://developer.netscape.com/software/netcast.html. [8] A.M. Odlyzko. Tragic loss or good riddance? The impending demise of traditional scholary journals. International Journal of Human-Computer Studies, 42:71–122, 1995. [9] OMG. CORBAservices: Common Object Services Specification. Object Management Group, November 1997. available at http://www.omg.org/corba/sectran1.htm. [10] D. S. Rosenblum and A. L. Wolf. A design framework for internet-scale event observation and notification. In Springer, editor, Proceedings of the 6th European Software Engineering Conference, volume 1301 of Lecture Notes in Computer Science, pages 344–360, Berlin, 1997. available at http://www.cs.colorado. edu/users/alw/AvailablePubs.html. [11] T.W. Yan and H. Garc´ıa-Molina. Distributed selective dissemination of information. In Proc. Parallel and Distributed Information Systems, pages 89–98, 1994.