Messaging Architectures

Obviously, you could argue that each XML messaging application has its own unique architecture. However, much of the variability in protocol features requirements comes from the high-level distinction between applications serving the two motivations for XML messaging discussed previously. While business document architectures and remote interface architectures share the basic need to exchange XML data among applications, the purpose, communication model, and resulting need for extended features differ significantly.

Business document applications naturally reflect the semantics of the business processes that they serve. Consider the process of "Purchasing." In the paper world, this process requires customer and supplier staff to assemble and exchange a certain set of documents such as "Request for Proposal," "Proposal," "Purchase Order," "Shipment Notification," and "Invoice." The exchange of these documents occurs in a well-defined pattern ”an "Invoice" requires the previous exchange of a "Purchase Order" and a "Shipment Notice." The sender does not usually expect an immediate response other than the acknowledgment that the document was received. It implicitly understands that the other party may perform a significant amount of internal processing before it's ready to send the next document in the business process. People also use terms like message-oriented architectures and coarse-grained Web Services to describe this type of application.

Remote interface applications naturally reflect the semantics of the applications they encapsulate. Consider an "Order Entry" application. It offers a certain set of functions such as "Create New Order," "Set Billing Address," "Add Line Item," "Set Payment Terms," and "Check Order Status." Using these functions requires some knowledge of the application design. One "Order Entry" application may require that you "Set Payment Terms" before you "Add Line Item," while another may not. The sender expects an immediate response because it usually needs to use the value of that response in the very next request. Because each function performs a relatively small piece of work, the sender implicitly understands that it needs to make a series of related requests . People also use terms like remote procedure call (RPC) architectures and fine-grained Web Services to describe this type of application.

Basic Protocol Requirements

The different semantics of the two architectures lead to different communication models. Business document applications typically require an asynchronous model ”the sender does not wait for the receiver to reply. Each document represents an action within a broader business process. The very act of sending the document completes the corresponding action. There is no need for further communication until the receiving party completes the next action. From the networking perspective, the sending party transfers a single, large block of data to the receiving party. The sending program does not wait for an immediate response before continuing on to the next task. Later, the roles may reverse with a new document flowing in the other direction. The asynchronous model works well over the Internet where latencies ”delays as the message moves through switches, routers, and servers ”are often too high to guarantee a timely response. Figure 4-2 shows the asynchronous communication model of the business document model architecture.

Figure 4-2. Asynchronous Communication Model

On the other hand, remote interface applications typically require a synchronous communication model ”the sender waits for the receiver to respond. Remote interfaces mimic the operation of local programming language interfaces. Most programming languages structure interfaces as a set of functions, each with a set of possible request parameters and a set of possible return values. Usually, each function call makes sense only in the context of a series of function calls related to a larger goal. Providing the same structure over a remote connection requires that the sender wait in a synchronous fashion for the recipient to process the request and return an appropriate value. Even if a particular transport does not physically have to wait for the return value, the dependencies of subsequent function calls on the return value impose a semantic requirement to wait for its completion. The synchronous model works well over intranets where lower latencies enable timely response, and the close dependencies among enterprise applications make interaction at the function level desirable. Figure 4-3 shows the synchronous communication model of the remote interface architecture.

Figure 4-3. Synchronous Communication Model

Additional Protocol Requirements

The combination of semantics and communication models influence the necessary protocol features. Because a business document transmission represents the completion of an entire business action, the sending application needs absolute assurance that the receiving application gets the document. However, the asynchronous communication model means that it may require some time and perhaps even intermediate processing by the messaging system to deliver the document. So the sender has no immediate indication that the message was received. Therefore, business document applications need a protocol that is reliable. It can guarantee the delivery of documents to a specific target application.

As for security, these applications may need explicit authorization traceable to a particular staff member of appropriate authority. As a completed action, a business document essentially authorizes the receiving party to take subsequent actions based on the information contained in the document. They often require the security property of nonrepudiation ”a provable commitment, equivalent to signing a physical document. However, the ability to define transaction boundaries is unnecessary. Each document represents a whole business action and is therefore implicitly a single transaction. There is rarely a need to specify that multiple messages are part of the same transaction.

Remote interface applications require almost the negative image of extended features from the messaging protocol. Because each function call represents only part of a larger operation, these applications usually need the ability to define transaction boundaries explicitly. If a set of function calls changes several pieces of related information, the sending application needs the absolute assurance that either all or none of these changes will occur.

From the perspective of security, remote interface applications rely on the mutual authentication of sender and recipient identities. There is no need for nonrepudiation of each function call. Once authenticated, the recipient simply verifies that the sender has the authorization to perform that particular function call. However, reliable message delivery is superfluous. Because the function call model requires the successful return of the call, the sender can assume that the recipient got the message if the function returns successfully. If the function takes too long to return, the sender can time out and retry the call.

Using Both Architectures

Neither architecture is inherently better than the other. They have different purposes: Business document architectures work best when the parties need to exchange well-defined work products over the Internet. Remote interface architectures work best when parties need to assemble a set of information flexibly from small pieces over an intranet. Ideally, e-commerce systems use both architectures simultaneously .

An enterprise gateway acts as both a business document application and a remote interface application. The business document half exchanges packages of business data, while the remote interface half assembles these packages through remote function calls. The business document halves of the gateways talk to each other, while the remote interface halves talk to internal applications. Figure 4-4 shows this combination of architectures.

Figure 4-4. Combining the Two Architectures