A Taxonomy and Classification of Adaptive Event

A Taxonomy and Classification of Adaptive Event Based Middleware with Support for Service Guarantees Shruti P. Mahambre, Madhu Kumar S.D. and Umesh Bellur KReSIT, IIT Bombay, Mumbai, India fshruti, madhu, [email protected]

A Taxonomy and Classification of Adaptive Event Based Middleware with Support for Service Guarantees Shruti P. Mahambre, Madhu Kumar S.D. and Umesh Bellur KReSIT, IIT Bombay, Mumbai, India fshruti, madhu, [email protected] Abstract Event Broker Networks are scalable versions of the publish subscribe paradigm that take the form of P2P overlays of broker nodes. Several routing schemes help disseminate events efficiently from publishers to subscribers on different overlay topologies. While there exist various frameworks that demonstrate several overlay topologies and routing schemes, attention has now turned to exploring nonfunctional attributes of such systems. Although many efforts have started addressing these needs, there does not exist a taxonomy and a comprehensive survey of adaptive event based middleware with provision for service guarantees. In this effort, we first present a detailed taxonomy and a survey of existing event based middleware efforts, centered around qualities of service and adaptation. In the process of putting together this survey we have also identified open research problems in the area.

1

Introduction

Event Broker Networks (EBNs) are a scalable incarnation of the asynchronous computing paradigm that take the form of overlay networks and provide decentralized routing, to disseminate application level events from publishers to subscribers. Middleware, that operates on these broker nodes, alleviates the issues related to the heterogeneity of underlying platforms and provide a uniform interface to applications written on them. A common service interface provided by such middleware is that of publish-subscribe (pub-sub) [18]. In a pub-sub paradigm, the producers publish information, consumers subscribe to this information, and receive notifications for the same. Information of interest is encapsulated in a structure termed an event. The middleware provides for storage and management for subscriptions and for routing events. The fully decoupled nature in terms of time, space and synchronization [18],

makes this model highly suitable for large scale distributed applications. EBN overlay network [14] is an abstraction that uses a subset of the underlying existing physical network. An overlay link is virtual, may consist of many physical links in the underlying network. The middleware executes on each of these overlay nodes that work cooperatively to accomplish their functions. Event based architectures are employed in various domains many of which themselves expose and hence require qualities of service guarantees of the underlying infrastructure. However, our survey indicates significant gaps in addressing these needs and that few middleware [13], [1], [5], provide support for such non functional service guarantees. However there does not exist a comprehensive survey of existing event based middleware, based on their support for quality of service guarantees and adaptation. In this effort, we present a survey of existing event based systems, classified based on a taxonomy of adaptive event based middleware, providing quality of service guarantees. Our taxonomy provides a basis for architecting a middleware with the above mentioned features, and also highlights research issues in this area. The rest of this paper is organized as follows. In the next section, we discuss how the taxonomy is structured and may be exploited by users, when classifying event based systems. In Section 3, we differentiate our work with existing approaches to middleware classification. Section 4 presents our architecture of an adaptive event based middleware which provides support for quality of service guarantees. We present a detailed taxonomy of the core features of the middleware in Section 5. We define QoS parameters relevant to an event based middleware in Section 6 and identify Adaptation Triggers in Section 7. We identify key research issues, which are an outcome of this classification in Section 8 and conclude in Section 9. A classification of existing event based middleware,

illustrating the usage of the taxonomy appears in the Appendix.

2

Structuring the Taxonomy

Our taxonomy is structured as a hierarchy of properties that serve as a basis for identifying features, required by an event based system, in order to ensure service guarantees in an adaptive manner. The taxonomy will lead to identification of groups of systems and also layout the functional characteristics that come into play when providing QoS guarantees and support for adaptation. Figure 1 illustrates the notation of the taxonomy hierarchy.

Figure 1. Taxonomy Key

