This chapter is from the book
This chapter is from the book
This chapter is from the book
Event Message
Several applications would like to use event notification to coordinate their actions and would like to use Messaging (53) to communicate those events.
How can messaging be used to transmit events from one application to another?
Sometimes, an event occurs in one object that another object needs to know about. The classic example is a Model-View-Controller architecture [POSA], where the model changes its state and must notify its views so that they can redraw themselves. Such change notification can also be useful in distributed systems. For example, in a B2B system, one business may need to notify others of price changes or a whole new product catalog.
A process can use Remote Procedure Invocation (50) to notify other applications of change events, but that requires that the receiver accept the event immediately, even if it doesn’t want events right now. RPC also requires that the announcing process know every listener process and invoke an RPC on each listener.
The Observer pattern [GoF] describes how to design a subject that announces events and observers that consume events. A subject notifies an observer of an event by calling the observer’s Update() method. Update() can be implemented as an RPC, but it would have all of RPC’s shortcomings.
It would be better to send the event notification asynchronously, as a Message (66). This way, the subject can send the notification when it’s ready, and each observer can receive the notification if and when it’s ready.
)
Figure 5.3 Use an Event Message for reliable, asynchronous event notification between applications.
When a subject has an event to announce, it creates an event object, wraps it in a message, and sends it on a channel as an Event Message. The observer receives the Event Message, gets the event, and processes it. Messaging does not change the event that’s being announced, but just makes sure that the notification gets to the observer.
An Event Message can be any kind of message in the messaging system. In Java, an event can be an object or data, such as an XML document. Thus, it can be transmitted through JMS as an ObjectMessage, TextMessage, and so on. In .NET, an event message is a Message with the event stored in it.
The difference between an Event Message and a Document Message (147) is a matter of timing and content. An event’s contents are typically less important. Many events even have an empty message body; their mere occurrence tells the observer to react. An event’s timing is very important; the subject should issue an event as soon as a change occurs, and the observer should process it quickly while it’s still relevant. Guaranteed Delivery (122) is usually not very helpful with events, because they’re frequent and need to be delivered quickly. Message Expiration (176) can be very helpful to make sure that an event is processed quickly or not at all.
The B2B system that must notify other businesses of price or product changes, for example, could use Event Messages, Document Messages (147), or a combination of the two. If a message says that the price for computer disk drives has changed, that’s an event. If the message provides information about the disk drive, including its new price, that’s a document being sent as an event. Another message that announces the new catalog and its URL is an event, whereas a similar message that actually contains the new catalog is an event that contains a document.
Which is better? The Observer pattern describes this as a trade-off between a push model and a pull model. The push model sends information about the change as part of the update, whereas the pull model sends minimal information, and observers that want more information request it by sending GetState() to the subject. The two models relate to messaging like this.
- Push model—The message is a combined document/event message; the message’s delivery announces that the state has occurred and the message’s contents are the new state. This is more efficient if all observers want these details, but otherwise it can be the worst of both worlds: a large message that is sent frequently and often ignored by many observers.
- Pull model—There are three messages:
- Update is an Event Message that notifies the observer of the event.
- State Request is a Command Message (145) an interested observer uses to request details from the subject.
- State Reply is a Document Message (147) the subject uses to send the details to the observer.
The advantages of the pull model are that the update messages are small, only interested observers request details, and potentially each interested observer can request the details it specifically is interested in. The disadvantage is the additional number of channels needed and the resulting traffic caused by more than one message.
For more details on how to implement Observer using messaging, see the section “JMS Publish/Subscribe Example” in Chapter 6, “Interlude: Simple Messaging.”
There is usually no reason to limit an event message to a single receiver via a Point-to-Point Channel (103); the message is usually broadcast via a Publish-Subscribe Channel (106) so that all interested processes receive notification. Whereas a Document Message (147) needs to be consumed so that the document is not lost, a receiver of Event Messages can often ignore the messages when it’s too busy to process them, so the subscribers can often be nondurable (not Durable Subscribers [522]). Event Message is a key part of implementing the Observer pattern using messaging.