Home > Design Patterns > Event-Driven Messaging
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

Listen to the podcasts that accompany this site

Event-Driven Messaging: 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.

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.