WebReference.com - Part 1 of Chapter 3: Professional XML Web Services, from Wrox Press Ltd (2/7) | WebReference

WebReference.com - Part 1 of Chapter 3: Professional XML Web Services, from Wrox Press Ltd (2/7)

To page 1current pageTo page 3To page 4To page 5To page 6To page 7
[previous] [next]

Professional XML Web Services

The SOAP Message Exchange Model

The SOAP specification defines a model for exchanging messages. It relies on three basic concepts: messages are XML documents, they travel from a sender to a receiver, and receivers can be chained together. Working with just these three concepts, it is possible to build sophisticated systems that rely on SOAP.

XML Documents As Messages

The most fundamental concept of the SOAP model is the use of XML documents as messages. SOAP messages are XML. This provides several advantages over other messaging protocols. XML messages can be composed and read by a developer with a text editor, so it makes the debugging process much more simple than that of a complex binary protocol. As XML has achieved such widespread acceptance, there are tools to help us work with XML on most platforms.

We won't examine a SOAP message in detail until later in the chapter, but here is an example of one:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
      <w:Greeting xmlns:w="http://www.wrox.com/helloworld/">
         <w:message>Hello world!</w:message>

Senders and Receivers

When SOAP messages are exchanged, there are two parties involved: a sender, and a receiver. The message moves from the sender to the receiver. This operation is the basic building block of SOAP message exchanges, the smallest unit of work. The figure below illustrates this simple operation:

Sendor to Transport to Receiver diagram

In many cases, however, this type of operation is not enough. A more common requirement would be for messages to be exchanged in request-response pairs. As we will see later in the chapter, this is the method SOAP uses with the HTTP transport and/or the RPC convention. Requiring that model, however, would make it difficult to design one-way message exchanges. By starting with the most basic operation, a one-way message exchange from sender to receiver, more complicated exchanges can be composed without preventing the simplest exchanges from occurring. This gives us the ability to construct message chains.

Message Chains

SOAP messages do not have to follow a traditional client-server model. Messages might be exchanged in this manner, as in the case of HTTP, or a chain of logical entities might process the messages. This concept of a logical entity that performs some processing of a SOAP message is referred to as an endpoint. Endpoints are receivers of SOAP messages. It is the responsibility of an endpoint to examine a message and remove the part that was addressed to that endpoint for processing.

It is worth mentioning here that despite the "O" in SOAP, there is nothing object-oriented about the SOAP model. Endpoints, as well as clients, can be written in any language, and there is no presumption of "objects" existing on either end of the wire.

As the model allows us to combine one-way messages into more complex operations, endpoints can function as both receiver and sender. This capability allows for a processing chain to be created, with messages being routed through the chain with some potential processing occurring at each step. Endpoints that function as both sender and receiver, passing messages that they receive on to another endpoint, are referred to as intermediaries. Intermediaries and the message chain concept allow developers the opportunity to construct sophisticated systems based on SOAP. The figures below show some examples of message patterns that can be achieved through chaining endpoints together:

Various SOAP messaging scenarios

Endpoint Behavior

Thinking of SOAP in terms of endpoints helps to understand the flexibility of SOAP messaging. No matter what route a message takes, or how many endpoints may process it, all endpoints must handle messages in a certain way. Here are the three steps that an endpoint must take to conform to the specification:

We will revisit these steps later in the chapter. By conforming to these three requirements, endpoints can be chained together to form complex systems.

Modular Design

SOAP is open and extensible. That means that all of the following scenarios are acceptable and allowed by the SOAP specification:

How is it that SOAP can support such different scenarios with the same model? The answer is in SOAP's modular design. Throughout the specification, there are placeholders left open for future extensibility of the protocol. SOAP is designed to be extensible in all of the following areas:

Extensibility is important, but without some concrete implementations of these concepts, SOAP would be just a lot of interesting concepts. Luckily, the authors of SOAP provided a description of one implementation each of: data, transport, and purpose. For data, the Specification provides the SOAP encoding rules (section 5 encoding). For Transport, a transport binding for HTTP is defined. Finally, for purpose, the specification defines a convention for using SOAP messages for RPC.

We will cover each of these topics in more detail in this chapter. It is important to remember these four concepts, because the fact that they are separate from the protocol and therefore extensible is one of the biggest advantages of SOAP.

To page 1current pageTo page 3To page 4To page 5To page 6To page 7
[previous] [next]

Created: November 12, 2001
Revised: November 12, 2001

URL: http://webreference.com/authoring/languages/xml/webservices/chap3/1/2.html