Event-Driven Messaging

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 messaging exchanges cannot easily be incorporated as part of cross-service transactions and publisher/subscriber availability issues can arise.
Principles Standardized Service Contract, Service Loose Coupling, Service Autonomy	Architecture Inventory, Service

Table 5.10 – Profile summary for the Event-Driven Messaging pattern.

Problem

Service consumers are typically required to initiate contact with service providers via the runtime invocation of the service program. In typical messaging environments, consumers can choose between one-way and request-response message exchange patterns (MEPs) but both need to originate from the consumer.

Events may occur within the service providerÕs functional boundary that are of interest to the service consumer. Following traditional MEPs, the consumer would need to continually poll the service provider in order to find out whether such an event had occurred (and to then retrieve the corresponding event details).

This model is inefficient because it leads to numerous unnecessary service invocations and data exchanges (Figure 6.x). It further introduces delays as to when the consumer receives the event information as it can only check at predetermined polling intervals.

Figure 6.47 – Service A (acting as a service consumer) polls Service B on an hourly basis for information about an event that Service A is interested in. Each polling cycle involves a synchronous, request-response message exchange. After the fourth hour, Service A learns that the event has occurred and receives the event information.

Solution

An event management program is introduced, allowing the service consumer to set itself up as a subscriber to events associated with a service (which assumes the role of publisher).There may be different types of events that the service provider makes available and consumers can choose which they would like to be subscribed to.

When such an event occurs, the service provider automatically sends the event details to the event management program, which then broadcasts the notification to all of the consumers registered as subscribers of the event.

Figure 6.48 – 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.

Application

An event-driven messaging framework is implemented as an extension to the service inventory. Runtime platforms, messaging middleware, and enterprise service bus products commonly provide the necessary infrastructure for message processing and tracing capabilities, along with system agents that provide complex event processing, filtering, and correlation.

Impacts

Event-Driven Messaging is based on asynchronous message exchanges that can occur sporadically, depending on whenever the service provider events actually occur. It therefore may not be possible to wrap these exchanges within runtime, cross-service transactions.

Furthermore, because notification broadcasts cannot be predicted, the consumer must always be available to receive the notification message transmissions. Also, messages are typically issued via the one-way MEP, which does not require an acknowledgement response from the consumer.

Both of the above listed drawbacks can raise serious reliability issues that can be addressed through the application of the Asynchronous Queuing and Reliable Messaging design patterns.

A common related impact is the difference in solution design. Developers need to become accustomed to designing service consumers and service providers to use an asynchronous messaging model that may seem ÒreversedÓ from traditional MEPs.

Relationships

The unique messaging model established by Event-Driven Messaging extends the base model provided by Service Messaging and is itself often extended via other specialized messaging patterns, such as Asynchronous Queuing and Reliable Messaging.

Figure 6.49 – The Event-Driven Messaging pattern provides distinct functionality that relies upon a combination of other messaging and agent-related patterns.

The publish-and-subscribe model that underlies the Event-Driven Messaging pattern provides advanced, asynchronous messaging functionality that can build upon the routing and messaging logic provided natively by ESB platforms (Figure 6.x).

Figure 6.50 – The Event-Driven Messaging pattern is considered an optional extension to the base Enterprise Service Bus compound pattern described in Chapter 9.

Case Study Example

Case study content is not available on this Web site.