The SOAP Model

Web services are an instance of the service-oriented architecture pattern that use SOAP as the (logical) transport mechanism for moving messages between services described by WSDL interfaces. This is a conceptually simple architecture, as shown in Figure 3-1, where SOAP messages are propagated via some underlying transport protocol between Web services.

Figure 3-1. The logical Web services network.

A SOAP message is an XML document whose root element is called the envelope. Within the envelope, there are two child elements called the header and the body. Application payloads are carried in the body, while the information held in the header blocks usually contains data from the various Web services protocols that augment the basic SOAP infrastructure (and which is the primary subject of this book). The structure of a SOAP message is shown in Figure 3-2.

Figure 3-2. The structure of a SOAP message.

The SOAP message shown in Figure 3-2 provides the conceptual basis on which the whole SOAP model is based. Application payload travels in the body of the message and additional protocol messages travel in header blocks (which are optional, and may not be present if only application data is being transported). This permits a separation of concerns at the SOAP processing level between application-level messages and higher-level Web services protocols (e.g., transactions, security) whose payload travels in the SOAP header space.

The split between application and protocol data within SOAP messages allows the SOAP processing model to be a little more sophisticated than was suggested by the simple architecture shown in Figure 3-1. SOAP's distributed processing model outlines the fundamentals of the Web services architecture. It states (abstractly) how SOAP messages including both the header and body elements are processed as they are transmitted between Web services. In SOAP terms, we see that an application is comprised of nodes that exchange messages. The nodes are free to communicate in any manner they see fit, including any message-exchange pattern from one-way transmission through bilateral conversations. Furthermore, it is assumed in SOAP that messages may pass through any number of intermediate nodes between the sender and final recipient.

More interestingly however, the SOAP specification proposes a number of roles to describe the behavior of nodes under certain circumstances, which are shown in Figure 3-3. As a message progresses from node to node through a SOAP-based network, it encounters nodes that play the correct role for that message. Inside message elements, we may find role declarations that match these roles (or indeed other roles produced by third parties), and where we find a node and message part that match, the node executes its logic against the message. For example, where a node receives a message that specifies a role of next (and every node except the sender is always implicitly next), the node must perform the processing expected of that role or fault. In Figure 3-3, we see that the nodes labeled "intermediate" all play the role next. The Web service that finally consumes the message plays the role ultimateReceiver, and so each processes only the parts of the SOAP message which are (either implicitly or explicitly) marked as being for that role.

Figure 3-3. SOAP node roles.

The processing model shown in Figure 3-3 is supported in software by SOAP servers. A SOAP server is a piece of middleware that mediates between SOAP traffic and application components, dealing with the message and processing model of the SOAP specification on a Web service's behalf. Therefore, to build Web services, it is important to understand how a SOAP server implements the SOAP model.

While it is impossible to cover every SOAP server platform here, we will examine the architecture of a generalized SOAP server (whose characteristics are actually derived from popular implementations such as Apache Axis and Microsoft ASP.Net) so that we have a mental model onto which we can hang various aspects of SOAP processing. An idealized view of a SOAP server is presented in Figure 3-4. This shows a generic SOAP server architecture. Inbound messages arrive via the physical network and are translated from the network protocol into the textual SOAP message. This SOAP message passes up the SOAP request stack where information stored in SOAP headers (typically context information for other Web services protocols like security, transactions and so forth) are processed by handlers that have been registered with the Web service. Such handlers are considered to be intermediate nodes in SOAP terms.

Figure 3-4. The architecture of a generalized SOAP server.

The handlers that operate on the headers are not generally part of the SOAP server by default, but are usually third-party components registered with the server to augment its capabilities. This means that SOAP servers are themselves extensible and can be upgraded to include additional protocol support over their lifetime as Web services' needs evolve.

At some later point, provided the header processing has not caused the service invocation to fail, the application payload of the message (carried in the SOAP body) reaches a dispatch mechanism where it causes some computation to occur within the back-end service implementation. The application logic then performs some computation before returning data to the dispatcher, which then propagates a SOAP message back down the SOAP response stack. Like the request stack, the response stack may have handlers registered with it which operate on the outgoing message, inserting headers into messages as they flow outward to be consumed by other Web services. Again, these handlers are considered to be nodes in SOAP terms.

Eventually, the outgoing message reaches the network level where it is marshaled into the appropriate network protocol and duly passes on to other SOAP nodes on the network, to be consumed by other SOAP nodes.