RUBDES : A RULE BASED DISTRIBUTED EVENT SYSTEM

Ozgur Koray SAHINGOZ1, Nadia ERDOGAN2

1

Air Force Academy, Computer Engineering Department, Yesilyurt, Istanbul, TURKEY, o.sahingoz@hho.edu.tr 2 Istanbul Technical University, Electrical-Electronics Faculty, Computer Engineering Department, Ayazaga, 80626, Istanbul, TURKEY erdogan@cs.itu.edu.tr

Abstract. In the last years, event-based communication paradigm has been largely studied and considered as a promising approach to develop the communication infrastructure of distributed systems. RUBDES (Rule Based Distributed Event System) is a distributed event system that allows the use of composite events in publish/subscribe computational model. In this system, an event is represented as an object and a rule is represented as an expression or a function that is evaluated or executed depending on the occurrence of events. This paper presents the design details of RUBDES and usage of Rule Definition Language (RDL) to describe composite events and event filters.

1 Introduction
In the traditional client/server computing model, which is used in RPC and RMI, communication is typically synchronous, tightly coupled and point-to-point. As shown in Figure 1.a, clients invoke a method on the remote server and wait for the response to return. This type of communication requires clients and servers to have some prior knowledge of each other. With the use of mobile or large-scale systems, the need for asynchronous, loosely coupled and point to multipoint communication pattern arises. Event models are application independent infrastructures that satisfy communication requirements of such systems. Event-based communication generally implements what is commonly known as the publish/subscribe protocol. As shown in Figure 1.b, an event supplier (publisher) asynchronously communicates event data to a group of event consumers (subscribers), ideally without knowledge of their number and location. To receive event data, subscribers register to an event service with the definitions of the particular interested events. A definition can include a simple subscription message, a subscription message with filtering on events or a subscription message for composite events. In this paper, we present RUBDES which is a distributed eventbased system that uses Rule Definition Language (RDL) to define subscription criteria in the form of a rule and relies on dynamic queries for filtering operations. RUBDES uses a content-based subscription policy, thus enhancing the efficiency of the two main processes of publish/subscribe systems, namely, the publishing and delivering processes.

Client
Request Response

Publisher Publisher Publisher

Storage and management of subscriptions

subscribe() publish() unsubscribe()

Subscriber
notify()

Subscriber
notify()

Server
a. Client/Server

Publisher

-Event Serverb. Event-based

Subscriber
notify()

Fig. 1. Client/Server and Event-based Computing Models

The rest of this paper is organized as follows. In the next section, we present a classification of publish/subscribe systems with references to related work. Section 3 introduces the computational model of RUBDES. Section 4 focuses on event types and how Rule Definition Language (RDL) is used. Section 5 presents an evaluation of the performance of the system. Our conclusions and plans for future work are presented in Section 6.

2 Publish/Subscribe systems
Publish/subscribe programming paradigm is characterized by the complete decoupling of producers (publishers) and consumers (subscribers). The event service that provides message transfers between publishers and subscribers can be decomposed along three dimensions, time decoupling, space decoupling, flow decoupling. Publish/subscribe systems can be classified into four groups according to their subscription mechanism. Each one is discussed in detail below, with references to representative work. Channel-based subscriptions: The simplest subscription mechanism is what is commonly referred to as a channel. Subscribers subscribe or listen to a channel. Applications explicitly notify the occurrence of events by posting notification to one or more channels. The part of an event that is visible to the event service is the identifier of the channel to which the event has been sent. Every notification posted to a channel is delivered by the event service to all the subscribers that are listening to that channel. The abstraction of the channel resembles to the one given by a mailing list. A user sends an e-mail to an address, and the message is forwarded to those who have registered to that mailing list. CORBA Event Service [1] adopts a channel-based architecture. Another widely used channel based model is the Java Delegation Event Model [2], which encapsulates events from the platform's Graphical User Interface. Subject-based subscription: Some systems extend the concept of a channel with a more flexible addressing mechanism that is often referred to as subject-based addressing. In this case, an event notification consists of two different parts: a wellknown attribute, the subject, that determines the address, which is followed by the remaining information of the event data. The main difference with respect to a channel is that subscriptions can express interest in many subjects/channels by specifying some form of expression to be evaluated against the subject of a

