This chapter is from the book
This chapter is from the book
This chapter is from the book
Document Message
An application would like to transfer data to another application. It could do so using File Transfer (43) or Shared Database (47), but those approaches have shortcomings. The transfer might work better using Messaging (53).
How can messaging be used to transfer data between applications?
This is a classic problem in distributed processing: One process has data that another one needs. File Transfer (43) is easy to use, but it doesn’t coordinate applications very well. A file written by one application may sit unused for quite a while before another application reads it. If several applications are supposed to read it, it’ll be unclear who should take responsibility for deleting it.
Shared Database (47) requires adding new schema to the database to accommodate the data or force-fitting the data into the existing schema. Once the data is in the database, there’s the risk that other applications that should not have access to the data now do. Triggering the receiver of the data to come and read it can be difficult, and coordinating multiple readers can create confusion about who should delete the data.
Remote Procedure Invocation (50) can be used to send the data, but then the caller is also telling the receiver—via the procedure being invoked—what to do with the data. Likewise, a Command Message (145) would transfer the data but would be overly specific about what the receiver should do with the data. Also, Remote Procedure Invocation (50) assumes two-way communication, which is unnecessary if we only want to pass data from one application to another.
Yet, we do want to use Messaging (53) to transfer the data. Messaging (53) is more reliable than an RPC. A Point-to-Point Channel (103) can be used to make sure that only one receiver gets the data (no duplication), or a Publish-Subscribe Channel (106) can be used to make sure that any receiver who wants the data gets a copy of it. So, the trick is to take advantage of Messaging (53) without making the Message (66) too much like an RPC.
){kind=small}
Figure 5.2 Use a Document Message to reliably transfer a data structure between applications.
Whereas a Command Message (145) tells the receiver to invoke certain behavior, a Document Message just passes data and lets the receiver decide what, if anything, to do with the data. The data is a single unit of data, a single object or data structure that may decompose into smaller units.
Document Messages can seem very much like Event Messages (151); the main difference is a matter of timing and content. The important part of a Document Message is its content: the document. Successfully transferring the document is important; the timing of when it is sent and received is less important. Guaranteed Delivery (122) may be a consideration; Message Expiration (176) probably is not. In contrast, an Event Messages (151) existence and timing are often more important than its content.
A Document Message can be any kind of message in the messaging system. In JMS, the document message may be an ObjectMessage containing a Serializable data object for the document, or it may be a TextMessage containing the data in XML form. In .NET, a document message is a Message (66) with the data stored in it. A Simple Object Access Protocol (SOAP) reply message is a document message.
Document Messages are usually sent using a Point-to-Point Channel (103) to move the document from one process to another without duplicating it. Messaging (53) can be used to implement simple workflow by passing a document to an application that modifies the document and then passes it to another application. In some cases, a document message can be broadcast via a Publish-Subscribe Channel (106), but this creates multiple copies of the document. The copies need to be read-only; otherwise, if the receivers change the copies, there will be multiple copies of the document in the system, each containing different data. In Request-Reply (154), the reply is usually a Document Message, where the result value is the document.
Example: Java and XML
The following example (drawn from the example XML schema in [Graham]) shows how a simple purchase order can be represented as XML and sent as a message using JMS.
Session session = // Obtain the session
Destination dest = // Obtain the destination
MessageProducer sender = session.createProducer(dest);
String purchaseOrder =
" <po id=\"48881\" submitted=\"2002-04-23\">
<shipTo>
<company>Chocoholics</company>
<street>2112 North Street</street>
<city>Cary</city>
<state>NC</state>
<postalCode>27522</postalCode>
</shipTo>
<order>
<item sku=\"22211\" quantity=\"40\">
<description>Bunny, Dark Chocolate, Large</description>
</item>
</order>
</po>";
TextMessage message = session.createTextMessage();
message.setText(purchaseOrder);
sender.send(message);
Example: SOAP and WSDL
With the SOAP protocol [SOAP 1.1] and WSDL service description [WSDL 1.1], when using document-style SOAP messages, the SOAP message is an example of a Document Message . The SOAP message body is an XML document (or some kind of data structure that has been converted into an XML document), and the SOAP message transmits that document from the sender (e.g., the client) to the receiver (e.g., the server).
When using RPC-style SOAP messaging, the response message is an example of this pattern. With this usage, the SOAP message body (an XML document) contains the return value from the method that was invoked. This example from the SOAP specification returns the answer from invoking the GetLastTradePrice method.
<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:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>