3 Related Work The taxonomy presented in Meir et al. [12] deals with classification of existing event based systems as a programming paradigm. It identifies fundamental properties of event based middleware and classifies them broadly based on event model and event service criteria, with a further classification on the basis of its functional and non functional features and its organization and interaction model. Even though we do start with core functionality, our focus is quality of service guarantees and adaption in middleware rather than programming models for functional aspects of EBMs. We also extend the definition of an event model as a communication model in [12] by taking into account, event characteristics such as, attributes, hierarchical and compositional relationships between event types. Eugster et al. [18], present a detailed survey of event based systems, which is based on a common denominator of the various modes of decoupling in asynchronous systems. Decoupling is discussed in three dimensions, in terms of time, space and synchronization. The main focus of the paper however is on implementation issues underlying the publish/subscribe schemes, and how these issues have been addressed in existing middleware. This paper also identifies some common qualities of service relevant in the pub-sub paradigm. We use this paper as a basis for our work, in identifying features that will require to form an inherent part of any event based system, that intends to support quality of service guarantees and classify them. Martin et al. [11], present a taxonomy, as a hierarchy of questions and answers, about the features of distributed computing

Figure 2. Architecture of Adaptive Middleware with QoS Support

systems (DCS). This taxonomy, though not specific to the pub-sub paradigm, can be used to compare existing general purpose distributed computing systems and provides a means to classify systems and also serves as a basis for designing a DCS that offers novel combinations of features. Existing taxonomies focus on classifying event based middleware based on their event model. However as can be seen, there is no effort so far in the direction of classifying event based middleware based on their support for QoS and adaptation. In this effort, we leverage the work done so far, in terms of classification based on the event model, and categorize existing event middleware, on the basis of their support for quality of service guarantees and adaptation. The classification also highlights the level of support for adaptation and service guarantees in the existing event based middleware and brings out key research problems that need further attention.

4

Middleware Architecture

As shown in Figure 2, we represent an event based middleware in the form of a layered architecture. We distinguish the core of the middleware, from the services it provides, as follows. The core comprises of mandatory functional features such as the event model, the subscription scheme used to disseminate events in the model and the overlay routing substrate which facilitates this routing (for event dissemination). The layer on top of the core forms a set of optional services known as the non functional, quality of service guarantees that the middleware provides. Reliability, Delivery Semantics, Message Ordering, Security, and Fault Tolerance are some of the services which a middleware may support. The QoS programming model comprises of the QoS specification provided by the user which is then translated into the required resource reservation. These qualities of service guarantees are orthogonal to the core functions supported by the middleware. The capability of the middleware to reconfigure itself, in order to ensure and maintain a quality of service agreement, is adaptability.

object define the event properties. Jedi [5] uses pattern (or string) matching to identify events occurring in the system while Siena [4] models an event in the form of a triplet as follows . Multiple event types can be now related to one another by a hierarchy or compositional relationship.

Figure 3. Core of the Middleware

Figure 4. The Event Model Adaptability may result in changes in the core of the middleware like the subscription scheme or the overlay routing substrate.

5 Taxonomy of Event Based Middleware 5.1

Core

As can be seen from Figure 3 our taxonomy begins with this differentiation between feature functionality and qualities of service properties. The core can be further categorized into the event model, overlay routing substrate and subscription scheme. 5.1.1

 Event Hierarchy: A new event type may be defined by inheriting from an existing event type and extending it leading to a hierarchy of event types and enabling polymorphic dispatch of events in the system. A subscriber subscribing to a supertype receives notifications from all subtypes of the event, as well as the supertype. DAC [7] supports a topic based event hierarchy, i.e., events in DAC are represented in the form of topics. Subscribers express their interest in these topics, and notifications are sent for the subscribed topic along with notifications for all its subtopics. In Hermes, every rendezvous node1 is aware of its descendent types, and hence, subscriptions to the parent rendezvous node, can be supported by inheritance routing.  Event Composition: Composite Events [13] provide a higher level of abstraction for event subscribers. A composite event service enables complex event patterns, as opposed to subscribing to all primitive events which make up the pattern and then form the detection themselves. The Hermes [13] middleware, provides support for a composite event service. Composite events maybe temporal or spatial in nature. Temporal composite events lead to the formation of a composite based on temporal dependencies between primitive events. Spatial composite events are unrelated in time, and are published based on a pattern of event subscriptions observed by the composite event detection engine.

Event Model 5.1.2

In any EBM, subscribers transmit subscriptions in the overlay network, with filters to filter out non-matching data elements from the event notifications and publishers float advertisements regarding the occurrence of a new event type. The event model is comprised of these three messages event advertisement, event notification and event subscription. The event model also defines the attributes of events uniquely identifying an event on the basis of its event identifier, event name, event type or the temporal or persistent nature of an event and offers additional information such as anonymity of publishers and subscribers. The event may also be characterized by the kind of data it stores. For e.g., the data contained in an event may have access control information associated with it i.e., it could be private or public. Hermes [13] follows an object model, in which every event is represented as an object, and the attributes of the

