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

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 Client subscribed “/weather/Munich” Notification “/weather/Munich” Client subscribed “/weather/Berlin” “/weather/*”

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

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

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

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

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)

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

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

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

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 *

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

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

Darmstadt University of Technology CoopIS 2001, TrentoGero Mühl Conclusion n Project R EBECA ( –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

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