A Taxonomy and Classification of Adaptive Event Based Middleware withSupport for Service Guarantees

Shruti P. Mahambre, Madhu Kumar S.D. and Umesh BellurKReSIT, IIT Bombay,

Mumbai, Indiafshruti, madhu, umeshg@it.iitb.ac.in

A Taxonomy and Classification of Adaptive Event Based Middleware withSupport for Service Guarantees

Shruti P. Mahambre, Madhu Kumar S.D. and Umesh BellurKReSIT, IIT Bombay,

Mumbai, Indiafshruti, madhu, umeshg@it.iitb.ac.in

Abstract

Event Broker Networks are scalable versions of the pub-lish subscribe paradigm that take the form of P2P overlaysof broker nodes. Several routing schemes help disseminateevents efficiently from publishers to subscribers on differ-ent overlay topologies. While there exist various frame-works that demonstrate several overlay topologies and rout-ing schemes, attention has now turned to exploring non-functional attributes of such systems. Although many effortshave started addressing these needs, there does not exista taxonomy and a comprehensive survey of adaptive eventbased middleware with provision for service guarantees. Inthis effort, we first present a detailed taxonomy and a surveyof existing event based middleware efforts, centered aroundqualities of service and adaptation. In the process of puttingtogether this survey we have also identified open researchproblems in the area.

1 Introduction

Event Broker Networks (EBNs) are a scalable incarna-tion of the asynchronous computing paradigm that take theform of overlay networks and provide decentralized rout-ing, to disseminate application level events from publishersto subscribers. Middleware, that operates on these brokernodes, alleviates the issues related to the heterogeneity ofunderlying platforms and provide a uniform interface toapplications written on them. A common service interfaceprovided by such middleware is that of publish-subscribe(pub-sub) [18]. In a pub-sub paradigm, the producerspublish information, consumerssubscribe to this informa-tion, and receivenotifications for the same. Informationof interest is encapsulated in a structure termed anevent.The middleware provides for storage and management forsubscriptions and for routing events. The fully decouplednature in terms of time, space and synchronization [18],

makes this model highly suitable for large scale distributedapplications.

EBN overlay network [14] is an abstraction that usesa subset of the underlying existing physical network. Anoverlay link is virtual, may consist of many physical linksin the underlying network. The middleware executes oneach of these overlay nodes that work cooperatively toaccomplish their functions. Event based architectures areemployed in various domains many of which themselvesexpose and hence require qualities of service guaranteesof the underlying infrastructure. However, our surveyindicates significant gaps in addressing these needs andthat few middleware [13], [1], [5], provide support for suchnon functional service guarantees. However there doesnot exist a comprehensive survey of existing event basedmiddleware, based on their support for quality of serviceguarantees and adaptation. In this effort, we present asurvey of existing event based systems, classified based ona taxonomy of adaptive event based middleware, providingquality of service guarantees. Our taxonomy providesa basis for architecting a middleware with the abovementioned features, and also highlights research issues inthis area.

The rest of this paper is organized as follows. In thenext section, we discuss how the taxonomy is structuredand may be exploited by users, when classifying eventbased systems. In Section 3, we differentiate our workwith existing approaches to middleware classification.Section 4 presents our architecture of an adaptive eventbased middleware which provides support for quality ofservice guarantees. We present a detailed taxonomy of thecore features of the middleware in Section 5. We defineQoS parameters relevant to an event based middleware inSection 6 and identify Adaptation Triggers in Section 7.We identify key research issues, which are an outcomeof this classification in Section 8 and conclude in Section9. A classification of existing event based middleware,

illustrating the usage of the taxonomy appears in theAppendix.

2 Structuring the Taxonomy

Our taxonomy is structured as a hierarchy of propertiesthat serve as a basis for identifying features, required by anevent based system, in order to ensure service guaranteesin an adaptive manner. The taxonomy will lead to iden-tification of groups of systems and also layout the func-tional characteristics that come into play when providingQoS guarantees and support for adaptation. Figure 1 illus-trates the notation of the taxonomy hierarchy.

Figure 1. Taxonomy Key

3 Related Work

The taxonomy presented in Meir et al. [12] deals withclassification of existing event based systems as a pro-gramming paradigm. It identifies fundamental propertiesof event based middleware and classifies them broadlybased onevent modeland event servicecriteria, with afurther classification on the basis of itsfunctionalandnonfunctional features and itsorganization and interactionmodel. Even though we do start with core functionality,our focus is quality of service guarantees and adaption inmiddleware rather than programming models for functionalaspects of EBMs. We also extend the definition of an eventmodel as acommunication modelin [12] by taking intoaccount, event characteristics such as, attributes, hierarchi-cal and compositional relationships between event types.Eugster et al. [18], present a detailed survey of event basedsystems, which is based on a common denominator of thevarious modes of decoupling in asynchronous systems.Decoupling is discussed in three dimensions, in terms oftime, space and synchronization. The main focus of thepaper however is on implementation issues underlying thepublish/subscribe schemes, and how these issues have beenaddressed in existing middleware. This paper also identifiessome common qualities of service relevant in the pub-subparadigm. We use this paper as a basis for our work, inidentifying features that will require to form an inherentpart of any event based system, that intends to supportquality of service guarantees and classify them. Martin etal. [11], present a taxonomy, as a hierarchy of questionsand answers, about the features of distributed computing