Overlay Routing Substrate

EBMs may also be categorized on the basis of its overlay routing substrate (Figure 5) that provides an IP address independent abstraction upon a physical underlay. A middleware architecture may support one or multiple overlay network topologies. Overlay networks are also useful in providing service guarantees and can be deployed using end hosts running overlay protocol software without depending on routers and ISPs. We have a threefold basis for categorizing overlay substrates:

 Node lookup protocol- The node lookup protocol refers to the protocol used when locating a node(object) in an overlay network. Based on the node 1 A rendezvous node is a node which houses events of a particular event

type

based on distributed hash tables, which use logical identifiers to identify overlay nodes in the network. The logical identifiers of the overlay nodes and the identifiers of the neighbors of a node are generated based on a random hash function. The overlay assumes full network connectivity and does not measure any of the physical network properties in the overlay construction process. Chord [17] constructs underlay unaware overlays.

Figure 5. Overlay Routing Substrate lookup protocol, overlay networks can be classified as content addressable overlays and flooding style overlays [6]. – Content Addressable Overlays: Here the network topology and the content of the objects are related. DHT [15] based techniques are used to convert object identifiers into overlay node identifiers. They provide the guarantee for locating an object if present, and search times are bounded. Pastry [16] and Chord [17] are content addressable overlays. – Flooding Style Overlays: Here object lookup is based on Time To Live (TTL) controlled flooding. A node looking for a particular key value, sends the request to all its known neighbors with a particular value for TTL. The neighbors will reply to the request by looking for a match to the keys in their local databases. If the neighbors find a match, they reply, else they forward the request to their known neighbors after increasing the Messagess hop count. If the hop count passes the TTL value, the forwarding stops. Unless the TTL is set to a very high value , there is a chance that the object will not be located even though it is present in some node. These topologies are unstructured and the topology is decided by factors like the join order of nodes and physical proximity. Freenet [9] is an example of flooding style overlays.

 Underlay Awareness- Next we categorize overlays based on their underlay awareness properties. The overlay network may be either aware of the underlying physical network topology or unaware of the underlying physical network topology. – Underlay Unaware overlays are constructed

– Underlay Aware overlay construction strategy maintains correspondence between the physical and the overlay networks. The overlay construction strategy considers some of the properties of the underlying physical network like path disjointness (absence of common nodes or physical links in different overlay paths), hop count (number of physical nodes between a pair of overlay nodes), bandwidth , physical distance information and failure statistics of the physical links and nodes. Thus the overlay network is sensitive to the changes in the underlying physical network, i.e., the overlay dynamically adapts to the resource based adaptation triggers. We further categorize the underlay aware overlay networks as Underlay Proximity Aware and Underlay Quality Aware overlays. Underlay proximity aware overlays reflect only the network proximity of the physical nodes. For example, while adding a new node into the overlay, a ping message is broadcast to all the nearby nodes, and the nearest neighbor is chosen based on the round trip time. No other underlay parameter is used in the overlay construction and maintenance. Pastry [16], Medym [3] and Hermes [13] belong to this category. The granularity of underlay awareness can be extended to physical link quality, failure probabilities, degree of nodes, diameter of the physical network and QoS guarantees of the underlying nodes and links. We call these overlays as Underlay Quality aware overlays. Here the overlay construction is based on the physical networkss qualitative parameters mentioned above. For example, the failure statistics information of the underlying links and physical nodes in the various physical paths possible can be used to select a reliable path for an overlay link. Also information regarding the degree of physical nodes is useful when constructing an overlay which lays emphasis on the degree of availability [10]. This work discusses how the diameter information can be used to constrain the maximum delay in the overlay network. The overlay network is adap-

