Generic Constraints for Content-Based Publish/Subscribe Gero Mühl

1. Generic Constraints for Content-Based Publish/Subscribe Gero Mühl PhD Program “Enabling Technologies for Electronic Commerce” Darmstadt University of Technology g_muehl@acm.org Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <1>

2. N N N Publish/Subscribe Systems • Set of Clients: • Producers publish notifications • Consumers • subscribe to interesting notifications • are asynchronously notified • “Notification Service” responsible for delivery • Characteristics • Loose coupling of clients • High Flexibility Notification “/weather/Munich” Producer 1. P/S Client subscribed “/weather/Berlin” 2. 2. Client subscribed “/weather/Munich” “/weather/*” Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <2>

3. Content-Based Filtering • Content-based Filters • whole content of notifications evaluated • more flexible/complex than subjects • set of matching notifications N(F){n | F(n)true} • Centralized implementations not scalable to wide-area scenarios • Requires powerful distributed infrastructure Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <3>

4. N N N N N B1 B2 B3 B4 Content-Based Routing G • Cooperating brokers • Local clients • Notification forwarding • Filter-BasedRouting Tables • Tradeoff: • Flooding vs. filtering at intermediate brokers • Network resource waste vs. filtering overhead(processing and delay) F (G,B4) Routing Tables (F,B2) (G,B3) Local Clients Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <4>

5. Content-Based Routing II • Size of routing tables crucial global knowledge about all active subscriptions not feasible • Solutions • exploit similarities/overlapping of subscriptions to minimize the knowledge needed • identity • covering • merging • trading accuracy vs. efficiency Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <5>

6. B4 B1 B2 B3 Covering • Filters can cover each other • FcoversGN(F)N(G) • Covering can decrease • size of routing tables • filter forwarding overhead F G (F,B1) (G,B2) F G (F,B3) Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <6>

7. B1 B2 B3 B4 Merging • Filters can be merged • perfectN(F)N(G)N(H) • imperfectN(F)N(G)N(H) • Merging generates new covers • Similar benefits as covering F H G F (F,B3) G H G (G,B1) (H,B2) H Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <7>

8. Existing Data/Filter Models • Existing Data/Filter modelseither too restricted (e.g. Tuples/String Matching) • only primitive data types • fixed set of constraints • limited support for covering and merging • or too general (e.g. XML/XPath) • local matching may be efficient • prohibiting routing optimizationse.g. covering of relational expressions is NP-complete Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <8>

9. Generic Constraints • Our solution: a generic filter framework • Name/value pairs • Extensible set of constraints and (complex) data types • Facilitates optimizations (covering and merging) • Constraints • independent of the actual data types (generic)e.g comparisons can be applied to all ordered values • data types just implement correspondent operations (e.g. comparisons) • test for matching, covering and generate merges Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <9>

10. Framework for Name/Value Pairs I • Notification: • Set of attributes (name/value pairs ) • Example: {(Type, Quote), (Name, “Infineon”), (Price, 23.24)} Name Value • Filters: • Conjunction of attribute filters: F  f1  fn • Attribute filter applies a constraint to a named value • At most one attribute filter per attribute • Example: {(TypeQuote)(Name“Infineon”)} Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <10>

11. Framework for Name/Value Pairs II Notification Filter * * 1 1 Attribute AttributeName AttributeFilter 1 1 n Value Constraint Exists Distinguishable Equality Inequality Comparison Ordered Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <11>

12. Example: GIS Frankfurt • F  {(TypeTrafficInformation) (Location around(Frankfurt,50km))} • G  {(TypeTrafficJam)(Length5km)  (Locationaround(Darmstadt,20km))} • FcoversG • H  {(TypeTrafficJam)(Location around(Frankfurt,40km))} • I  {(TypeTrafficJam)(Location around(Wiesbaden,40km))} • H and I can be merged imperfectly Darmstadt X X Frankfurt X X X Wiesbaden Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <12>

13. Algorithms • Use the implementations provided by the constraints • Matching (outputs all filters matching a notification) • counting the number of satisfied attribute filters • Covering (outputs all filters F that cover G) • N(F)N(G) (figj.n(fi)  n(gj)) • counting of covering attribute filters • Merging (outputs merging candidates) • necessary condition for perfect merging: F differs from G in exactly one attribute filter • counting of identical attribute filters Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <13>

14. Conclusion • Project REBECA (http://www.gkec.informatik.tu-darmstadt.de/rebeca) • Prototype of notification infrastructure • Content-Based Notification Mechanisms (G. Mühl) • Scopes in Event-Based Systems (L. Fiege) • Example Applications • Stock trading platform • Self-actualizing web-pages • Future Work • Measurements and simulations • Fault tolerance Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <14>

15. Questions? Darmstadt University of Technology CoopIS 2001, Trento Gero Mühl <15>