Figure 2. Architecture of Adaptive Middle-ware with QoS Support

systems (DCS). This taxonomy, though not specific to thepub-sub paradigm, can be used to compare existing generalpurpose distributed computing systems and provides ameans to classify systems and also serves as a basis fordesigning a DCS that offers novel combinations of features.

Existing taxonomies focus on classifying event basedmiddleware based on their event model. However as can beseen, there is no effort so far in the direction of classifyingevent based middleware based on their support for QoS andadaptation. In this effort, we leverage the work done sofar, in terms of classification based on the event model, andcategorize existing event middleware, on the basis of theirsupport for quality of service guarantees and adaptation.The classification also highlights the level of support foradaptation and service guarantees in the existing eventbased middleware and brings out key research problemsthat need further attention.

4 Middleware Architecture

As shown in Figure 2, we represent an event based mid-dleware in the form of a layered architecture. We distin-guish thecoreof the middleware, from theservicesit pro-vides, as follows. The core comprises of mandatory func-tional features such as the event model, the subscriptionscheme used to disseminate events in the model and theoverlay routing substrate which facilitates this routing (forevent dissemination). The layer on top of the core forms aset of optionalservicesknown as the non functional, qual-ity of service guarantees that the middleware provides. Re-liability, Delivery Semantics, Message Ordering, Security,and Fault Tolerance are some of the services which a mid-dleware may support. The QoS programming model com-prises of the QoS specification provided by the user which isthen translated into the required resource reservation. Thesequalities of service guarantees are orthogonal to the corefunctions supported by the middleware. The capability ofthe middleware to reconfigure itself, in order to ensure andmaintain a quality of service agreement, isadaptability.

Figure 3. Core of the Middleware

Figure 4. The Event Model

Adaptability may result in changes in the core of the mid-dleware like the subscription scheme or the overlay routingsubstrate.

5 Taxonomy of Event Based Middleware

5.1 CoreAs can be seen from Figure 3 our taxonomy begins with

this differentiation between feature functionality and qual-ities of service properties. The core can be further cate-gorized into theevent model, overlay routing substrateandsubscription scheme.

5.1.1 Event Model

In any EBM, subscribers transmit subscriptions in the over-lay network, with filters to filter out non-matching dataelements from the event notifications and publishers floatadvertisements regarding the occurrence of a new eventtype. The event model is comprised of these three messagesevent advertisement, event notificationandevent subscrip-tion. The event model also defines the attributes of eventsuniquely identifying an event on the basis of its event iden-tifier, event name, event type or the temporal or persistentnature of an event and offers additional information such asanonymity of publishers and subscribers. The event mayalso be characterized by the kind of data it stores. For e.g.,the data contained in an event may have access control in-formation associated with it i.e., it could be private or pub-lic. Hermes [13] follows an object model, in which everyevent is represented as an object, and the attributes of the

object define the event properties. Jedi [5] uses pattern (orstring) matching to identify events occurring in the systemwhile Siena [4] models an event in the form of a triplet asfollows <name,type,value>. Multiple event types can benow related to one another by a hierarchy or compositionalrelationship.

� Event Hierarchy: A new event type may be definedby inheriting from an existing event type and extend-ing it leading to a hierarchy of event types and en-abling polymorphic dispatch of events in the system. Asubscriber subscribing to a supertype receives notifica-tions from all subtypes of the event, as well as the su-pertype. DAC [7] supports a topic based event hierar-chy, i.e., events in DAC are represented in the form oftopics. Subscribers express their interest in these top-ics, and notifications are sent for the subscribed topicalong with notifications for all its subtopics. In Her-mes, every rendezvous node1 is aware of its descen-dent types, and hence, subscriptions to the parent ren-dezvous node, can be supported by inheritance routing.

� Event Composition: Composite Events[13] providea higher level of abstraction for event subscribers. Acomposite event service enables complex event pat-terns, as opposed to subscribing to all primitive eventswhich make up the pattern and then form the detec-tion themselves. The Hermes [13] middleware, pro-vides support for a composite event service. Compos-ite events maybe temporal or spatial in nature. Tem-poral composite events lead to the formation of a com-posite based on temporal dependencies between prim-itive events. Spatial composite events are unrelated intime, and are published based on a pattern of event sub-scriptions observed by the composite event detectionengine.

5.1.2 Overlay Routing Substrate

