Download presentation
Presentation is loading. Please wait.
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.