MAIN PROJECT END SEMESTER REPORT

Analysis of Event Models in Event-based

Middleware

SUBMITTED IN PARTIAL FULFILMENT OF THE DEGREE OF

BACHELOR OF TECHNOLOGY

by
NIDHI RAJ Y2364
NILIMA NAIR Y2192
RADHIKA REVI Y2196
SHAINA KARDAM Y2382
GROUP NO. 15

Under the guidance of

Mr. S.D. Madhukumar

Department of Computer Engineering

National Institute of Technology, Calicut

 DEPARTMENT OF COMPUTER
ENGINEERING
NATIONAL INSTITUTE OF TECHNOLOGY,
CALICUT

CERTIFICATE
This is to certify that the project entitled

Analysis of Event Models in Event-based

Middleware
is a bona fide record of the work done by

NIDHI RAJ (Y2.364)

NILIMA NAIR (Y2.192)
RADHIKA REVI (Y2.196)
SHAINA KARDAM (Y2.382)

Eighth semester B.Tech students of National Institute of Technology,

Calicut, submitted as a partial fulfillment of the degree of Bachelor Of
Technology in Computer Engineering.

Dr. M.P. Sebastian Mr. S.D. Madhukumar

Head of Department Faculty in charge (Project Guide)
Department of Computer Engineering, Department of Computer Engineering,
National Institute of Technology National Institute of Technology
Calicut Calicut
 ACKNOWLEDGEMENT

We wish to express our sincere gratitude to Mr. S. D. Madhukumar, Department

of Computer Engineering, for his invaluable guidance and help throughout the
progress and completion of this project.

We are also thankful to our families and friends for their encouragement,
cooperation and support for completion of this project.

We express to all, our heartfelt gratitude.

 ABSTRACT

The concept of a middleware was introduced to facilitate communication between

entities in a heterogeneous distributed computing environment. The main task of an
event-based middleware is to disseminate data to all interested parties in a large-
scale distributed system. Hence, an event model is needed to describe how data, and
interest in that data, is expressed in the system i.e. event publication and event
subscription respectively. In our system, we represent an event as an object and the
event model is illustrated using a sample application.
 CONTENTS

1. Introduction 1

a. Problem Specification 1

b. Literature Survey 1

c. Motivation 2

d. Background 2

e. System Design 3

2. Analysis 4

3. Implementation and Results 5

4. Conclusion and Future work 11

5. References 12
1. INTRODUCTION

Problem Specification

The problem at hand is to develop an event system that can be extended to any
application. For this, the present models were analyzed and their drawbacks were
detailed. When designing an event model, the following were kept in view; the first
was, its interaction with the data model of the programming language and the other
was bridging the semantic gap between event and programming language data by
mapping publications and subscriptions onto programming language objects. This
mapping can be very natural if the event model respects the data model of the
programming language. As a consequence, the notion of data types should be
present in the event model. Strong type-checking can then verify that event data
conforms to its type specification. In addition, most object-oriented programming
languages support the concept of type inheritance to create more specialized
subtypes from existing types. The event model should support addition of new
attributes dynamically. When an event publication is expressed as a message, a
language must be used that has a powerful enough type system to support the typing
of events and event attributes. With the recent proliferation of XML as a standard
format for semi-structured data, the more expressive XML Schema language can be
used. It has a generic type system that supports the definition of new data types and
provides type inheritance through restriction and extension. It is a natural choice for
publication of messages in heterogeneous distributed computing environment.

Literature Survey

In this section we survey the event models in some of the well known event based
middleware projects likes Hermes, Rebecca, Rule Based Distributed Event System
(RUBDES), Elvin, Java Event-Based Distributed Infrastructure (JEDI), and
Scalable Internet Event Notification Architecture (SIENA). We found that the
Hermes event model was the most suited model which we could extend to obtain
the additional functionalities that we wished to implement.

Motivation

In the present scenario, it is in demand to have the existing event based middleware
supporting the addition of new attributes dynamically to the existing attributes in
the event model. Hence there should be provisions in the event model to handle this
aspect of the events. We need a new event model, which can support real life
applications running on an event driven middleware. It may be noted that dynamic
adaptation will be easy with more information gathered from the events, which are
occurring during the execution stage of the event driven applications.
Background