EBMs may also be categorized on the basis of its overlayrouting substrate (Figure 5) that provides an IP address in-dependent abstraction upon a physicalunderlay. A middle-ware architecture may support one or multiple overlay net-work topologies. Overlay networks are also useful in pro-viding service guarantees and can be deployed using endhosts running overlay protocol software without dependingon routers and ISPs. We have a threefold basis for catego-rizing overlay substrates:

� Node lookup protocol- The node lookup proto-col refers to the protocol used when locating anode(object) in an overlay network. Based on the node

1A rendezvous node is a node which houses events of a particular eventtype

Figure 5. Overlay Routing Substrate

lookup protocol, overlay networks can be classified ascontent addressable overlaysandflooding style over-lays[6].

– Content Addressable Overlays:Here the net-work topology and the content of the objects arerelated. DHT [15] based techniques are used toconvert object identifiers into overlay node iden-tifiers. They provide the guarantee for locating anobject if present, and search times are bounded.Pastry [16] and Chord [17] are content address-able overlays.

– Flooding Style Overlays:Here object lookup isbased on Time To Live (TTL) controlled flood-ing. A node looking for a particular key value,sends the request to all its known neighbors witha particular value for TTL. The neighbors will re-ply to the request by looking for a match to thekeys in their local databases. If the neighborsfind a match, they reply, else they forward therequest to their known neighbors after increasingthe Messagess hop count. If the hop count passesthe TTL value, the forwarding stops. Unless theTTL is set to a very high value , there is a chancethat the object will not be located even though itis present in some node. These topologies are un-structured and the topology is decided by factorslike the join order of nodes and physical proxim-ity. Freenet [9] is an example of flooding styleoverlays.

� Underlay Awareness-Next we categorize overlaysbased on their underlay awareness properties. Theoverlay network may be either aware of the underlyingphysical network topology or unaware of the underly-ing physical network topology.

– Underlay Unaware overlays are constructed

based on distributed hash tables, which use log-ical identifiers to identify overlay nodes in thenetwork. The logical identifiers of the overlaynodes and the identifiers of the neighbors of anode are generated based on a random hash func-tion. The overlay assumes full network connec-tivity and does not measure any of the physi-cal network properties in the overlay constructionprocess. Chord [17] constructs underlay unawareoverlays.

– Underlay Aware overlay construction strategymaintains correspondence between the physicaland the overlay networks. The overlay construc-tion strategy considers some of the properties ofthe underlying physical network like path dis-jointness (absence of common nodes or physicallinks in different overlay paths), hop count (num-ber of physical nodes between a pair of overlaynodes), bandwidth , physical distance informa-tion and failure statistics of the physical linksand nodes. Thus the overlay network is sensi-tive to the changes in the underlying physical net-work, i.e., the overlay dynamically adapts to theresource based adaptation triggers. We furthercategorize the underlay aware overlay networksas Underlay Proximity Aware and UnderlayQuality Aware overlays. Underlay proximityaware overlays reflect only the network proxim-ity of the physical nodes. For example, whileadding a new node into the overlay, a ping mes-sage is broadcast to all the nearby nodes, and thenearest neighbor is chosen based on the roundtrip time. No other underlay parameter is used inthe overlay construction and maintenance. Pas-try [16], Medym [3] and Hermes [13] belong tothis category. The granularity of underlay aware-ness can be extended to physical link quality, fail-ure probabilities, degree of nodes, diameter of thephysical network and QoS guarantees of the un-derlying nodes and links. We call these overlaysas Underlay Quality aware overlays. Here theoverlay construction is based on the physical net-workss qualitative parameters mentioned above.For example, the failure statistics information ofthe underlying links and physical nodes in thevarious physical paths possible can be used to se-lect a reliable path for an overlay link. Also infor-mation regarding the degree of physical nodes isuseful when constructing an overlay which laysemphasis on the degree of availability [10]. Thiswork discusses how the diameter information canbe used to constrain the maximum delay in theoverlay network. The overlay network is adap-

tive to the resource based triggers involving thechanges in these properties. At present there is noreported work on Underlay Quality aware over-lay networks which are used in Event Based Mid-dleware to the best of our knowledge.

� Structure of topology- Finally, we categorize overlaynetworks, based on the structure of their overlay net-work topology. We have identified a set of topologieson which most of the existing event based middlewareare based. These topologies determine the formationof event dissemination trees in the event based middle-ware, when routing event notifications. We will dis-cuss these topologies in detail. All the event basedmiddleware studied as a part of this survey adhere toone or a combination of the topologies discussed be-low. However this taxonomy could be extended to ac-commodate newer topologies.

– Hierarchical Topology [4] : The nodes are con-nected in a hierarchy of parent-child relation-ships and hence form a tree like structure. Eachserver in the topology has a number of clients thatmay be publishers, subscribers or intermediatebrokers in the network. The parent server is ableto receive notifications, advertisements and sub-scriptions from all its clients, but will only sendback notifications. Jedi uses a hierarchical over-lay topology for dispatch of events.

