Design and Evaluation of a WideArea Event Notification Service

1
Design and Evaluation of a Wide-Area Event
Notification Service

• Antonio Carzaniga
• David S. Rosenblum
• Alexander L. Wolf

2
Overview

• Introduction
• Critical design issues
• Topologies
• Routing Strategies
• Evaluation
• Simulation studies
• Future Challenges

3
Introduction (1)

• Distributed event notification service

4
Introduction (2)

• Key activities of an event notification service
• Notification selection
• Notification delivery
• Challenges in a wide-area setting
• Maximize expressiveness in the selection
  mechanism
• Maintain scalability in the delivery mechanism

5
Critical Design Issues

• Interconnection topology
• Hierarchy, adopted by JEDI
• General graph, adopted by SIENA
• Routing algorithm
• Broadcast notifications
• Broadcast subscriptions
• Broadcast advertisements
• Processing strategy
• Pruning A server propagates a subscription only
  if it defines new notifications that are not
  covered by previously propagated subscriptions.

6
API and Semantics (1)

• Interfaces of SIENA
• publish (notification n)
• subscribe (string identity, pattern expression)
• unsubscribe (string identity, pattern expression)
• advertise (string identity, filter expression)
• unadvertise (string identity, filter expression)
• Notification a set of typed attributes
• Each attribute has a type, a name, and a value.

7
API and Semantics (2)

• Filters -- specify a set of attributes and
  constraints on the values of those attributes
• Patterns a sequence of filters matched by a
  temporally ordered sequence of notifications,
  each one matching the corresponding filter

8
API and Semantics (3)

• Two variants of the semantics of SIENA
• Subscription-based semantics
• A notification n is delivered to an interested
  party X ? X submitted at least one subscription
  s such that n matches s.
• Advertisement-based semantics
• A notification n published by object Y is
  delivered to interested party X ? Y advertised a
  filter a that covers n and X registered a
  subscription s that covers n.

9
Architectures (1)

• Hierarchical client/server architecture
• Acyclic peer-to-peer architecture

10
Architectures (2)

• General peer-to-peer architecture
• Hybrid architectures

11
Routing Strategies used in SIENA

• To ensure delivery of notifications to
  interested parties that subscribe for them.
• Employs principles found in multicast routing
  protocols.
• Main Idea Send Notification only towards event
  servers that have interested clients , possibly
  using shortest path.

12
Routing Strategies Generic principles

• Downstream Replication

13
Routing Strategies Generic Principles (2)

• 2. Upstream Evaluation

14
Two Classes of Routing Algorithms

• Subscription forwarding
• Subscriptions set the path for notifications
• Subscriptions are broadcast throughout the
  network
• Forms a spanning tree that connects subscribers
  to all servers in the network
• No advertisements used

15
Two classes of Routing Algorithms (2)

• Advertisement forwarding
• Advertisements set the path for Subscriptions
• And Subscriptions set the path for Notifications
• Advertisements are broadcast throughout the
  network thereby forming tree
• Subscriptions are sent only to advertisers that
  submitted relevant advertisements

16
Optimizations in SIENA

• Exploit commonalities among subscriptions and
  advertisements
• Prune propagation trees by propagating only along
  paths not covered by previous requests
• Unsubscriptions and unadvertisements are handled
  similarly

17
The Filters Poset

• This data structure represents a partially
  ordered set of filters.
• Partial order is defined by covering relations
  for subscription filters advertisement filters.
• Event server maintains this data structure that
  keeps track of
• previous requests
• their relationships
• their source
• where they are forwarded

18
The Filters Poset (2)

• Poset extends vertically -gt subscriptions very
  much inter-dependent -gt few subscriptions
  summarize all others.
• Poset extends horizontally -gt few similarities
  among subscriptions -gt few opportunities to
  reduce traffic

19
Algorithms for Hierarchical Architecture

• Hierarchical server maintains
• Subscriptions in a poset s.
• Subscribers(s) set contains identities of
  subscribers of subscription.
• Variable master contains identity of master
  server.

20
Algorithms for Hierarchical Architecture (2)
Subscriptions

• Upon receiving subscribe (X,f),
• if server E finds subscription f in poset Ps
  such that f covers f and contains X in its
  subscribers set , no action taken.
• If f already exists in Ps, insert X in its
  subscribers set.
• Otherwise, if f or f not found, f is inserted
  with empty immediate successor and predecessor.