tive to the resource based triggers involving the changes in these properties. At present there is no reported work on Underlay Quality aware overlay networks which are used in Event Based Middleware to the best of our knowledge.

 Structure of topology- Finally, we categorize overlay networks, based on the structure of their overlay network topology. We have identified a set of topologies on which most of the existing event based middleware are based. These topologies determine the formation of event dissemination trees in the event based middleware, when routing event notifications. We will discuss these topologies in detail. All the event based middleware studied as a part of this survey adhere to one or a combination of the topologies discussed below. However this taxonomy could be extended to accommodate newer topologies. – Hierarchical Topology [4] : The nodes are connected in a hierarchy of parent-child relationships and hence form a tree like structure. Each server in the topology has a number of clients that may be publishers, subscribers or intermediate brokers in the network. The parent server is able to receive notifications, advertisements and subscriptions from all its clients, but will only send back notifications. Jedi uses a hierarchical overlay topology for dispatch of events. – Acyclic Topology [4]: The servers communicate with each other as peers. The links between servers are non-directed and the server connections produce an acyclic graph. This enables bidirectional flow of flow of subscriptions, advertisements and notifications. – Non-Acyclic Topology [4] removes the constraint of an acyclic graph from acyclic topology. This topology allows bi-directional communication amongst two servers. However, there may exist multiple paths between servers. This makes the topology robust and resilient to failures, but could also lead to cycles. – Hybrid Topology supports a combination of topologies, i.e., it exhibits different topologies at different levels of granularity. Siena [4] poses a good example of a hybrid topology. For eg: Some clusters of subnets in Siena have very intense traffic of local events, and only a small fraction of these events is visible outside the cluster. Here, for efficiency reasons, a generic graph topology might be preferable inside the cluster while the high-level topology could be set up as an acyclic graph.

Figure 7. Subscription Scheme of the Middleware

5.1.3

Subscription Scheme

As shown in Figure 7, this refers to the semantics followed by the subscribers when specifying their interest in an event, and by publishers when publishing or advertising an event. In Topic/Subject Based Scheme, participants publish events and subscribe to individual topics. Each topic is identified by a keyword. This is similar to group communication, where similar topics are grouped together. Topics can overlap, leading to a hierarchy as in DAC. In the Content Based Scheme subscriptions are based on the actual content of the event enabling a fine grained search, as compared to the topic based scheme. The properties of the events maybe internal attributes of the data structures carrying the events. Examples are Jedi [5], Siena and Elvin [8]. In a Type Based Scheme, events are classified according to their type [19]. A type represents commonalities in structure and content and facilitates a closer integration of the language and the middleware. IndiQoS [1] and Hemres support type based routing scheme. Finally the Hybrid Scheme is as the name suggests a combination of the routing schemes discussed above. 5.2

Discussion

We have thus far categorized an EBM according to its functional characteristics. Each of these properties will need to be considered while providing service guarantees. For example: composite event models may dictate the upper bound on the latency of the notification and the type of overlay topology may restrict the set of routes available to choose from when looking to provide reliable delivery. In the following section we present an extension of the taxonomy with service guarantees, in detail.

6

Quality of Service

As seen in Figure 2, an event based middleware may optionally provide support for QoS guarantees. These service guarantees, follow a publisher-offered, subscriberrequested pattern. It is the task of the event-broker network to ensure that the quality constraints are met, when delivering events. As shown in Figure 8, we have identified five

Figure 6. Non Acyclic, Hierarchical, Acyclic Topologies 6.2

Bandwidth

Bandwidth represents the resources, available across the path during event transfer - which is denoted by the number of events being transferred between publisher and subscriber, per time unit. If a subscriber does not specify a requirement, then default values are assumed, which provide the maximum possible bandwidth available along a path. IndiQos provides support for Latency and Bandwidth parameters. IndiQoS uses Netpipe, which is an Infopipe2 responsible for transferring events between different hosts. The length of the Netpipe represents the latency and the width of the Netpipe represents its maximum bandwidth. Figure 8. QoS in Middleware

6.3

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

6.1

Latency

Also known as time to delivery, is defined as time between a publisher publishing an event and a subscriber for the same event, receiving a notification for the same, w.r.t an independent observer. It is the task of the overlay network to effectively reduce the overall, latency of event notifications, in an event broker network. If Td represents the transmission delay, Pd represents the propagation delay (this is constant for a network), Qd represents the buffering/queuing delay, e represent an event of type  , and n is the total number of nodes occurring in the path between a publisher and subscriber, then the latency L(e ) for a single notification of an event of type  between a publisher and subscriber, is given as follows:

X L(e ) = n(P ) + (T [i] + Q [i]) d

d

i=1

d