– Acyclic Topology [4]: The servers communi-cate with each other as peers. The links betweenservers are non-directed and the server connec-tions produce an acyclic graph. This enables bi-directional flow of flow of subscriptions, adver-tisements and notifications.

– Non-Acyclic Topology [4] removes the con-straint of an acyclic graph from acyclic topology.This topology allows bi-directional communica-tion amongst two servers. However, there mayexist multiple paths between servers. This makesthe topology robust and resilient to failures, butcould also lead to cycles.

– Hybrid Topology supports a combination oftopologies, i.e., it exhibits different topologies atdifferent levels of granularity. Siena [4] posesa good example of a hybrid topology. For eg:Some clusters of subnets in Siena have very in-tense traffic of local events, and only a small frac-tion of these events is visible outside the clus-ter. Here, for efficiency reasons, a generic graphtopology might be preferable inside the clusterwhile the high-level topology could be set up asan acyclic graph.

Figure 7. Subscription Scheme of the Middle-ware

5.1.3 Subscription Scheme

As shown in Figure 7, this refers to the semantics fol-lowed by the subscribers when specifying their interest in anevent, and by publishers when publishing or advertising anevent. InTopic/Subject Based Scheme, participants pub-lish events and subscribe to individualtopics. Each topic isidentified by akeyword. This is similar to group commu-nication, where similar topics are grouped together. Top-ics can overlap, leading to a hierarchy as in DAC. In theContent Based Schemesubscriptions are based on the ac-tual content of the event enabling a fine grained search, ascompared to the topic based scheme. The properties of theevents maybe internal attributes of the data structures car-rying the events. Examples are Jedi [5], Siena and Elvin[8]. In a Type Based Scheme, events are classified accord-ing to their type [19]. A type represents commonalities instructure and content and facilitates a closer integration ofthe language and the middleware. IndiQoS [1] and Hem-res support type based routing scheme. Finally theHybridSchemeis as the name suggests a combination of the rout-ing schemes discussed above.

5.2 Discussion

We have thus far categorized an EBM according to itsfunctional characteristics. Each of these properties willneed to be considered while providing service guarantees.For example: composite event models may dictate the up-per bound on the latency of the notification and the type ofoverlay topology may restrict the set of routes available tochoose from when looking to provide reliable delivery. Inthe following section we present an extension of the taxon-omy with service guarantees, in detail.

6 Quality of Service

As seen in Figure 2, an event based middleware mayoptionally provide support for QoS guarantees. Theseservice guarantees, follow a publisher-offered, subscriber-requested pattern. It is the task of the event-broker networkto ensure that the quality constraints are met, when deliver-ing events. As shown in Figure 8, we have identified five

Figure 6. Non Acyclic, Hierarchical, Acyclic Topologies

Figure 8. QoS in Middleware

classes of service guarantees - Reliability, Delivery Seman-tics, Message Ordering, Latency and Bandwidth.

6.1 Latency

Also known astime to delivery, is defined as time be-tween a publisher publishing an event and a subscriber forthe same event, receiving a notification for the same, w.r.t anindependent observer. It is the task of the overlay network toeffectively reduce the overall, latency of event notifications,in an event broker network. If Td represents the transmis-sion delay, Pd represents the propagation delay (this is con-stant for a network), Qd represents the buffering/queuingdelay, e� represent an event of type� , andn is the total num-ber of nodes occurring in the path between a publisher andsubscriber, then the latencyL (e� ) for a single notificationof an event of type� between a publisher and subscriber, isgiven as follows:

L(e� ) = n(Pd) +nXi=1

(Td[i] +Qd[i]) (1)

6.2 BandwidthBandwidth represents the resources, available across the

path during event transfer - which is denoted by the num-ber of events being transferred between publisher and sub-scriber, per time unit. If a subscriber does not specify arequirement, then default values are assumed, which pro-vide the maximum possible bandwidth available along apath. IndiQos provides support for Latency and Bandwidthparameters. IndiQoS usesNetpipe, which is anInfopipe2

responsible for transferring events between different hosts.The length of the Netpipe represents the latency and thewidth of the Netpipe represents its maximum bandwidth.

6.3 ReliabilityReliability in an event based system is defined as the ra-

tio of number of successful notifications, to the number ofevents published of that type.Assume thatn(e� ) represents the number of notificationssent for an event type� andp(e� ) is number of publicationsof event of type� , The reliabilityR attained at subscribersis given by 2.

R[s(e� )] = n(e� )p(e� ) (2)