• ONLY if f is inserted as root subscription, does
  the server forward subscribe (E,f) to master.
• If immediate predecessor is NOT null, server
  removes X from subscribers set of all
  subscriptions covered by f.

21
(No Transcript)
22
Algorithms for Hierarchical Architecture (3)
Notifications

• Upon receiving a Notification n
• The server determines all the subscriptions that
  cover n.
• The server sends a copy of n to all the
  subscribers of the subscriptions.
• The server sends copy of n to master server, if
  master was not sender of n.

23
Algorithms for Hierarchical Architecture (4)
Unsubscriptions

• Single unsubscription might cancel one or more
  previous subscriptions
• If root subscription is canceled , the server
  must forward unsubscription to master AND must
  forward new root subscriptions.

24
Algorithms for Hierarchical Architecture(5)
Advertisement forwarding

• Advertisement forwarding technique does not apply
  to hierarchical architecture. Why?
• Advertisements and Unadvertisements are silently
  dropped.

25
Algorithms for peer-to-peer Architecture

• In peer-to-peer architectures, a server
  maintains
• A set of neighbors
• Subscriptions in poset Ps
• Set of subscribers with each subscription
• Set of forwards with subset of neighbors to which
  s is forwarded.
• A subscription or notification is propagated from
  origin to its destination following a minimum
  spanning tree.

26
Algorithms in peer-to-peer Architecture(2)
Subscriptions

• Extension of algorithm of the hierarchical
  server
• Algorithms differ in how peer-to-peer server
  forwards subscriptions to its neighbors.
• f is forwarded to all neighbors except those
• Upstream from the server along spanning tree
  rooted at subscriber of f.
• To those to which f covering f has already been
  forwarded.

27
Algorithms in peer-to-peer Architecture(3)
Notifications

• Processed the same way as in hierarchical
  architectures.

28
Algorithms in peer-to-peer Architecture(4)
Advertisement Forwarding

• Main difference Two interacting computations
• Advertisement forwarding constraints subscription
  forwarding.

29
Evaluation

• How can we demonstrate ability to scale?
• Qualitative reasoning with regard to
  expressiveness of the notification selection
  mechanism
• Performing simulation studies
• Constructing a prototype implementation

30
Simulation Studies

• Reasoning for Level of Expressiveness
• Some scalability factors such as network latency
  cannot be controlled by the design
• Expressiveness level approximates SQL
• Conclusion covering relations have reasonable
  complexities for a scalable event notification
  system.

31
Simulation Studies

• Issues
• Scalability w.r.t. architectures/algorithms
• Architecture/algorithms vs increased application
  demands - how is communication cost affected?

32
Simulation Studies

• Network configuration
• Assumptions
• costs are linear functions of load
• latencies of links are constant
• sites and links have infinite capacity
  (congestion?)
• only homogenous architectures are chosen
• centralized architectures are considered as a
  basis for comparison (simplicity)

33
Simulation Studies

• Application Behavior
• involves collective behavior of an applications'
  objects of interest
• Done using scenario generation

34
Simulation Studies

• Total Cost
• as a basic metric for event notification services
  captures important aspects of scalability
• total cost remains almost constant when there are
  more than 100 interested parties (saturation)
• very high numbers of objects of interest results
  in client/server architecture performing worse
  than acyclic peer to peer with subscription
  architecture
• acyclic peer to peer with advertisement
  architecture shows unstable cost profile at low
  densities

35
Simulation Studies

• Cost per Service request
• total cost / number of client requests
• low value -gt low overheads
• it can be seen that centralized architectures are
  unreasonable
• Cost per Subscription
• total cost of all subscription messages/ number
  of subscriptions processed

36
Simulation Studies

• Conclusions
• Hierarchical client/server architecture has lower
  per-subscription costs than acyclic peer to peer
  therefore it is better suited for low densities
  of clients
• For both architectures high densities of
  interested parties results in higher subscription
  costs
• Cost of delivering a notification to interested
  parties is more or less the same for the 2
  architectures
• Peer to peer is better when total cost of
  communication is dominated by notifications

37
Future Challenges

• Enhancing the design of the interface and
  algorithms to support mobility of clients
• Extensions that support quality of service
  parameters suited for integration of software
  components
• Explore other important issues of WANs such as
  mechanisms for reliability and fault tolerance of
  event notification systems
• Realization of content based routing