A REPORT ON THE PROJECT

EVENT NOTIFICATION SERVER

By

Kiran Anna

Temitope Alo

Submitted as part of the requirements of the course “Process Coordination in Service and Computational Grids”, CPA5937

Professor

Dr. Dan Marinescu

Department of Computer Science

University of Central Florida

Spring 2002

Table of Contents
  1. Introduction…………………………………………………………………..3
  2. Event Notification Service Mechanisms..……………………………………5
  3. ENS design…………………………………………….……………………..7
1. INTRODUCTION

1.1Bond

Bond is a Java-based object-oriented middleware for network computing. Network computing is a paradigm that emphasizes the use of network resources, computing resources distributed across the network, over local resources. Network resources are hosts, programs and data. Middleware is a software layer that allows developers to mold systems tailored to specific needs from components and develop new components based upon existing ones. The goals of the Bond system are to:

  • Facilitate access to network resources,
  • Support collaborative activities, and
  • Accomodate software diversity and hardware heterogeneity.

Bond can be used in stand-alone mode or to connect to a Bond domain. A Bond domain consists of a society of users with common interests and a number of services. In stand-alone mode a user may create objects and agents and execute locally several demos. To create a Bond domain one needs to activate the servers provided with the package.

1.2 Problem and Motivation

In order to support collaborative activities, the Bond needs a service mechanism that supports coordination of the work over the network. A notification service based on events provides a good solution to this problem.

This service can be implemented by means of an Event Notification Server (ENS) added to the Bond domain. This model consists of two types of users- event producers and event consumers. The producers register events with the ENS and the consumers subscribe to the events in the ENS. The ENS coordinates the events between the producers and the consumers. The ENS design is explained in more detail in chapter 2.

1.3ENS Mechanisms – A Background

The primary purpose of an event notification service is to support notification selection and delivery. The challenge we therefore face is maximizing expressiveness in the selection mechanism and scalability in the delivery mechanism. Expressiveness is the ability of the event service to provide powerful data model to express filters and patterns on notifications and to use that data model as the basis for optimizing the notification delivery. Scalability measures are not just related to number of event generators, number of event notifications, and number of notification recipients, but alongside, it identifies issues related to local-area networks in terms of latency, bandwidth, centralized control etc.

The efficiency and performance of the event service and the routing of notification is dependent on the selection mechanism used to deliver the events between the publishers and subscribers. This selection mechanism in turn, depends on the language used to construct the notifications and filters. Three classes of selection mechanisms are identified

  • Channel-based selection
  • Subject-based selection and
  • Content-based selection

These classes are explained in detail in chapter 2.

1.4Scope

This document provides a detailed description of the various issues related to the ENS and its design. Chapter 2 explains and evaluates various schemes of the ENS and discusses the reasons for a selecting a scheme for the design and implementation of the ENS. The ENS design and algorithms are explained in the chapter 3.

2. THE EVENT NOTIFICATION SERVICE MECHANISMS

2.1 The Selection Mechanism

The efficiency and performance of the event service and the routing of the notification is dependent on the selection mechanism that is used in the ENS.Three classes of selection mechanism that affect the ENS are identified.

  • Channel-based Selection: In this mechanism, the ENS had a collection of channels. For ease of understanding, these channels can be identified with mailboxes used in inter-process communication. The publishers and the subscribers have to register with these channels in the ENS to send and receive events. The ENS delivers notifications sent by publishers registered on a particular channel to all the subscribers registered on the same channel.
  • Subject-based Selection: In the subject-based mechanism, the ENS has a predefined set of subjects. The clients subscribe to notifications based on the subject. The ENS delivers the notifications that the publisher publishes on a particular subject to all the clients who has subscribed on that subject.
  • Content-based language: In content-based, a client subscribes to all notifications whose content matches the particular predicates defined by the client.