notification. This implies that a subscription may define a set of event notifications, and two subscriptions may specify two overlapping sets of notifications. This, in turn, implies that one event may match any number of subscriptions. JEDI [3] adopts the subject-based subscription mechanism. In JEDI, an event is given in the form of a function call, where the first string is the function/event name followed by parameters, e.g., print (tez.doc, myprinter). Each event is labeled with a subject. Subscriptions are specified with an indication of the subject of interest Content-based subscription: By extending the domain of filters to the whole content of notifications, some researchers obtain another class of subscriptions called content-based [5]. Content-based subscriptions are conceptually very similar to subject-based ones. However, since they can access the whole structured content of notifications, an event server gets more freedom in encoding the data upon which filters can be applied and that the event service can use for setting up routing information. Examples of event systems that provide this kind of subscription are Yeast [4] (uses a centralized structure) and SIENA[5]. In SIENA, an event notification is a set of attributes in which each attribute is a triple, as in attribute = (name; type; value). Attributes are uniquely identified by their names. An event filter defines a class of event notifications by specifying a set of attribute names and types and some constraints on their values, e.g., attr filter = (name; type; operator; value). Object-based subscription: Type based publish/subscribe model [6], proposed by Eugster, is a new model of subscription that has been developed to access event data in a more structured manner. Events are often viewed as low-level messages, and a predefined set of such message types are offered by most systems, providing very little flexibility. To overcome this deficiency, type-based publish/subscribe mechanism manipulates events as objects, called obvents. The core idea underlying this integration consists in viewing events as first class citizens, and subscribing to these events by explicitly specifying their type. So an application-defined event data can be used in the event system.

3. RUBDES Computational Model

RUBDES is an event-based publish/subscribe system that uses rules for subscribing to an event service. Many of the event systems described in literature, as referenced in the previous section, use predefined events. RUBDES implements a content-based subscription mechanism, similar to that proposed by Carzaniga [5], which enables handling of application-defined events. RUBDES, being implemented in Java, makes use of Java RMI facility extensively to access remote objects. To create a uniform structure, the components of the system are designed to be accessed over well-defined interfaces and, naturally, they are expected to implement the methods included in those interfaces. Fig. 2 depicts the general architecture of RUBDES. The system consists of three main components: Subscribers, Publishers and Event Servers. SUBSCRIBER: Subscribers of events determine what types of information they are interested in and describe them in a rule form usable by the Event Service. A subscriber has to know the address of the Event Server to which it should register.

Subscribers have to implement the Subscriber interface, which consists of a single method, notify. An event server issues a remote call to the notify method of the subscriber to deliver an event. The subscriber is expected to process the event in the context of this method.
Subscriber EVENT SERVICE Event Server Subscriber Event Server

Publisher

Event Server Subscriber

Event Server

Subscriber Publisher

Fig. 2. RUBDES Architecture

PUBLISHER: Publishers of information decide on what events are observable, how to name or describe those events, how to actually observe the event, and then how to represent the event as a discrete entity. A publisher process is not required to implement a particular interface. The Event Servers address has to be known by the publisher so that it can issue a remote call to its publish method. EVENT SERVER: The main function of the Event Server is to dispatch incoming event notifications from publishers to (possibly multiple) subscribers. The event server implements the EventServer interface, which consists of the following three methods: subscribe: A client (a subscriber or an event server) registers interest in a particular event by invoking the subscribe method of the event server. It supplies its RMI contact address and a rule that describes the events it is interested in as parameters to the call. unsubscribe: A client can cancel its registration by calling the unsubscribe method, supplying parameters needed to identify the subscription previously made. publish: A dispatcher (a publisher or an event server) calls the publish method to announce an event. The Event Server consists of manager modules that handle the basic functionalities of the system and several structures to hold various data. The internal architecture of the Event Server and message flow between its components are shown in Fig. 3. In the following, we describe the execution flow of registration and dispatching operations. Execution Flow of Registration: A client can register (or unregister) to an event server by invoking its subscribe (or unsubscribe) method. When a client subscribes to an event server, it sends certain parameters (its address and rule) to register on. The Subscription Manager adds these parameters into the Subscription Base. The Subscription Manager follows the following algorithm to process a subscription: 1. It checks subjects of interest in the Advertisement Base. To prevent subscription on an unpublished event, we use an Advertisement Base which keeps a list of events published previously.