Reliability in an event based system is defined as the ratio of number of successful notifications, to the number of events published of that type. Assume that n(e ) represents the number of notifications sent for an event type  and p(e ) is number of publications of event of type  , The reliability R attained at subscriber s is given by 2.

R[s(e )] = np((ee )) 

(1)

(2)

Using equation 2, reliability is measured at different levels in an event based system The delivery reliability for the notification of an event type, is measured for a single subscriber subscribing for a single event type. A subscriber may subscribe for multiple event types. However we measure the reliability that the subscriber attains for each event type that it has subscribed for. This is given by 2. The reliability attained by a subscriber for all the event types e(j ), it has subscribed for, is given by 3. The reliability offered by the entire system for a specific event type, can be calculated across all the subscribers as shown in 4. And finally using 3 and 4 the reliability of the entire system is as given by 5.

R[s(ej )] =

n



Reliability

P

max j =1

R[s(ej )]

emax

(3)

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

R[si (e )] = R[si (j )] = 6.4

P

smax i=1

P

smax i=1

R[si (e )]

smax

[(Pjmax =1 R[si (ej )])=(max )] smax

j in the system, and n is notification message then FIFO

(4)

(5)

Delivery Semantics

This refers to the quality of message delivery which the event broker network provides a subscriber with. Delivery semantics come into play at the last hop, i.e., just before the notification reaches the subscriber. They are dependent on two values - Reliability for an event type, i.e. Reliability Factor rf , calculated as shown in 2 and support for Duplicate messages, i.e., a . The lowest level of a delivery guarantee is best effort. Gryphon [2] follows exactly once delivery semantics even during periods of disconnection.

:[rf ] ^ [a ]

(6)

As can be seen from 6, it does not require the network to be reliable. The notifications are sent without any guarantee of delivery and duplication. The at most once delivery semantic as shown in equation7,

:[rf ] ^ :[a ]

(7)

ensures that a subscriber receives maximum one notification of an instance of an event type. However, it may receive multiple notifications from different event types, which it has subscribed for. The at least once delivery semantic as described in 8 [rf ] ^ [a ] (8) ensures that the subscriber receives at least one notification of an instance of an event type. So the subscriber can receive multiple notifications of the same event type, albeit from different instances of that event type. The exactly once delivery semantic, described in 9

[rf ] ^ :[a ]

(9)

ensures that the subscriber receives a notification from exactly one instance of an event type. 6.5

Message Ordering

This identifies the sequence in which the notifications are delivered to the subscriber(s) w.r.t the order they were published. The event broker network, may adopt a default temporal ordering in the form of First In First Out, (FIFO) or Last In First Out, (LIFO). If  is a time stamp associated with events e of type i ,

ordering is expressed as shown in 10 and LIFO message ordering maybe expressed as shown in 11.

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

(10) (11)

If the notifications are not ordered, we assume that the default ordering is either random or unordered. Another form of ordering is Total Ordering. In this case, if an event notification of an event type is to be sent to multiple subscribers, then it is desirable that all notifications of the event type are delivered in the same order to all subscribers. Assume that 0 n and n are the notifications events received at subscribers 0 s and s for event types i and j . The total ordering semantics are given in 12

[ ( )]  n[e(j )] ) :(n [e(j )]  n [e(i )]) 0

n e i

0

(12)

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

( )

( )

[ ( )] ! n[e(j )]

e i ! e j ) n e i

(13)

Prioritization of messages is a form of ordering, in which priority numbers are assigned to events when published, and ordering is done based on these priorities. A higher priority event notification can preempt a lower priority one. If p denotes the publication of event e of type i , j , then prioritization in an event based system is expressed as shown in 14

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

p e i 6.6

(14)

Discussion

In this section, we have identified an important set of quality of service parameters. As can be seen from Table 1, most of the existing middleware, either do not support or provide limited support for service guarantees. Latency is assumed to be a default QoS parameter when routing event notifications. IndiQos is the only existing effort in this area, which explores latency and bandwidth as QoS parameters in detail. Reliability, Message Ordering and Delivery Semantics have been supported on a limited scale so far. Hermes reliability model has two aspects - the robustness of the middleware against failures and the reliability that is explicitly demanded by clients through a quality of service(QoS) specification. Hermes routing algorithms use built-in faulttolerance features which enable event brokers to recover to a consistent system state after failure. However Hermes does not provide support for reliability specified by the client as a service guarantee. We present the details in Table 2 in the Appendix A.