The following are few terms that require a clear understanding:

An event system is a system where entities communicate asynchronously by
producing and consuming events. We have producers and consumers in the system.
A producer is an entity that produces events and a consumer is an entity that
consumes events. An event is a message that contains data that producers wish to
distribute to consumers. We define an event service as a middleware that
implements an event model. A producer forwards events to an event service in the
system. The event service is responsible for distributing events to interested
consumers within the system. A consumer may specify to the event service the
subset of all events that it is interested in receiving by specifying a filter in a
filtering language to the event service. An entity may be a producer of events, a
consumer of events or both a producer and a consumer of events.
There are roles that an entity can take on at any time namely, publishing an event
and subscribing for events.
Hence the producer is often known as a publisher and the consumer is often known
as a subscriber in event service terminology. An event service client is any software
entity that uses the event service. An event contains parameters and attributes.
Parameters and attributes have a type and a name value pair associated with them.
An event may also contain a special subject parameter that indicates the type of the
event. There are two main kinds of filtering that are support that may be provided
by an event service is content based filtering and subject based filtering.

System Design

In an application all possible events are to be defined in advance. These event

schemas are to be compiled and stored at the publisher’s side. Once successfully
compiled these are to be advertised through the broker network. The subscribers
who have interest in the new event advertisement will express their interest to the
broker and will become subscribers of the event. Later while the application is on
execution the subscribers will be receiving the events with all the relevant data
values for the event schemas, which they have subscribed earlier. A GUI for
subscriber registration is to be provided. With the help of the event model the
attributes and its values are passed. Type checking of the publication message is
performed with the help of XML parsing. The event is to be demonstrated using an
example application. The application domains can include, for example, software
environments such as Field, Tool talk and Arch studio, Real-time communication,
E-commerce, Application monitoring, Software testing, Software Engineering,
Event-based integration of components and Internet-scale content-based routing
 <Interface>
<Interface>
EVENT INTERFACE
EVENT TYPE INTERFACE
+setEventType()
+getEventType() +setAttributeValue()
+setEventType() +getAttributeValue()
+setParentEventType() +clearAttributeValue()
+getParentEventType() +clearAllAttributeValues()
+getAttributeType() //Returns class
+addNewAttribute()
+modifyAttribute()
+deleteAttribute()
+deleteAllAtribute()
EVENT

-eventType : eventTypeInt
* -attributeValues : Map
+parent 1 +child
EVENT TYPE

-eventType : String
-parentEventType : eventTypeInt
-attributes : Map
<Interface>
<Interface>
EVENT FILTER INTERFACE
EVENT LOGIC EXP INTERFACE
+getFieldIterator()
+setLogicalExp()
+getField()
+getLogicalExp()
+matches()
+setAttribute()
+addEqualityFilter()
+getAttribute()
+addGreaterThanFilter()
+setOperator()
+addLessThanFilter()
+getOperator() EVENT FILTER +covers() //Event filter
+setValue()
+getValue() -equalityFilter : Map
-greaterThanFilter : Map
-lessThanFIlter : Map

The proposed system is designed as follows. Object oriented design approach is

followed incorporating efficient use of interfaces and generalizations. A short
description of the main entities is given below.

Event Type
It specifies a new type of event. It has an event type schema (a set of attributes and their
types). It supports functions for setting a basic parent event type with many
instances of parent event. We can modify the attributes and delete the unwanted
ones.

Event
This is the basic class for manipulating the attribute values of the event. This class
can be extended to any application having their own attribute set defined.

Event Filter
Event filter is used for attribute based filtering. It also checks subset relation
between two filters.
2. ANALYSIS
Study of various event models

The event models of the following middleware were studied

Elvin: In Elvin, events are represented as attribute-value pairs. Each attribute-value
pair consists of a unique name and an associated value, which is a string

JEDI: In JEDI, events are represented as set of strings representing a very simple
form of regular expression. The first string of the pattern is the pattern name, while
others are the pattern parameters.

Siena: In Siena event model, events are represented as a triple. Each event
notification is a set of attributes in which each attribute is a triple: attribute= (name,
type, value). In Siena, attributes are uniquely identified by their name[2].

