Design and Evaluation of a Wide-Area 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 -> 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.

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 -> 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