broker network. Modern distributed applications allow simultaneous mobility of both subscribers and publishers, which triggers changes and necessitates adaptive behavior from the EBM. The service guarantees affected by this trigger are latency, bandwidth and reliability.

Figure 9. Adaptation Triggers in Middleware

7 Adaptation in Middleware As seen in the previous section, EBMs have a set of committed service guarantees. Certain events that occur after the deployment of the application in the system, may result in the violation of these service guarantees. The middleware, then has to execute a series of actions, in order to ensure service guarantees, despite the occurrence of these events. We term such events as adaptation trigger events. Some examples of events belonging to this category are mobility of clients, load variations and advertisements of events with special requirements like delivery within a short time of publication. We model the adaptation requirements in event based middleware using this concept of adaptation triggers. Based on these adaptation trigger events we classify the EBM as shown in Figure 9. 1. EBM adapting to client related adaptation trigger events (client mobility) 2. EBM adapting to event model based trigger events (notification of an urgent event) 3. EBM adapting resource based trigger events (broker or channel failure) 7.1

Client Related Adaptation Triggers

 Client Mobility can be represented by a ’disconnect’ followed by a ’reconnect’ operation. During the period of disconnection of a publisher of an event type, there may be multiple subscriptions from different subscribers for events (published by the publisher which is currently disconnected) arriving at the broker where the publisher was originally registered. Once the publisher reconnects to a broker node in the network, these subscriptions will be forwarded to the new broker to which the publisher is connected. This triggers changes in the routing tables of intermediate brokers, and leads to variation of traffic load at the brokers. Similar issues arise, when a subscriber disconnects from one broker and reconnects to another in the

 Publishing Rate Variations- The changes in the frequency of events may result in increase or decrease of traffic on the communication channels. If the frequency of occurrence of an event increases beyond a threshold (the buffer space available at the broker node, or bandwidth of communication channels) buffer overflows, traffic congestion and communication delay may occur at some channels. In other words this results in load unbalancing in the broker network. Similarly when the publishing rate decreases some channels may become relatively free and they can invite more traffic through those links. Thus traffic load redistribution is demanded by this trigger event. Service guarantees affected as a result of this trigger are latency, bandwidth and reliability. 7.2

Adaptation

Triggers

Related

to

the

Event Model

 Secure Event Notifications- Notifications of events which are defined to be ’secure’, trigger the secure transmission of the event. Event demarcated as ’secure’ will be routed through specific brokers only, which have the encryption rules defined.  Urgent Event Notifications- An event may have a TTL (Time to live) value associated with it, in which case, the event notification is valid, only if it is delivered to the client within the TTL. Such event notifications, trigger the finding of express paths (or paths which can route the event within the specified TTL). Service guarantees affected by this trigger are latency and ordering of events. 7.3

Adaptation

Triggers

Related

to

Changes in Resource Availability

 Failure of link/broker- This results in non-delivery of events which are routed through these links or brokers. Once the failure is detected, alternate paths need to be established to the destinations whose routes have been disrupted due to the link/broker failures. This is an important adaptation trigger event, for maintaining resilience of the broker network. Service guarantees affected by this trigger are latency, bandwidth and reliability.

 Resource Availability Variation- Introduction of a high bandwidth link, increase in size of buffer of a broker node, withdrawal of a high speed link in the physical network etc will all result in changes on the event dissemination trees which have already been established based on the resource availability at that point of time. For example the express paths developed for some urgent event types will need to be re-established, if any of the physical links are replaced with a low bandwidth physical carrier. This triggers a series of actions in the event broker network. Service guarantees affected by this trigger are latency, bandwidth and reliability. 7.4

Discussion

In this section, we have discussed the idea of dynamic adaptation in event based middleware using the concept of adaptation trigger events. The classification in Table 2, shows that few of the existing middleware, support client level and event model level adaptation triggers. However secure/urgent event notifications, link/broker failures and resource availability variation are not addressed by most existing middleware projects. We present the details in Table 2.

8

