Enterprise Integration Patterns: Message Construction
This chapter is from the book
This chapter is from the book
This chapter is from the book
Introduction
In Chapter 3, “Messaging Systems,” we discussed Message (66). When two applications want to exchange a piece of data, they do so by wrapping it in a message. Whereas a Message Channel (60) cannot transmit raw data per se, it can transmit the data wrapped in a message. Creating and sending a Message (66) raises several other issues.
- Message intent—Messages are ultimately just bundles of data, but the sender can have different intentions for what it expects the receiver to do with the message. It can send a Command Message (145), specifying a function or method on the receiver that the sender wishes to invoke. The sender is telling the receiver what code to run. It can send a Document Message (147), enabling the sender to transmit one of its data structures to the receiver. The sender is passing the data to the receiver but not specifying what the receiver should necessarily do with it. Or it can send an Event Message (151), notifying the receiver of a change in the sender. The sender is not telling the receiver how to react, just providing notification.
- Returning a response—When an application sends a message, it often expects a response confirming that the message has been processed and providing the result. This is a Request-Reply (154) scenario. The request is usually a Command Message (145), and the reply is a Document Message (147) containing a result value or an exception. The requestor should specify a Return Address (159) in the request to tell the replier what channel to use to transmit the reply. The requestor may have multiple requests in process, so the reply should contain a Correlation Identifier (163) that specifies which request this reply corresponds to.
- Huge amounts of data—Sometimes applications want to transfer a really large data structure, one that may not fit comfortably in a single message. In this case, break the data into more manageable chunks and send them as a Message Sequence (170). The chunks must be sent as a sequence, not just a bunch of messages, so the receiver can reconstruct the original data structure.
- Slow messages—A concern with messaging is that the sender often does not know how long it will take for the receiver to receive the message. Yet, the message contents may be time-sensitive, so if the message isn’t received by a certain deadline, it should be ignored and discarded. In this situation, the sender can use Message Expiration (176) to specify an expiration date. If the messaging system cannot deliver a message by its expiration, it should discard the message or move it to a Dead Letter Channel (119). Likewise, if a receiver gets a message after its expiration, it should discard the message.
There are two common Request-Reply (154) scenarios worth noting; both involve a Command Message (145) request and a corresponding Document Message (147) reply. In the first scenario, Messaging RPC, the requestor not only wants to invoke a function on the replier, but also wants the return value from the function. This is how applications perform an RPC (Remote Procedure Call) using Messaging (53). In the other scenario, Messaging Query, the requestor performs a query; the replier executes the query and returns the results in the reply. This is how applications use messaging to perform a query remotely.
In summary, simply choosing to use a Message (66) is insufficient. When data must be transferred, it must be done through a Message (66). This chapter explains other decisions that are part of making messages work.
Command Message
An application needs to invoke functionality provided by other applications. It would typically use Remote Procedure Invocation (50), but it would like to take advantage of the benefits of using Messaging (53).
How can messaging be used to invoke a procedure in another application?
The advantage of Remote Procedure Invocation (50) is that it’s synchronous, so the call is performed immediately while the caller’s thread blocks. But that’s also a disadvantage. If the call cannot be executed immediately—either because the network is down or because the remote process isn’t running and listening—then the call doesn’t work. If the call were asynchronous, it could keep trying until the procedure in the remote application is successfully invoked.
A local invocation is more reliable than a remote invocation. If the caller could transmit the procedure’s invocation to the receiver as a Message (66), then the receiver could execute the invocation locally. So, the question is how to make a procedure’s invocation into a message.
There’s a well-established pattern for encapsulating a request as an object. The Command pattern [GoF] shows how to turn a request into an object that can be stored and passed around. If this object were a message, then it could be stored in and passed around through a Message Channel (60). Likewise, the command’s state (such as method parameters) can be stored in the message’s state.
){kind=small}
Figure 5.1 Use a Command Message to reliably invoke a procedure in another application.
There is no specific message type for commands; a Command Message is simply a regular message that happens to contain a command. In JMS, the command message could be any type of message; examples include an ObjectMessage containing a Serializable command object, a TextMessage containing the command in XML form, and so on. In .NET, a command message is a Message (66) with a command stored in it. A Simple Object Access Protocol (SOAP) request is a command message.
Command Messages are usually sent over a Point-to-Point Channel (103) so that each command will be consumed and invoked only once.
Example: SOAP and WSDL
With the SOAP protocol [SOAP 1.1] and WSDL service description [WSDL 1.1], when using RPC-style SOAP messages, the request message is an example of this Command Message pattern. With this usage, the SOAP message body (an XML document) contains the name of the method to invoke in the receiver and the parameter values to pass into the method. This method name must be the same as one of the message names defined in the receiver’s WSDL.
This example from the SOAP specification invokes the receiver’s GetLastTradePrice method with a single parameter called symbol.
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
In a SOAP command, one might expect the method name to be the value of some standard