2. It adds the incoming subscription to the Subscription Base, which consists of subscriptions formerly received. Its entries consist of the fields (Event_type, Triggering_SQL, owner_address, send_address). Triggering_SQL is a set of SQL commands, which are generated according to a subscription rule, and is to be triggered when an incoming event is related to a filtered or composite event. 3. It forwards this subscription message to other Event Servers.

Class Loader

Rule Base

Advertisement Base

Subscription Base

Knowledge Base Manager Publish Manager Filter Manager Subscription Manager

publish

subscribe unsubscribe notify or publish

Queue Manager Event Queue Server List Notification Queue Server Message Queue

Notification Manager Inter Server Communicator

inter server messaging

Fig. 3. The Architecture of the Event Server

Execution Flow of Dispatching: A dispatcher sends an event message by invoking the publish method of the event server with the required parameters (published event data). The Publish Manager creates a Class Loader thread to download the classes the published object belongs to from the publisher site and adds this incoming notification to the Event Queue. Messages in the Event Queue are processed by the Filter Manager later. When a new event (for example, event_x) arrives, the Filter Manager follows the following algorithm to process it: 1. It examines the Subscription Base to find out if there is a subscription on event_x and adds the published event type to the Advertisement Base. 2. For each subscription on event_x, it generates a notification according to the subscription rule and puts it into the Notification Queue. All incoming events are not stored in the same event table. For different types of events, different tables are created in the RuleBase. To generate notifications, the Filter Manager runs a query on the subscription record and the event data in the corresponding RuleBase table. Therefore, selections of filtered and composite subscriptions are performed faster when compared to other event-based systems previously mentioned. Notification Manager is an autonomous thread that sends the notification requests that are placed into the Notification Queue to target clients (subscribers or event servers). Inter Server Communicator is used for messaging between Event Servers.

4 Event Types and Rules

Event class is the base class of all event classes and defines common attributes for all types of events. The class definition of the event extends the base class Event and