Using equation 2, reliability is measured at different lev-els in an event based system The delivery reliability for thenotification of an event type, is measured for a single sub-scriber subscribing for a single event type. A subscribermay subscribe for multiple event types. However we mea-sure the reliability that the subscriber attains for each eventtype that it has subscribed for. This is given by 2. The relia-bility attained by a subscriber for all the event types e(�j), ithas subscribed for, is given by 3. The reliability offered bythe entire system for a specific event type, can be calculatedacross all the subscribers as shown in 4. And finally using3 and 4 the reliability of the entire system is as given by 5.

R[s(e�j )] =P�maxj=1 R[s(e�j )]

e�max (3)

2Infopipes are software components that can be connected to each otherto form an overlay network

R[si(e� )] =Psmaxi=1 R[si(e� )]

smax (4)

R[si(�j)] =Psmaxi=1 [(P�maxj=1 R[si(e�j )])=(�max)]

smax (5)

6.4 Delivery SemanticsThis refers to the quality of message delivery which the

event broker network provides a subscriber with. Deliverysemantics come into play at the last hop, i.e., just beforethe notification reaches the subscriber. They are dependenton two values -Reliability for an event type, i.e. Relia-bility Factor rf , calculated as shown in 2 and support forDuplicatemessages, i.e.,�a. The lowest level of a deliveryguarantee isbest effort. Gryphon [2] followsexactly oncedelivery semantics even during periods of disconnection.

:[rf ] ^ [�a] (6)

As can be seen from 6, it does not require the network tobe reliable. The notifications are sent without any guaran-tee of delivery and duplication. Theat most oncedeliverysemantic as shown in equation7,

:[rf ] ^ :[�a] (7)

ensures that a subscriber receives maximum one notificationof an instance of an event type. However, it may receivemultiple notifications from different event types, which ithas subscribed for. Theat least oncedelivery semantic asdescribed in 8

[rf ] ^ [�a] (8)

ensures that the subscriber receives at least one notificationof an instance of an event type. So the subscriber can re-ceive multiple notifications of the same event type, albeitfrom different instances of that event type. Theexactly oncedelivery semantic, described in 9

[rf ] ^ :[�a] (9)

ensures that the subscriber receives a notification from ex-actly one instance of an event type.

6.5 Message OrderingThis identifies the sequence in which the notifications

are delivered to the subscriber(s) w.r.t the order they werepublished. The event broker network, may adopt a defaulttemporal ordering in the form ofFirst In First Out, (FIFO)or Last In First Out, (LIFO).If � is a time stamp associated with eventse of type �i,

�j in the system, andn is notification message then FIFOordering is expressed as shown in 10 and LIFO messageordering maybe expressed as shown in 11.

�[e(�i)] � �[e(�j)]) n[e(�i)]! n([e(�j)] (10)

�[e(�i)] � �[e(�j)]) :(n[e(�i)]! n[e(�j)]) (11)

If the notifications are not ordered, we assume that the de-fault ordering is eitherrandomor unordered. Another formof ordering isTotal Ordering. In this case, if an event notifi-cation of an event type is to be sent to multiple subscribers,then it is desirable that all notifications of the event type aredelivered in the same order to all subscribers. Assume thatn andn

0

are the notifications events received at subscriberssands

0

for event types�i and�j . The total ordering seman-tics are given in 12

n[e(�i)] � n[e(�j)]) :(n0 [e(�j)] � n0 [e(�i)]) (12)

Causal Ordering, is required, if the order between events isdefined on the basis of a relative cause-effect relationship.All events in Jedi are causally ordered. Casual ordering canbe expressed as shown in 13

e(�i)! e(�j)) n[e(�i)]! n[e(�j)] (13)

Prioritization of messages is a form of ordering, in whichpriority numbers are assigned to events when published, andordering is done based on these priorities. A higher prior-ity event notification can preempt a lower priority one. Ifpdenotes the publication of evente of type�i, �j , then prior-itization in an event based system is expressed as shown in14

p[e(�i)] < p[e(�j)]) n[e(�i)]! n[e(�j)] (14)

6.6 DiscussionIn this section, we have identified an important set of

quality of service parameters. As can be seen from Table1, most of the existing middleware, either do not support orprovide limited support for service guarantees. Latency isassumed to be a default QoS parameter when routing eventnotifications. IndiQos is the only existing effort in this area,which explores latency and bandwidth as QoS parametersin detail. Reliability, Message Ordering and Delivery Se-mantics have been supported on a limited scale so far. Her-mes reliability model has two aspects - the robustness of themiddleware against failures and the reliability that is explic-itly demanded by clients through a quality of service(QoS)specification. Hermes routing algorithms use built-in fault-tolerance features which enable event brokers to recover to aconsistent system state after failure. However Hermes doesnot provide support for reliability specified by the client asa service guarantee. We present the details in Table 2 in theAppendix A.

Figure 9. Adaptation Triggers in Middleware

7 Adaptation in Middleware