2.2 Selection Mechanism Issues:

  • Channel-based Selection: All recipients that are connected to the channel receive all the notifications that are published by objects of interest on that channel. This scheme is restrictive on the predicates that can be defined. The filter applies to a single well-known field (e.g channel = “abc news”). This scheme therefore limits clients to notifications available on such channel alone. Moreover, since the predicates are predefined, clients are prevented from making a selection on the type of notification desired.
  • Subject-based Selection: This permits richer predicates with wild card string expressions on subject identifiers.(e.g subject = “*forecast” gives a notification on all events with words ending in “forecast”). The drawback here lies in the fact that notification to subscribers will be based on a wide range of information related to the subject definition. Thus, subscribers are liable to receiving irrelevant notifications. Also, this mechanism needs a centralized authority to define all the possible subjects, which will be a major draw back at Internet scale ENS. In like manner, from the point of view of the publisher, both subject-based and channel-based are not flexible because an object of interest that is interested in producing an event notification on a number of subjects or channels, will have to explicitly publish the notification on all of them (subjects/channels).
  • Content-based Selection: Notifications received by different subscribers are different since predicates are user-defined. Clients specify and receive the exact notification they desire. By issuing a subscription, a component is given the freedom to declare its interest in a number of notifications characterized by some common properties. To allow flexibility for the clients we intend our event notification service for, we have decided to implement our event service using content-based language.

2.3 Scalability Issue:

The internal architecture of an event service influences its performance. Intuitively, it has to scale to accommodate a growing number and distribution of components. If we assume that the event service is implemented as a centralized element, it can rapidly become a bottleneck as the number of components grows. This gets even worse when components are distributed over a wide-area network. To alleviate this problem, we have to consider distributed Event Notification Servers. Since we don’t have time to implement distributed EN servers we implement a basic EN server, which can be later extended, to support distributed EN servers. Also content-based selection mechanism is best fitted to support Internet scale distributed EN servers.

  1. ENS DESIGN

3.1. Bond servers

The bond domain currently supports the following servers:

  • Bond System Monitor (BSM)
  • Directory Server (DS)
  • Persistent Storage Server (PSS)
  • Authentication Server (AS)

We investigated the services provided by the above servers and their implementation. After our initial study, we came to a conclusion that the Bond provides most of infrastructure needed to implement the ENS. Owing to the time factor, we envision the design of a simple event notification service that uses the Bond infrastructure and cooperates with other existing Services (such as Persistent Storage Server) within the Bond domain. This leads us to follow the same design methodology adopted for such Services. Since Bond can be used either in stand-alone mode or to connect to a Bond domain, the event service we are designing will therefore support either stand-alone or will be suitable for supporting distributed applications requiring component interactions over the network.

3.2. ENS API

ENS is a Bond server that provides event notification service, allowing producers of events to register with the server, and consumers to subscribe to individual events or classes of events. ENS provides five types of services:

  • Advertise an event
  • Unadvertise an event
  • Publish an event
  • Subscribe to an event
  • Unsubscribe an event

The Bond ENS provides the clients, which include both producers and consumers with several APIs for accessing the event notification server. These include:

  • boolean adverstiseEvent (bondShadow ens, bondObject producer, Filter filter)
  • boolean unadvertiseEvent (bondShadow ens, bondObject producer, Filter filter)
  • boolean publishEvent (bondShadow ens, bondObject producer, Notification notify)
  • boolean unpublishEvent (bondShadow ens, bondObject producer, Notification notify)
  • boolean subscribeEvent (bondShadow ens, bondObject consumer, Pattern pattern)
  • boolean unsubscribeEvent (bondShadow ens, bondObject consumer, Pattern pattern)

In these APIs, the parameter ens refers to the bondShadow of an ENS, the parameter producer refers to the object that desires to publish/advertise an event while the parameter consumer represents an object that requests a notification from the ENS. The parameter notify, filter, and patterns represent the data model to represent the events generated by the producer or subscribed to by the consumer. They are explained in detail in the Semantics section.

The APIs are provided as methods of the class EventNotification. So all the producers/consumers are required to have an instance of this class EventNotification to communicate with the ENS. Figure 1 depicts the APIs and the mechanism to get the service provided. We decided to use communication infrastructure of the bond for the ENS. Therefore, the event Notification, the event filter and pattern objects are embedded into the bondMessage and communicated to the server using the Bond communication mechanism.

method advertiseEvent(………)

