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 1. Downstream Replication

13. Routing Strategies: Generic Principles (2) 2. Upstream Evaluation

14. Two Classes of Routing Algorithms  Subscription forwarding : Subscriptions set the path for notificationsSubscriptions set the path for notifications Subscriptions are broadcast throughout the networkSubscriptions are broadcast throughout the network Forms a spanning tree that connects subscribers to all servers in the networkForms a spanning tree that connects subscribers to all servers in the network No advertisements usedNo advertisements used

15. Two classes of Routing Algorithms (2)  Advertisement forwarding : Advertisements set the path for Subscriptions Advertisements set the path for Subscriptions And Subscriptions set the path for NotificationsAnd Subscriptions set the path for Notifications Advertisements are broadcast throughout the network thereby forming treeAdvertisements are broadcast throughout the network thereby forming tree Subscriptions are sent only to advertisers that submitted relevant advertisementsSubscriptions 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 -> subscriptions very much inter- dependent -> few subscriptions summarize all others.  Poset extends horizontally -> few similarities among subscriptions -> 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 it’s subscriber’s set, no action taken. –If f already exists in Ps, insert X in it’s subscriber’s 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 subscriber’s set of all subscriptions covered by f.

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 it’s destination following a minimum spanning tree.A subscription or notification is propagated from origin to it’s 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 Issues  Scalability w.r.t. architectures/algorithms  Architecture/algorithms vs increased application demands - how is communication cost affected?

32. Simulation Studies Network configuration: Network configuration: Assumptions 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 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 -> 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