Chapter 12. Event-Driven Interaction Patterns
In the previous chapters we examined four different ways in which two parties might interact, but without asking why they were interacting. For the In-Out and Out-In patterns, the reason is obvious (Figure 12-1a): One party is sending a request to the other and expecting a response. For the In-Only and Out-Only interactions, however, there are two possibilities. The first is that one party is sending a request to the other (Figure 12-1b). The second is that one party is simply sending a notification of some kind to the other (Figure 12-1c).
Figure 12-1. Message Semantics in Interactions
This seemingly innocuous difference between a request and a notification is, in fact, quite important: It reflects an entirely different style of interaction. Requests are always directed to an identified party and direct that party to take some specific action. Notifications, on the other hand, are simply announcements—and are not necessarily directed at any particular party. In fact, the notification may go to multiple parties (Figure 12-2). It is up to the party receiving the announcement to decide what, if anything, needs to be done.
Figure 12-2. Notifications Delivered to Multiple Parties
The Pub-Sub Architecture Pattern
The idea that a communication—a message—might not be directed to any party gives rise to the notion of an event-driven interaction. The publication of the message constitutes the announcement of an event, and parties wishing to receive the event obtain a subscription for that type of message. The result is the publication-subscription paradigm, often abbreviated as pub-sub.
The pub-sub paradigm requires an intermediate communications channel as shown in Figure 12-3. This channel serves several purposes:
• It provides facilities for parties to publish messages.
• It provides facilities for parties to subscribe to messages.
• It directs individual messages to the parties that have subscribed to those messages.
• It acts as a buffer between the publishers and subscribers.
Figure 12-3. Pub-Sub Architecture Pattern
Although file systems and databases can be used as pub-sub communications channels, the most common type of channel is a messaging system. The TIBCO Enterprise Message Service (EMS) is an example of a messaging system designed expressly for this purpose. At its core, it provides the standardized facilities of a Java Messaging Service (JMS).
In JMS, individual channels are referred to as destinations. Publishers send messages to destinations, and a message sent to a destination constitutes an event. Subscribers connect to the EMS server and indicate the destinations to which they would like to subscribe. When a message is published, it is delivered to the appropriate subscriber(s).
Queue Semantics
JMS offers two types of destinations, each with a distinctly different message delivery paradigm: queues and topics. A message sent to a queue is delivered to a single subscriber, regardless of how many subscribers there are for the queue (Figure 12-4).
Figure 12-4. Queue Delivery Semantics
A queue is generally used to deliver requests as opposed to announcements. In this case, the publisher is the service consumer and the subscriber is the service provider. A channel used in this manner is an example of an In-Only interaction.
The reason for having more than one subscriber would be to distribute the load for handling the messages. This means that each of the subscribers does exactly the same thing with the messages. The semantics governing which of the subscribers receives each message depends upon the implementation of the queue. The default EMS semantics is that messages are distributed in a round-robin manner among active subscribers.
Note that distributing load in this manner does not guarantee that messages will be processed in the order in which they were published and delivered. One subscriber may receive a message but not finish processing it before another subscriber finishes processing a subsequent message. There are a number of design patterns that can be used to handle such situations, but a discussion of these patterns is beyond the scope of this book and is addressed in Architecting Composite Applications and Services with TIBCO1.
When a queue is used to deliver requests, replies may be required. To facilitate this, EMS provides several options for returning reply messages to the publisher. These configuration options are described in the product manual. A channel used in this manner is an example of an In-Out interaction.
Queues generally retain messages until they have been delivered. EMS provides several options for persisting messages so that they are not lost in the event of a server restart. Again, these are described in the product manual.
Topic Semantics
When a message is published to a topic, in contrast to a queue, it is delivered to all subscribers (Figure 12-5). Topics are typically used to deliver notifications (announcements) rather than requests. A channel used in this manner is an example of the Out-Only pattern.
Figure 12-5. Topic Delivery Semantics
Sometimes notifications require responses, as in the previous chapter’s example of a newspaper extending an offer to a subscriber that requires a response. To support this, EMS provides facilities to route replies back to the publisher if required. A channel used in this manner is an example of the Out-In pattern in which a single output message constitutes a blanket request to all subscribers.
By default, messages are delivered only to those subscribers that happen to be connected at the time the message is published and then the message is discarded. By exception, subscribers can declare their subscriptions to be durable. When there are durable subscribers, EMS will retain messages until those subscribers come back online and have received their messages.
Bridge Semantics
If you examine the design intent of individual messages, some messages are explicit announcements of business events, while others serve as requests or replies. However, broadly speaking, the sending of any message is, in itself, an event. For example, sending a request from one system to another and sending the reply by the second system are two events that occur in the interaction between those two systems.
When you are monitoring a system to see whether it is behaving properly (or for other purposes), these events are the pieces of raw data that serve as the basis for the monitoring. Since individual raw events observed at this level may or may not have business significance, they are often referred to as technical events. Understanding the business meaning of such events is the world of complex event processing.
Complex event processing begins with the capture of technical events. Some of these technical events are the sending of messages, while others may be changes to database records or changes to files. Recognizing and capturing these events is an essential element of complex event processing. Mechanisms for recognizing changes in files and databases are discussed in Chapter 15. For now we will focus our attention on recognizing and capturing messages.
If a message is being published to a topic, capturing the message is as simple as adding a subscriber to the topic. However, if the message is being published to a queue, you can’t just add another subscriber because you will disrupt the normal delivery of the message.
EMS provides a facility that can be used to capture copies of messages being published to queues (and topics, for that matter): the bridge (Figure 12-6). EMS allows you to create a one-way bridge between any pair of topics and queues. When a message is published to the source destination of the bridge (the queue in the figure), EMS makes a copy of the message and places it in the target destination of the bridge (the topic in the figure).
Figure 12-6. Bridge Message Delivery Semantics
Other Sources of Events
Most of the discussion in this chapter has focused on messages, since they are the most common mechanism for distributing information about events. However, in many cases the actual event you are looking for may not be a message at all. In these cases, you will most likely need to select a mechanism for recognizing the event and generating a message that can be used to communicate information about the event. Two of the most common examples are database and file changes, both of which are discussed in Chapter 15.
Summary
When two components interact, each interaction represents one of three things: a request for something to be done, a reply to such a request, or an announcement that some business event has occurred.
In contrast to requests and replies, announcements are not necessarily being delivered to a single recipient: It is reasonable to want an announcement to be sent to multiple parties. This sending of a single message to multiple parties gives rise to the pub-sub architecture pattern.
The pub-sub pattern involves a third party providing a communications channel between the publishers and subscribers. The TIBCO Enterprise Message Service (EMS) provides JMS communications capabilities that are well-suited to this channel role.
Messages in JMS are published to destinations, and subscribers receive messages from those destinations. JMS provides two different types of destinations, queues and topics, each with different message delivery semantics. A queue will deliver a message to exactly one subscriber and will retain the message until it has been delivered. Queues are well-suited to request and request-reply interactions. A topic will deliver a message to all subscribers who are connected at the time the message is published. Topics are well-suited to pub-sub (broadcast) interactions.
There are times when it is desirable to treat a queue-based request (or reply) as an event (announcement) in its own right. The EMS bridge provides the means for automatically making a copy of a message when it is delivered and placing the copy in a target topic or queue. This lets you make a copy of the request (or reply) and deliver it to another destination without disrupting the original interaction.