A producer expresses its intent to publish a particular type of event by using the above API to the ENS.

method unadvertiseEvent(………)

A producer can decide to unpublish an event by using the method unadvertiseEvent to the ENS

method publishEvent(………)

The producers of events notify the occurrence of an event by sending a publish request to the ENS using the above method.

method subscribeEvent(……..)

Consumers declare their interest in receiving event notification or classes of event notifications by sending a method subscribeEvent (…… ) to the ENS.

method unsubscribeEvent(……..)

Consumers of the events can declare that they are no longer interested in receiving notification of the occurrence of particular event(s) by sending the unsubscribe method to the ENS.

3.2Semantics

3.2.1Notification: An event notification is an untyped set of typed attributes. Each attribute is defined by three parameters:

  • Type of the attribute
  • Name of the attribute
  • Value of the attribute

An attribute name is just a character string, an attribute type consists of a predefined set of primitive types that are commonly found in programming languages and database query languages, and for which a fixed set of operators are defined. The advantage with this attribute parameter scheme is scalability. Typed notifications require a global authority for managing and verifying the type space, which is not feasible at an Internet scale. On the other hand, notifications consisting of attributes built from a restricted set of attribute types can be used to create infinitely many notifications and also provides efficient notification mechanism based on the content of the notification thus providing scalability at an Internet level. For example, the notification displayed in fig. 2 represents a stock price change event.

The Notifications are used by publishers to convey the occurrence of an event owing to the change in the state of the certain attributes which is it has advertised to publish.

3.2.2 Filters: An Event filter is a set of attributes and constraints on the values of those attributes. Each attribute constraint is a tuple specifying a type, a name, a binary predicate operator and a value for an attribute. The operators we decided to support include all the common equality and ordering relations (=,,<, >, etc.) for all of its types, substring(*), prefix (>*) and suffix (*<) operators for strings and operator any that matches any value. A filter simply selects event notifications if the attributes defined in the notification matches the attribute constraints defined in the filter. An attribute  = (type, name, value) matches an attribute constraint  = (type, name, operator, value) if and only if type = type name= name operator(value, value). For example, fig. 3 represents a filter that matches price increases for the stock DIS on stock exchange NYSE.

Also a filter can be defined with multiple constraints for the same attribute and all such constraints must be matched. A notification is said to be match a filter only if all the attribute constraints on all the attributes in the filter matches with the corresponding attributes in the notification. So some times a notification may contain attributes, which are not defined in the filter. As long as all the attributes in the filter matches with the attributes in the notification, a match is said to occur.

3.2.3 Patterns: A pattern is nothing but a collection of filters. A pattern can be applied to one or more notifications based on both their attribute values and on the combination they form.

3.3 EN Server Design

The Event Notification Server (ENS) and the clients communicate by means of Bond object bondMessage. The clients embed their service request in the bondMessage and send it to the ENS. The ENS unwraps the bondMessage and checks for the service request in the sub protocol field and calls the appropriate sub-protocol handler. We have decided to provide six sub protocol handlers to the ENS to handle the service requests from the clients.

  • sphadvertiseEvent(bondMessage msg, bondObject sender)
  • sphunadvertiseEvent(bondMessage msg, bondObject sender)
  • sphpublishEvent(bondMessage msg, bondObject sender)
  • sphunpublishEvent(bondMessage msg, bondObject sender)
  • sphsubscribeEvent(bondMessage msg, bondObject sender)
  • sphunsubscribeEvent(bondMessage msg, bondObject sender)

We have also decided to use the Virtual Network of Objects (VNO) feature of the Bond to send notifications to the collection of consumers who have subscribed to the same event. The VNO is a container for a collection of objects, which are communicated to by multicast mechanism.

The ENS checks the event from the producer and scans the consumers which have subscribed to the received event and applies a filter supplied by the consumers to see if they need to be notified about the event occurrence. All the consumers that satisfy the filter requirements are added to a VNO and are communicated by the multicast mechanism provided to the VNO by the Bond. The use of VNO in the ENS saves a great amount of time as the Bond has the multicast communication infrastructure readily available. The missing ENS design features if any, will be explained in more detail in the next report.

1