1. Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl 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

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

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

4. Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl Content-Based Routing n Cooperating brokers –Local clients –Notification forwarding –Filter-Based Routing Tables n Tradeoff: –Flooding vs. filtering at intermediate brokers –Network resource waste vs. filtering overhead (processing and delay) B1B1 Local Clients N B2B2 B3B3 B4B4 N N N N F G (F,B2)(G,B3)(F,B2)(G,B3) (G,B4)(G,B4) Routing Tables

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

6. Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl Covering n Filters can cover each other –F covers G  N(F)  N(G) n Covering can decrease –size of routing tables –filter forwarding overhead F G B4B4 B1B1 B2B2 B3B3 (F,B3)(F,B3) (F,B1)(G,B2)(F,B1)(G,B2) F G

7. Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl Merging n Filters can be merged –perfectN(F)  N(G)  N(H) –imperfectN(F)  N(G)  N(H) n Merging generates new covers n Similar benefits as covering F G B1B1 B2B2 B3B3 (G,B1)(H,B2)(G,B1)(H,B2) H G H F G H B4B4 (F,B3)(F,B3)

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

9. Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl Generic Constraints n Our solution: a generic filter framework –Name/value pairs –Extensible set of constraints and (complex) data types –Facilitates optimizations (covering and merging) n 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

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

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

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

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

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

15. Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl Questions?