SOA Patterns > Service Messaging Patterns > Event-Driven Messaging
Event-Driven Messaging (Little, Rischbeck, Simon)
How can service consumers be automatically notified of runtime service events?
Problem
Events that occur within the functional boundary encapsulated by a service may be of relevance to service consumers, but without resorting to inefficient polling-based interaction, the consumer has no way of learning about these events.
Solution
The consumer establishes itself as a subscriber of the service. The service, in turn, automatically issues notifications of relevant events to this and any of its subscribers.
Application
A messaging framework is implemented capable of supporting the publish-and-subscribe MEP and associated complex event processing and tracking.
Impacts
Event-driven message exchanges cannot easily be incorporated as part of Atomic Service Transaction, and publisher/ subscriber availability issues can arise.
Architecture
Inventory, Composition
Service A requests that it be set up as a subscriber to the event it is interested in by interacting with an event manager. Once the event occurs, Service B forwards the details to the event manager which, in turn, notifies Service A (and all other subscribers) via a one-way, asynchronous data transfer. Note that in this case, Service A also receives the event information earlier because the event details can be transmitted as soon as they’re available.
Related Patterns in This Catalog
Asynchronous Queuing, Atomic Service Transaction, File Gateway, Intermediate Routing, Reliable Messaging, Service Agent, Service Callback, Service Instance Routing
Related Patterns in Other Catalogs
Event Message, Publish-Subscribe Channel
Related Service-Oriented Computing Goals