As seen in the previous section, EBMs have a set of com-mitted service guarantees. Certain events that occur afterthe deployment of the application in the system, may resultin the violation of these service guarantees. The middle-ware, then has to execute a series of actions, in order toensure service guarantees, despite the occurrence of theseevents. We term such events asadaptation trigger events.Some examples of events belonging to this category aremobility of clients, load variations and advertisements ofevents with special requirements like delivery within a shorttime of publication. We model the adaptation requirementsin event based middleware using this concept ofadaptationtriggers. Based on these adaptation trigger events we clas-sify the EBM as shown in Figure 9.

1. EBM adapting to client related adaptation triggerevents(client mobility)

2. EBM adapting to event model based trigger events(no-tification of an urgent event)

3. EBM adapting resource based trigger events(broker orchannel failure)

7.1 Client Related Adaptation Triggers� Client Mobility can be represented by a ’disconnect’

followed by a ’reconnect’ operation. During the pe-riod of disconnection of a publisher of an event type,there may be multiple subscriptions from different sub-scribers for events (published by the publisher whichis currently disconnected) arriving at the broker wherethe publisher was originally registered. Once the pub-lisher reconnects to a broker node in the network,these subscriptions will be forwarded to the new bro-ker to which the publisher is connected. This trig-gers changes in the routing tables of intermediate bro-kers, and leads to variation of traffic load at the bro-kers. Similar issues arise, when a subscriber discon-nects from one broker and reconnects to another in the

broker network. Modern distributed applications allowsimultaneous mobility of both subscribers and publish-ers, which triggers changes and necessitates adaptivebehavior from the EBM. The service guarantees af-fected by this trigger are latency, bandwidth and re-liability.

� Publishing Rate Variations- The changes in the fre-quency of events may result in increase or decreaseof traffic on the communication channels. If the fre-quency of occurrence of an event increases beyonda threshold (the buffer space available at the brokernode, or bandwidth of communication channels) bufferoverflows, traffic congestion and communication delaymay occur at some channels. In other words this resultsin load unbalancing in the broker network. Similarlywhen the publishing rate decreases some channels maybecome relatively free and they can invite more trafficthrough those links. Thus traffic load redistribution isdemanded by this trigger event. Service guarantees af-fected as a result of this trigger are latency, bandwidthand reliability.

7.2 Adaptation Triggers Related to theEvent Model

� Secure Event Notifications-Notifications of eventswhich are defined to be ’secure’, trigger the securetransmission of the event. Event demarcated as ’se-cure’ will be routed through specific brokers only,which have the encryption rules defined.

� Urgent Event Notifications- An event may have aTTL (Time to live) value associated with it, in whichcase, the event notification is valid, only if it is deliv-ered to the client within the TTL. Such event notifi-cations, trigger the finding of express paths (or pathswhich can route the event within the specified TTL).Service guarantees affected by this trigger are latencyand ordering of events.

7.3 Adaptation Triggers Related toChanges in Resource Availability

� Failure of link/broker- This results in non-delivery ofevents which are routed through these links or brokers.Once the failure is detected, alternate paths need to beestablished to the destinations whose routes have beendisrupted due to the link/broker failures. This is animportant adaptation trigger event, for maintaining re-silience of the broker network. Service guarantees af-fected by this trigger are latency, bandwidth and relia-bility.

� Resource Availability Variation- Introduction of ahigh bandwidth link, increase in size of buffer of a bro-ker node, withdrawal of a high speed link in the phys-ical network etc will all result in changes on the eventdissemination trees which have already been estab-lished based on the resource availability at that pointof time. For example the express paths developed forsome urgent event types will need to be re-established,if any of the physical links are replaced with a lowbandwidth physical carrier. This triggers a series ofactions in the event broker network. Service guaran-tees affected by this trigger are latency, bandwidth andreliability.

7.4 DiscussionIn this section, we have discussed the idea of dynamic

adaptation in event based middleware using the concept ofadaptation trigger events. The classification in Table 2,shows that few of the existing middleware, support clientlevel and event model level adaptation triggers. Howeversecure/urgent event notifications, link/broker failures andresource availability variation are not addressed by most ex-isting middleware projects. We present the details in Table2.

8 Research Issues

In this section, we discuss the research issues which havecome about as a result of this survey.

� Support for Quality of ServiceIt is apparent from this survey, that providing serviceguarantees in an event based middleware is still in itsnascent stages, as most existing middleware, do notfully support any of the quality of service parametersthat have been identified. While some of the param-eters such as latency have been studied individuallyidentifying and resolving issues brought about by theinterplay of QoS parameters is yet to be done. We viewthese issues to be involving aprogramming modelforQoS-expression and an accompanyingrun timeto re-solve architectural issues related to a distributed imple-mentation of QoS.

� Adaptation in event based middlewareAnother area rich in research potential appears to bethat of dynamic adaptation. This involves challengeslike identifying triggers that cause adaptation, dynamicreconfiguration of topology to ensure service guaran-tees, extending event dissemination algorithms (con-tent/topic/type based), and exploring issues broughtabout by mobility of clients. Detecting and reacting tofailures both the overlay and underlay levels remain to