YANCEES: In YANCEES events are represented as sets of attributes, which have

name type and value. Events in Yancees are represented in XML format

REBECA: REBECA follows a well-formed XML document structure for event

modeling. The event model followed in REBECA does not having the features,
which we have outlined.

Hermes: In Hermes the event model adopted follows the object-oriented approach
and it can be easily mapped to the data models of object oriented programming
languages. Hermes has an event model, which supports event types, event type
inheritance and record like structure for the event representation[1].

Our event model

The events are treated like objects. We argue that the entire design of the event-
based middleware should be remodeled to accommodate the changing behaviors
from various components. As a first step of this we find that the event model
described in Hermes [1] can be modified further so that it works efficiently under
an adaptive environment. Adding the support of new styles of GUI for user
interaction is an example of domain specific application level changes. The
proposed event model can work well under both topic based and content based
Publish Subscribe systems
3. IMPLEMENTATION and RESULTS

Implementation languages – Java.

Parsing and Type checking of the publication message- XML
GUI- JavaScript and HTML
We have four main classes, namely, Event.java, EventType.java, EventFilter.java,
and Check_logical.java. These classes encompass our event model which is based
on attribute value pair.

The developed event model can be extended to any application. In our event model,
type checking of subscription and publication message is automatically performed
by validating xml. It is the subscribers who determine what kind of information
they are interested in. A filter maybe used to specify the subset of all events that the
consumer is interested in, to the event service. It is necessary to know the event
server to which one should register. Event server address should also to be known
to the publisher.
Our event model is based on the semi-structured data model: They are record
oriented models which allow us to call methods on attribute objects. In this model,
notification is a well formed XML document, which consists of elements in
hierarchy.

We have demonstrated our event model with an application called Power warning.
This application warns a customer when a temperature of the server exceeds a
specified value.
We have provided a dynamic GUI which can serve many applications. After the
submission of the query, the servlet appears confirming our request. At the same
time, a thread runs at the subscriber’s side constantly checking the updated
information. There can be many subscribers at the same time, each being processed
by their own threads.
The application runs on a web server located at some URL, say,
www.powerwarn.com. Our customers connect to this site using a normal html
browser.

Fig. 1 Customer Registration form

The customer fills in the form specifying the city and the warning condition and
submits it.
 Fig 2: Processing of the request

This is a servlet that receives an HTTP Post request that has several parameters and
registers the request in the user table.
 Fig 3: Thread run with one subscriber

Our application is responsible for periodically calling the weather information site
at some URL, say, www.weather.com to fetch the current temperature of the
designated city.
 Fig 4: Thread run with two subscribers

If the temperature exceeds the warning level for more than the specified number of
hours a warning message is sent to the person.
After the weather site is updated so that the current temperature falls below the
subscribed temperature, no more notifications are sent.

fig 5: The thread showing temperature within control

The user parameters extracted are stored in an object. A separate thread is

implemented as a separate object making a roll call of this object every hour.
Whenever a thread is dispatched the current object makes a connection to the URL,
www.weather.com to look up the current temperature and send an email warning if
necessary, to all the subscribers whose information is stored in the hash table.
4. CONCLUSION AND FUTURE WORK

We have successfully developed an event model which can dynamically adapt

to the changing environment. Further improvements are possible. It is possible
to implement compound and composite events. Also, it is possible to modify it
so that the event name can be made to carry information helpful in adaptive
event filtering, routing and matching.
5. REFERENCES

[1] Peter R. Peitzuch: Hermes: A scalable event-based middleware, http:// portal

.acm.org/ citation.cfm? id=7080508.

[2] Antonio Carzaniga,David S. Rosenblum,Alexander L.Wolf Design of a Scalable

Event Notification Service,Interface and Architecture :Technical Report CU-CS-
863-98,University of Colorado,August 1998

[3][ABKM01] David G. Andersen, Hari Balakrishnan, M. Frans Kaashoek, and

Robert Morris. Resilient Overlay Networks. In Proceedings of the 18th ACM
Symposium on Operating Systems Principles (SOSP’01), Chateau Lake Louise,
Banff, Canada, October 2001..