Research Issues

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

 Support for Quality of Service It is apparent from this survey, that providing service guarantees in an event based middleware is still in its nascent stages, as most existing middleware, do not fully support any of the quality of service parameters that have been identified. While some of the parameters such as latency have been studied individually identifying and resolving issues brought about by the interplay of QoS parameters is yet to be done. We view these issues to be involving a programming model for QoS-expression and an accompanying run time to resolve architectural issues related to a distributed implementation of QoS.  Adaptation in event based middleware Another area rich in research potential appears to be that of dynamic adaptation. This involves challenges like identifying triggers that cause adaptation, dynamic reconfiguration of topology to ensure service guarantees, extending event dissemination algorithms (content/topic/type based), and exploring issues brought about by mobility of clients. Detecting and reacting to failures both the overlay and underlay levels remain to

be explored. Adaptive load distribution and resilience to path outages in event broker networks, are also topics which have been touched upon only lightly so far.

 Miscellaneous Other issues worthy of consideration include ensuring QoS under hierarchical and compositional relationships between events and exploring paradigms of aspect oriented programming, late binding and component based design for achieving dynamic adaptation in event based systems.

9

Conclusion

This paper presented a taxonomy of an adaptive event based middleware with support for quality of service guarantees. The taxonomy identifies only those set of functional characteristics of a middleware, which come into play when guaranteeing QoS or during adaptation. These characteristics form a part of the core of the middleware, without which the functioning of any event based middleware would be incomplete. The taxonomy further identifies a set of non-functional characteristics of a middleware, which are termed as quality of service parameters, and provides a definition of each of the parameters, in the context of an event based system. The taxonomy also identifies adaptation triggers and their applicability in the core of the middleware. The taxonomy can easily be extended for any quality of service parameters, or adaptation triggers they may be identified in the future. The classification based on this taxonomy, not only identifies the lack of support for service guarantees in an event based middleware, but also defines the required characteristics for architecting a middleware which will provide support for QoS guarantees and be adaptive in nature.

References [1] F. Araujo and L. Rodrigues. On QoS-aware publishsubscribe. In ICDCSW 2002. In proceedings of the 22nd International conference of Distributed Computing Systems Workshops, pages 511– 515, Vienna, Austria, 2002. IEEE Computer Society. [2] S. Bhola, R. Strom, S. Bagchi, Y. Zhao, and J. Auerbach. Exactly-once Delivery in a Content-based PublishSubscribe System. In Proc. of the Int. Conf. on Dependable Systems and Networks (DSN’2002), pages 7–16, 2002. [3] F. Cao and J. P. Singh. MEDYM: Match- Early and Dynamic Multicast for Content-Based Publish-Subscribe Service Networks. In Proceedings of the Sixth International Conference on Middleware, volume 3790, pages 292–313. LNCS, 2005. [4] A. Carzaniga. Architectures for an Event Notification Service Scalable to Wide-area Networks. PhD thesis, Politecnico di Milano, Italy, 1998.

[5] G. Cugola, E. D. Nitta, and A. Fuggetta. The JEDI event based infrastructure and its application to the development of OPSS WFMS. IEEE Transactions on Software Engineering, 27(9):827–850, September 2001. [6] D. Doval and D. OMahony. Overlay Networks a scalable Alternative for P2P. In IEEE Internet Computing July-August 2003, volume 7, 2003. [7] P. T. Eugster, R. Guerraoui, and J. Sventek. Distributed Asynchronous Collections: Abstractions for Publish/Subscribe Interaction. In ECOOP 2000 - ObjectOriented Programming: 14th European Conference, page 252, Cannes, France, 2000. Springer-Verlag. [8] I.Clarke, O. Sandberg, B. Wiley, and T. Hong. Elvin has left the Building: A Publish/Subscribe Notification Service with Quenching. In In Proceedings of AUUG Technical Conference ’97, Brisbane, Australia, 1997. [9] I.Clarke, O. Sandberg, B. Wiley, and T. Hong. Freenet: A distributed anonymous information storage and retrieval system. In International workshop on design issues in anonymity and nobservability 2000, volume 2009/2001, page 46, Berkeley, CA, USA, 2000. LNCS. [10] M. Kumar and U. Bellur. An Underlay Aware, Adaptive Overlay for Event Broker Networks. In Proceedings of the Fifth International Workshop on Adaptive and Reflective Middleware (To appear), 2006. [11] B. E. Martin, C. H. Pedersen, and J. Bedford-Roberts. An Object-Based Taxonomy for Distributed Computing Systems. Computer, 24(8):17–27, August 1991. [12] R. Meier and V. Cahill. Taxonomy of Distributed EventBased 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 Networks in an Event Based Middleware. In ICDCSW ’03: Proceedings of 2nd International Conference on Distributed Event 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 DHT Service and Its Uses. In Proceedings of the 2005 conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, pages 73–84, Philadelphia, Pennsylvania, USA, 2005. ACM Press. [16] A. Rowstron and P. Druschel. Pastry: Scalable, decentralized object location and routing for large-scale peer-to-peer systems. In IFIP/ACM ’01: Proceedings of 18th IFIP/ACM International Conference on Distributed Systems Platforms, 2001. [17] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan. Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications. In SIGCOMM ’01: Proceedings of the ACM SIGCOMM ’01 Conference, August 2001. [18] P. Th.Eugster, P. Felber, R. Guerraoui, and A. M. Kermarrec. The Many Faces of Publish/Subscribe. ACM Computing Surveys(CSUR), 35(2):114–131, 2003. [19] P. Th.Eugster, R. Guerraoui, and C.H.Damm. On Objects an Events. In OOPSLA ’96. Proceedings of the 16th ACM