be explored. Adaptive load distribution and resilienceto path outages in event broker networks, are also top-ics which have been touched upon only lightly so far.

� MiscellaneousOther issues worthy of consideration include ensur-ing QoS under hierarchical and compositional relation-ships between events and exploring paradigms of as-pect oriented programming, late binding and compo-nent based design for achieving dynamic adaptation inevent based systems.

9 Conclusion

This paper presented a taxonomy of an adaptive eventbased middleware with support for quality of service guar-antees. The taxonomy identifies only those set of functionalcharacteristics of a middleware, which come into play whenguaranteeing QoS or during adaptation. These character-istics form a part of thecore of the middleware, withoutwhich the functioning of any event based middleware wouldbe incomplete. The taxonomy further identifies a set ofnon-functional characteristics of a middleware, which aretermed as quality of service parameters, and provides a def-inition of each of the parameters, in the context of an eventbased system. The taxonomy also identifies adaptation trig-gers and their applicability in the core of the middleware.The taxonomy can easily be extended for any quality of ser-vice parameters, or adaptation triggers they may be identi-fied in the future. The classification based on this taxonomy,not only identifies the lack of support for service guaran-tees in an event based middleware, but also defines the re-quired characteristics for architecting a middleware whichwill provide support for QoS guarantees and be adaptive innature.

References

[1] F. Araujo and L. Rodrigues. On QoS-aware publish-subscribe. InICDCSW 2002. In proceedings of the 22ndInternational conference of Distributed Computing SystemsWorkshops, pages 511– 515, Vienna, Austria, 2002. IEEEComputer Society.

[2] S. Bhola, R. Strom, S. Bagchi, Y. Zhao, and J. Auer-bach. Exactly-once Delivery in a Content-based Publish-Subscribe System. InProc. of the Int. Conf. on DependableSystems and Networks (DSN’2002), pages 7–16, 2002.

[3] F. Cao and J. P. Singh. MEDYM: Match- Early and DynamicMulticast for Content-Based Publish-Subscribe Service Net-works. InProceedings of the Sixth International Conferenceon Middleware, volume 3790, pages 292–313. LNCS, 2005.

[4] A. Carzaniga. Architectures for an Event Notification Ser-vice Scalable to Wide-area Networks. PhD thesis, Politec-nico di Milano, Italy, 1998.

[5] G. Cugola, E. D. Nitta, and A. Fuggetta. The JEDI eventbased infrastructure and its application to the developmentof OPSS WFMS.IEEE Transactions on Software Engineer-ing, 27(9):827–850, September 2001.

[6] D. Doval and D. OMahony. Overlay Networks a scalable Al-ternative for P2P. InIEEE Internet Computing July-August2003, volume 7, 2003.

[7] P. T. Eugster, R. Guerraoui, and J. Sventek. Dis-tributed Asynchronous Collections: Abstractions for Pub-lish/Subscribe Interaction. InECOOP 2000 - Object-Oriented Programming: 14th European Conference, page252, Cannes, France, 2000. Springer-Verlag.

[8] I.Clarke, O. Sandberg, B. Wiley, and T. Hong. Elvin has leftthe Building: A Publish/Subscribe Notification Service withQuenching. InIn Proceedings of AUUG Technical Confer-ence ’97, Brisbane, Australia, 1997.

[9] I.Clarke, O. Sandberg, B. Wiley, and T. Hong. Freenet:A distributed anonymous information storage and retrievalsystem. InInternational workshop on design issues inanonymity and nobservability 2000, volume 2009/2001,page 46, Berkeley, CA, USA, 2000. LNCS.

[10] M. Kumar and U. Bellur. An Underlay Aware, AdaptiveOverlay for Event Broker Networks. InProceedings ofthe Fifth International Workshop on Adaptive and ReflectiveMiddleware (To appear), 2006.

[11] B. E. Martin, C. H. Pedersen, and J. Bedford-Roberts. AnObject-Based Taxonomy for Distributed Computing Sys-tems.Computer, 24(8):17–27, August 1991.

[12] R. Meier and V. Cahill. Taxonomy of Distributed Event-Based Programming Systems.The Computer Journal,48(5):602–626, June 2005.

[13] P. Pietzuch.Hermes - A Scalable Event-Based Middleware.PhD thesis, Queens College, University of Cambridge, UK,2004.

[14] P. Pietzuch and J. Bacon. Peer-to-Peer Overlay Broker Net-works in an Event Based Middleware. InICDCSW ’03:Proceedings of 2nd International Conference on DistributedEvent Based Systems, pages 1–8. IEEE Computer Society,2003.

