Hermes: A Distributed Event-Based Middleware
Architecture
Peter Pietzuch and Jean Bacon{Peter.Pietzuch,Jean.Bacon}@cl.cam.ac.uk1st 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
• 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
Hermes – A Distributed Event-Based M/W
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
B
P S
B
B
B
B
B
B
B
P
P
P
P P
S
S
SS
S
P
S
7
• 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
Design II
PrinterEvent (printerID > 42)
class PrinterFinished extends PrinterEvent { attribute int jobID; attribute string userID;}
8
Architecture
Network Layer (IP Unicast/Multicast)
Peer-to-Peer Routing Network Layer
Type-Based Pub/Sub Layer
QoS
SecurityComposite
Events
Type- and Attribute-Based Pub/Sub Layer
TransactionsDiscovery
...Event-Based Middleware Layer
Reliability
9
• 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
Algorithms I - Peer to Peer Routing
10
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
B4
B2
B5
B1
B3
P1
P2
S1
S2
RR
11
• Filtering State• Notifications follow reverse paths of subscriptions• Covering and Merging supported
Algorithms III – Content-Based Pub/Sub
B4
B2
B5
B1
B3
P1
P2
S1
S2
RR
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
Fault-Tolerance II
• Event Broker Failure– resend Advertisements and Subscriptions– recreate Filtering State
B4
B2
B5
B1
B3
P1
S1
R
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
• 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
Future Work
16
• 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
Conclusions