Event-Driven Messaging (Little, Rischbeck, Simon)
How can service consumers be automatically notified of runtime service events?
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.
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.
A messaging framework is implemented capable of supporting the publish-and-subscribe MEP and associated complex event processing and tracking.
Event-driven message exchanges cannot easily be incorporated as part of Atomic Service Transaction, and publisher/ subscriber availability issues can arise.
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.