[15] S. Rhea, B. Godfrey, B. Karp, J. Kubiatowicz, S. Ratnasamy,S. Shenker, I. Stoica, and H. Yu. OpenDHT: A Public DHTService and Its Uses. InProceedings of the 2005 conferenceon Applications, Technologies, Architectures, and Protocolsfor Computer Communications, pages 73–84, Philadelphia,Pennsylvania, USA, 2005. ACM Press.

[16] A. Rowstron and P. Druschel. Pastry: Scalable, decentral-ized object location and routing for large-scale peer-to-peersystems. InIFIP/ACM ’01: Proceedings of 18th IFIP/ACMInternational Conference on Distributed Systems Platforms,2001.

[17] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Bal-akrishnan. Chord: A Scalable Peer-to-peer Lookup Servicefor Internet Applications. InSIGCOMM ’01: Proceedingsof the ACM SIGCOMM ’01 Conference, August 2001.

[18] P. Th.Eugster, P. Felber, R. Guerraoui, and A. M. Kermar-rec. The Many Faces of Publish/Subscribe.ACM ComputingSurveys(CSUR), 35(2):114–131, 2003.

[19] P. Th.Eugster, R. Guerraoui, and C.H.Damm. On Objectsan Events. InOOPSLA ’96. Proceedings of the 16th ACM

SIGPLAN conference on Object oriented programming, sys-tems, languages, and applications, pages 254–269, TampaBay, FL, USA, 2001. ACM Press.

A Appendix

Here we present a classification of EBMs, based on their functional characteristics, and the support they provide for qualityof service parameters. We have picked the most popular EBMs available today as a basis for this classification. Jedi, Siena,Hermes and IndiQoS provide partial support for some of the service guarantees we have identified in Section 6. Siena doesnot provide support for any QoS parameters, but describes an event model, comprising of single or multiple event servers,with different overlay topologies used in routing events. Table 2 gives us a clear insight into the current level of supportprovided by existing middleware for service guarantees and adaptation, while Table 1, classifies existing efforts based on thefunctional characteristics required for architecting such a middleware. Finally, Table 3 highlights the QoS parameters whichare directly affected as a result of the adaptation triggers being generated in an event based middleware, thus bringing out theinterplay between them.

Table 1. Classification of Event Based Middleware

Middleware Event Model Overlay Topology Subscription Scheme

Elvin Events represented asstrings. No composition orhierarchy of events.

Underlay Unaware - StarTopology (Static)

Content Based

Jedi Object Based (Active Ob-jects and Event Dispatcher).No hierarchy or compositionof events.

Underlay Unaware - Hier-archical Event Dispatcher(Static)

Content Based - Patternmatching of events

Siena Pattern based model in theform of a triplet (name, type,value). No hierarchy orcomposition of events.

Underlay Unaware - Acyclicpeer to peer, Hierarchical orHybrid topology (Static)

Content Based

Gryphon No hierarchy or compositionof events.

Underlay Aware. Hierarchi-cal Structure, with publisherhosting broker as root andsubscriber hosting broker asleaf

Content Based

Hermes Object Based. Supportsevent hierarchy and compo-sition.

Underlay Aware - Hybrid(Static)

Hybrid - Type based andType and Attribute Based

Rebeca No hierarchy or compositionof events.

Underlay Unaware - Hier-archical, symmetrical andacyclic tree like topology

Content Based with cover-ing and merging of filters

Medym No hierarchy or compositionof events.

Underlay Aware (proximity)overlay

Content based

IndiQoS Object Based with QoS Pro-files. No hierarchy or com-position of events.

Underlay Aware - Hybrid(Static)

Type Based

Table 2. Classification of Middleware Based on Support for QoS and Adaptation

Event Based MiddlewareElvin Jedi Siena Gryphon Hermes Rebeca Medym IndiQoS

QoS Supported ParametersLatency N N N N N N N Y

Bandwidth N N N N N N N YReliability N N N N Y N Y N

Delivery Semantics N N N Y N N N NMessage Ordering N Y N N N N N N

Adaptation Applicable at LevelEvent Model N N N N N N N N

Overlay Topology N N N N Y N Y NRouting Scheme N N N N Y N Y N

Adaptation TriggersClient Movement N Y Y Y N N N N

Publishing Rate Variation Y Y Y Y Y Y Y NSecure Event Notification N N N N N N N NUrgent Event Notification N N N N N N N N

Link Failure N N N Y N N Y NBroker Failure N N N N Y N Y N

Availability Variation N N N N N N N N

Table 3. Classification of QoS and Adaptation Triggers

QoS ParametersLatency Bandwidth Reliability Ordering Del Semantics

Adaptation Trigger - ClientClient Movement Y Y Y N N

Publishing Rate Variation Y Y Y N N

Adaptation Trigger - Event ModelSecure Event Notification N N N N NUrgent Event Notification Y N N Y N

Adaptation Trigger - ResourceLink Failure Y Y Y N N

Broker Failure Y Y Y N NAvailability Variation Y Y Y N N