may contain additional structures. A subscriber specifies the type of the event it wishes to be notified of. Fig. 4 shows the specification of a sample event type class named HeatEvent. In addition to the attributes inherited from the Event class, this class defines a new attribute loc to identify the location of the event produced and value to represent a measure of some kind, for example, a temperature reading of a thermometer. public class HeatEvent extends Event implements Serializable { int loc; // location of the event double value; // measurement of the temperature}
Fig. 4. A User Defined Event Type

A rule is an expression or function that is evaluated or executed depending on the occurrence of events. Rule Definition Language (RDL) is used to state rules to aid the specification of a single or a pattern of events in distributed systems. The grammar of the Rule Definition Language (RDL) and various programming examples are given in RUBCES [7], which is a centralized (with a single Event Server) version of RUBDES. A subscription rule can be created by the Graphical User Interface (GUI) at the subscriber site. This GUI can be specific to subscription event type and specific types of rules can be produced. Otherwise, a rule can be written manually in a text area component of a general GUI. Of course, this rule must conform to the RDLs grammar.
rule rule_1 onEvent HeatEvent h1 getData h1.value rule rule_2 onEvent HeatEvent h1 getData h1.value where (h1.value > 25 and h1.value < 37) rule rule_3 onEvent Temperature t1, Humidity h1 getData h1.value,t1.value where (t1.value < 27 and h1.value < 70) c. Composite Event

a. Simple Event

b. Filtered Event Fig. 5. Filtered Events in RDL

A rule definition is composed of four parts, each introduced by the keywords rule, onEvent, getData and where, respectively, as shown in Fig. 5. The first part sets a unique identifier for the rule, the second part specifies the type of the target event, the third part specifies the specific information data about the event that subscriber wants to be notified with, and the last part describes the conditions on which a filtered or a composite event should be caught. In RUBDES, it is possible to define rules for three different event types: simple events, events with filtering and composite events. Simple events, shown in Fig. 5.a, are used when subscribers are interested in only one

event type. An event-based system may include a multiple number of publishers. Thus, the number of events propagated in an event-based system may be quite large. However, a particular consumer is usually interested in only a subset of the events propagated in the system. Event filters are a means to control the propagation of events. Filters enable a particular consumer to subscribe to the exact range of events it is interested in receiving. An event that is delivered uses network bandwidth and CPU processing power on the consumer side. It is therefore desirable to prevent the delivery of unwanted events. RUBDES allows for event filtering as shown in Fig. 5.b. Clients may require to be notified on events from multiple sources and may want to detect a specific pattern of event occurrences from these different publishers. Such a combination of event occurrences, where a client is interested in a sequence of event occurrences but not in any of the events alone, is called an event composition. Intuitively, while a filter selects one event notification at a time, a pattern can select several notifications that together match an algebraic combination of filters. An advanced feature of RUBDES is that it allows subscribers to specify composite events, as shown in Fig. 5.c.

5 System Performance
Weve selected average message distribution time as an appropriate benchmark for evaluating performance of a communication framework. We define event distribution time as the elapsed time from the generation of an event to its reception by all subscribers that are interested in that event. In our analysis, event generation is the submission of an event to the Event Server by a publisher. In our preliminary analysis, we established an objective of determining the efficiency of the Event Server delivery without incurring concurrency into the system. Our goal was to examine the performance and scalability of the system.
960 Distribution Time (ms) 940 920 900 880 860 840 820 800 4 8 12 16 20 Number of Subscribers 24 28 32

Fig. 6.. Average Distribution Time with Respect to Number of Subscribers

We ran a simple benchmark with a single publisher, strongly connected to four event servers and a multiple number of subscribers, which were distributed evenly on these event servers. The number of subscribers was varied from 4 to 32 on successive trials. The experiment used a single event source whose event generation rate was slow enough to allow all the listeners to complete processing a given event before the next one was generated. As we were sure that there was no concurrent event delivery, we could compute the theoretical best average delivery time. Fig. 6 shows event distribution times we have measured for increasing number of subscribers. Although, RUBDES has not been tested with very large numbers of subscribers and publishers, the results we have obtained suggest that RUBDES is scalable.

6 Conclusion and Future Work

In this paper, we have presented RUBDES, an event-based publish/subscribe system that uses rules to specify subscription on events. RUBDES uses a content-based subscription mechanism that allows users to subscribe on different event types. A new Rule Definition Language (RDL) is used to enable specification of different types of subscription (simple subscription, subscription with filtering and subscription for composite events). Implementation of a prototype system in Java is completed. As future work, we plan to apply the system in different application domains and focus on new design decisions to improve its performance and scalability. We want to add features for mobile subscribers that can connect from different locations to different Event Servers and test the entire system in a large scale platform.

References
1. Object Management Group, CORBAservices: Common Object Service Specification, Technical Report, Object Management Group, July (1998). 2. Java AWT: Delegation Event Model. Available online at http://java.sun.com/j2se/ 1.4.1/docs/guide/awt/1.3/designspec/events.html (2003) 3. G. Cugola, E. Di Nitto, and A. Fuggetta, The JEDI event-based infrastructure and its application to the development of the OPSS WFMS, Technical Report, CEFRIEL Politecnico di Milano, Italy, August (1998). 4. B. Krishnamurthy and D. S. Rosenblum, Yeast: A General Purpose Event-Action System, IEEE Transactions on Software Engineering, 21(10):845857, Oct. (1995). 5. A. Carzaniga, Architectures for an Event Notification Service Scalable to Wide-area Networks, PhD Thesis, Politecnico di Milano, Italy, December (1998). 6. P.T.Eusgter, TypeBased Publish/Subscribe, PhD Thesis. Ecole Polytechnique Federale De Lausanne, France, (2001) 7. O. K. Sahingoz, N. Erdogan, RUBCES: Rule Based Composite Event System, accepted for publication in XII. Turkish Artificial Intelligence and Neural Network Symposium (TAINN), Turkey, July (2003)