SOAP Headers and Asynchronous Messaging

SOAP Headers and Asynchronous Messaging

An important use case for SOAP is the ability to send and receive SOAP messages asynchronously, and in this context, there are two possible definitions of that term. I will explain both.

Often, asynchronous programming is used to describe a programming model in which threads are utilized very well by never blocking while waiting for file access, network access, or other operations that depend on non-CPU time. This is important, but not what I want to talk about in this chapter.

The other meaning of asynchronous has to do with what is commonly called a Message Exchange Pattern, or MEP. In this case, asynchronous means that messages are sent, but there is no immediate response. Commonly, when using SOAP with HTTP, there is a request message and an immediate response message as part of the HTTP request–response pattern. This is evident with other protocols as well.

But because SOAP is protocol independent, you can also imagine sending a SOAP message with no immediate reply! Far from being considered an error case, this is in fact a powerful model for which SOAP provides.

With SOAP, you are passing two kinds of data: the XML in the body, which is the application or service-specific data, and header data. Data in the message body is XML intended for the final destination of the SOAP message. But, you can also send header data. By default headers are also for the final destination, but they also can be used as intermediaries that the SOAP message may come across along the way. You indicate this, along with the need (or lack thereof) for the header to be understood, by using the actor and mustUnderstand attributes on the header.

For example, imagine you wanted to send a header that authorized the message to pass through a corporate firewall using some special token. Listing 9.15 shows this code.

An Asynchronous SOAP Message
          <Alert xmlns="">
               KeithBa is online!

Now, when this message is sent, the entire message path, including who reads which pieces of data, should look something like Figure. Notice that the message is sent entirely in one direction. The MEP in this case is a one-way, or asynchronous, message. There could be a return message that would follow a possibly similar but reverse path. But all of these messages would follow separate paths, possibly over different transports as they move along. Even more important, they are related, but not at the transport level.

1. A Message-Sending Architecture


     Python   SQL   Java   php   Perl 
     game development   web development   internet   *nix   graphics   hardware 
     telecommunications   C++ 
     Flash   Active Directory   Windows