Protocol Design Problem

To understand how XML messaging works, it helps to consider how one might go about designing a basic distributed protocol with XML. Figure 4-1 captures the general problem. An instance of a software application running on one machine wants to send some XML data to an instance of another software application running on a different machine. There are three issues. First, what information does the sending application have to wrap around the XML data to enable processing by the receiving machine? Second, what is the low-level mechanism for moving this data across the network? Third, what additional contextual information will the receiving application need to facilitate message processing?

Figure 4-1. XML Messaging Problem

Wrapper Information

At a minimum, the wrapper information must identify the target application, specify what it wants this application to do, and indicate the data this application should use in fulfilling the request. A concrete example in plain English would be "The target application is the Shipping Application at http://www.foocompany.com/Application/Shipping; the application should perform its Get Status function; and it should use the Account Number ABCDEFGHI and the Order Number 123456789." To encode such a request as XML, identifying the target application and specifying the type of request clearly requires adding new information, either as elements or attributes. Indicating the data to use for execution requires a standard method for encoding such parameters in XML elements.

Once the receiving application processes the message, it may want to send back some information. This returned information might be as simple as an acknowledgement that it has received and understood the message. It could be a single value such as "Shipped," in the case of our hypothetical "Get Status" request. It could also be a sophisticated structure such as a complete "Shipment" business document. The protocol designer must decide the level of complexity to allow in the returned information. The designer must also decide where to interpret return values of a given complexity. Simple acceptance codes may belong at the transport level. A transport may also accommodate a single string return value. Returning an entire XML document may require a complete wrapper just like the request.

Transport Binding

Once the designer has a firm plan for formatting requests and responses, he needs to select a means of transporting information between sender and receiver. Typically, people refer to the combination of the message format and a transport as a binding. Different applications may require transports with different characteristics, so a messaging protocol should support multiple transport bindings. This goal starts to make the protocol designer's task very difficult because he must take into account the low-level behavior of many transports. A binding maps the features supported by the transport protocol to the information exchanges possible with the messaging protocol.

The most commonly used transport for Internet applications is HTTP, so it is the obvious binding for an XML messaging protocol, although others are certainly possible. HTTP includes a number of methods such as GET and POST. Requests and responses can be formatted as text, typically using the MIME standard to package different chunks of information. So the binding for an XML messaging protocol to HTTP must specify how to use these methods, how to use MIME for packaging different parts of transmissions, and the meaning of various return codes.

Contextual Information

So far, the designer has enough functionality to send XML data between applications and receive a reply. But many electronic commerce applications require extended features to meet the business needs of the parties. Security is one class of such features. At the very least, applications should authenticate themselves before exchanging messages. The message wrapper may need to reflect this requirement by including the identity of the sender, which the receiver verifies through the authentication process. Often, security concerns also necessitate further work on the transport binding. If exchanges include sensitive information, they may need encryption, a feature provided by HTTPS. While identical to HTTP except for additional security measures, the transport binding must specify how to use these features.

Reliability is another class of extended features. Certain circumstances may rely on guaranteed delivery of each message. Transactions are yet another class of feature. A sending application may want to indicate that a set of messages represents a single logical unit of work that should either succeed or fail together. Satisfying the requirements for these additional features depends on the precise architecture of the application messaging, and addressing different architectures is where complications in protocol design arise.