SIGPLAN conference on Object oriented programming, systems, languages, and applications, pages 254–269, Tampa Bay, 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 quality of 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 does not 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 support provided by existing middleware for service guarantees and adaptation, while Table 1, classifies existing efforts based on the functional characteristics required for architecting such a middleware. Finally, Table 3 highlights the QoS parameters which are directly affected as a result of the adaptation triggers being generated in an event based middleware, thus bringing out the interplay between them. Table 1. Classification of Event Based Middleware Middleware

Event Model

Overlay Topology

Subscription Scheme

Elvin

Events represented as strings. No composition or hierarchy of events.

Underlay Unaware - Star Topology (Static)

Content Based

Jedi

Object Based (Active Objects and Event Dispatcher). No hierarchy or composition of events.

Underlay Unaware - Hierarchical Event Dispatcher (Static)

Content Based - Pattern matching of events

Siena

Pattern based model in the form of a triplet (name, type, value). No hierarchy or composition of events.

Underlay Unaware - Acyclic peer to peer, Hierarchical or Hybrid topology (Static)

Content Based

Gryphon

No hierarchy or composition of events.

Underlay Aware. Hierarchical Structure, with publisher hosting broker as root and subscriber hosting broker as leaf

Content Based

Hermes

Object Based. Supports event hierarchy and composition.

Underlay Aware - Hybrid (Static)

Hybrid - Type based and Type and Attribute Based

Rebeca

No hierarchy or composition of events.

Underlay Unaware - Hierarchical, symmetrical and acyclic tree like topology

Content Based with covering and merging of filters

Medym

No hierarchy or composition of events.

Underlay Aware (proximity) overlay

Content based

IndiQoS

Object Based with QoS Profiles. No hierarchy or composition of events.

Underlay Aware - Hybrid (Static)

Type Based

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

Elvin

Event Based Middleware Jedi Siena Gryphon Hermes

Rebeca

Medym

IndiQoS

Latency Bandwidth Reliability Delivery Semantics Message Ordering

N N N N N

QoS Supported Parameters N N N N N N N N N N N Y N N Y N Y N N N

N N N N N

N N Y N N

Y Y N N N

Event Model Overlay Topology Routing Scheme

N N N

Adaptation Applicable at Level N N N N N N N Y N N N Y

N N N

N Y Y

N N N

Client Movement Publishing Rate Variation Secure Event Notification Urgent Event Notification Link Failure Broker Failure Availability Variation

N Y N N N N N

Adaptation Triggers Y Y Y Y N N N N N Y N N N N

N Y N N N N N

N Y N N Y Y N

N N N N N N N

Y Y N N N N N

N Y N N N Y N

Table 3. Classification of QoS and Adaptation Triggers

Latency

QoS Parameters Bandwidth Reliability

Ordering

Del Semantics

Client Movement Publishing Rate Variation

Adaptation Trigger - Client Y Y Y Y Y Y

N N

N N

Secure Event Notification Urgent Event Notification

Adaptation Trigger - Event Model N N N Y N N

N Y

N N

Link Failure Broker Failure Availability Variation

Adaptation Trigger - Resource Y Y Y Y Y Y Y Y Y

N N N

N N N