1 / 16

Hermes: A Distributed Event-Based Middleware Architecture

Hermes: A Distributed Event-Based Middleware Architecture. Peter Pietzuch and Jean Bacon {Peter.Pietzuch,Jean.Bacon}@cl.cam.ac.uk 1st DEBS Workshop, Vienna, Austria, July 2002. Motivation. How do we build Event-Based Distributed Applications ? Software Engineering Issues

ziarre
Download Presentation

Hermes: A Distributed Event-Based Middleware Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hermes: A Distributed Event-Based Middleware Architecture Peter Pietzuch and Jean Bacon {Peter.Pietzuch,Jean.Bacon}@cl.cam.ac.uk 1st DEBS Workshop, Vienna, Austria, July 2002

  2. Motivation • How do we build Event-Based Distributed Applications? • Software Engineering Issues • Middleware Abstraction • Event-Based Middleware vs. Simple Event System • Language Integration • Complete Environment for Application Programmer • Additional Middleware Services • Scalability for Large-Scale, Internet-Wide Systems • Keep Little State • No Global Broadcasts • Fault-Tolerance

  3. Overview • Motivation • Event-Based Middleware • Hermes • Design • Architecture • Event Routing Algorithms • Fault-Tolerance • Implementation • Future Work • Conclusions

  4. Event-Based Middleware • M/W following Pub/Sub Communication Paradigm • loose coupling, asynchronous messaging, many-to-many communication, source/sink anonymity • Additional Middleware Services • Programming Model, Programming Language Integration • Reliability, Fault-tolerance, QoS • Security • Transactions • Support for Mobile Event Clients • Additional Pub/Sub Services • Reflection (Meta Events) • Composite Event Patterns • Event Persistence

  5. Hermes – A Distributed Event-Based M/W • Logical Network of Self-organising Event Brokers (P2P) • Scalable Design and Routing Algorithms • Expressive Content-Based Filtering • Clean Layered Design • Traditional M/W functionality • strong typing, fault-tolerance, reliability… • Extensible to provide additional M/W services

  6. Design I • Event Brokers • provide middleware functionality • logical overlay network with content-based routing and filtering • easily extensible • Event Clients (Event Publishers Event Subscribers ) • connect to Event Broker • light-weight • language independence • mobility

  7. Design II • Event Model • Typed Events with Attributes • Inheritance • Subscription Model • Type- and Attribute-Based Pub/Sub • Super-Type Subscriptions • Routing Model • Peer to Peer Overlay Routing • Application-Level Routing more flexible • Several Layers class PrinterFinished extends PrinterEvent { attribute int jobID; attribute string userID; } PrinterEvent (printerID > 42)

  8. Architecture

  9. Algorithms I - Peer to Peer Routing • Routing Overlay Network (Pastry, Tapestry, CAN, …) • Event Brokers get unique Node IDs • route (message, nodeID) • Properties • always routes to numerically closest existing Node ID • log N hops • logical topology reflects physical topology • adapts to node and link failure • Event Brokers become Rendezvous Nodes • make sure that subscriptions find advertisements • created on a per-type basis • hash function of event type name • scalable event dissemination algorithm

  10. P B 1 B P 1 2 2 B 3 S 2 R R B S B 1 5 4 Algorithms II – Topic-Based Pub/Sub • Type Msg, Advertisements, Subscriptions, Notifications • Rendezvous Nodes • Reverse Path Forwarding • Notifications follow Advs and then the reverse path of Subs

  11. P B 1 B P 1 2 2 B 3 S 2 R B S B 1 5 4 Algorithms III – Content-Based Pub/Sub • Filtering State • Notifications follow reverse paths of subscriptions • Covering and Merging supported R

  12. Fault-Tolerance I • Heartbeat Messages + Soft State (Leases) • Link Failure • adapt at P2P routing layer • Event Broker Failure • recreate filtering state by resending subscriptions and advertisements • Event Client Failure • Soft State in Brokers will expire • Rendezvous Node Failure • replicate Rendezvous Nodes (weak consistency)

  13. B B P 1 1 2 B 3 R B S B 1 5 4 Fault-Tolerance II • Event Broker Failure • resend Advertisements and Subscriptions • recreate Filtering State

  14. Implementation • Actual Implementation • Java Implementation of Event Broker and Event Clients • Event Types defined in XML Schema • Java Language Binding for Events using Reflection • Implementation within a Simulator • Large-Scale, Internet-Like Topologies • up to 104 Nodes so far

  15. Future Work • Experiments within the Simulator • Verify Scalability Claims • Test Fault-Tolerance Scenarios • Other Pub/Sub Middleware Services • Distributed Composite Event Detection • Changes to the P2P Routing Layer • Taking Advantage of an Existing Multicast Service • Structuring into Domains

  16. Conclusions • Future Internet-Wide Applications require new M/W Paradigms Event-Based Middleware • Traditional Middleware functionality • Scalable Event Dissemination Algorithms • Application-Level P2P Routing gives a useful abstraction • Type- and Attribute-Based Pub/Sub results in good language integration • Fault-Tolerance is essential for wide-area networks

More Related