Bindings can do a huge variety of different things for us—compare this variety to what the SOAP header mechanism can do, and you might notice that the set of possible semantics you can achieve is similar (almost anything, in fact).The designers of SOAP 1.2 noticed the similarity as well, and wanted to write a framework that might help future extension authors describe their semantics in ways that were easy to reason about, compare with each other, and refer to in machine-readable ways.
What was needed was a way to specify that a given semantic could be implemented either by a binding or by using SOAP headers. Nodes might use this information to decide whether to send particular headers—if you’re running on top a secure binding, for instance, you might not need to add security headers to your messages, which can save your application effort and time. Also, since a variety of modules might be available to an engine at any given time, it would also be nice to be able to unambiguously indi-cate that a particular module performed a certain set of desired semantics.To achieve these goals, the first job was to have a standard way to name the semantics in question.
The SOAP authors came up with an extensibility framework that is described in sec-tion 3 of part 1 of the SOAP 1.2 spec.The framework revolves around the nosec-tion of an abstract feature
g
, which is essentially a semantic that has a name (a URI) and a specifi-cation explaining what it means. Features can be things like reliability, security, transac-tions, or anything you might imagine. A feature is typically specified by describing the behavior of each node involved in the interaction, any data that needs to be known before the feature does its thing, and any data that is transferred from node to node as a result. It’s generally convenient if the specification of the feature’s behavior can be found at the URI naming the feature—so if a user sees a reference to it somewhere, they can easily locate a description of what it does.The state relevant to a feature is generally described in terms of named properties
g
. Properties, in the SOAP 1.2 sense, are pieces of state, named with URIs, which affect the operation of features. For instance, you might describe a “favorite color” feature that involves transferring a hexadecimal color value from one node to another.You wouldpick a URI for the feature, describe the rules of operation, and name the color property with another URI. Because a feature definition is abstract, you don’t say anything about how this color would move across the wire.
Features are expressed (turned into reality via some mechanism) by bindings and mod-ules.We’ve already described both of these—recall that a binding is a means for ing functions below the SOAP processing model, and a module is a means for perform-ing functions usperform-ing the SOAP processperform-ing model, via headers.
Here’s a simple example of how a feature might be expressed by a binding in one case and a module in another. Imagine a “secure channel” feature.The specification for this feature indicates that it has the URI http://skatestown.com/secureChannel, and the abstract feature describes a message traveling from node to node in an unsnoopable fashion (to some reasonable level of security).We might then imagine a SOAP binding to the HTTPS protocol, which would specify that it implements the
http://skatestown.com/secureChannelfeature. Since HTTPS meets the security requirements of the abstract feature, the feature would be satisfied by the binding with no extra work, and the binding specification would indicate that it natively supports this feature.We could also imagine a SOAP module (something like WS-Security, which we discuss in Chapter 9, “Securing Web Services”) that provides encryption and signing of a SOAP message across any binding.The module specification would also state that it implements the secureChannelfeature.With this information in hand, it would be pos-sible, in a situation that required a secure channel, to decide to engage our SOAP mod-ule in some situations (when using the HTTP binding, for instance) and to not bother in other situations where the HTTPS binding is in use.
Another example of making features concrete could be the color feature discussed earlier.The feature spec describes moving a color value from the sender to the receiver in the abstract. A custom binding over email might define a special SMTP header to carry this color information outside the SOAP envelope.Writing a SOAP module to satisfy the feature would involve defining a SOAP header that carried the value in the envelope.
Message Exchange Patterns
One common type of feature is a Message Exchange Pattern (MEP)
g
. An MEP specifies how many messages move around in a given interaction, where they originate, and where they end up. Each binding can (and must) support one or more message exchange patterns.The SOAP 1.2 spec defines two standard MEPs: Request-Response and SOAP Response.Without going into too much detail (you can find the full specifications for these MEPs in the SOAP 1.2 spec, part 2), we’ll give you a flavor of what these MEPs are about.The Request-Response MEP involves a requesting node and a responding node. As you might expect, it has the following semantics: First, the requesting node sends a SOAP message to the responding node.Then the responding node replies with a SOAP message that returns to the requesting node. See Figure 3.9.
155 The Transport Binding Framework
Figure 3.9 The Request-Response MEP
You should note a couple of important things here. First, the response message is corre-lated to the request message—in other words, the requesting node must be able to figure out which response goes with which request. Since the MEP is abstract, though, it doesn’t specify how this correlation is achieved but leaves that up to implementations.
Second, if a fault is generated at the responding node, the fault is delivered in the response message.
The SOAP Response MEP is similar to the Request-Response MEP, except for the fact that the request message is explicitly not a SOAP message. In other words, the request doesn’t trigger the execution of the SOAP processing model on the receiving node.The receiving node responds to the request with a SOAP message, as in the Request-Response MEP (see Figure 3.10).
Requesting
Figure 3.10 The SOAP Response MEP
The primary reason for introducing this strange-seeming MEP is to support REST-style interactions with SOAP (see the sidebar “REST-Style versus Tunneled Web Services”).
The SOAP Response MEP allows a request to be something as simple as an HTTP GET; and since the responding node doesn’t have to implement the SOAP processing model, it can return a SOAP message in any way it deems appropriate. It might, for instance, be an HTTP server with a variety of SOAP messages in its filesystem.
As you’ll see in a moment, the HTTP binding natively supports both of these MEPs.
Of course, MEPs, like other abstract features, can also be implemented via SOAP mod-ules. Here’s an example of how the Request-Response MEP might be implemented using SOAP headers across a transport that only allows one-way messages:
<soapenv:Envelope
<!--This header specifies the return address-->
<reqresp:ReplyTo soapenv:mustUnderstand=”true”
xmlns:reqresp=”http://skatestown.com/requestResponse”>
<destination>udp://me.com:6666</destination>
</reqresp:ReplyTo>
<!--This header specifies a correlation ID-->
<reqresp:correlationID soapenv:mustUnderstand=”true”
xmlns:reqresp=”http://skatestown.com/requestResponse”>
1234
</reqresp:correlationID>
</soapenv:Header>
<soapenv:Body>
<doSomethingCool/>
</soapenv:Body>
</soapenv:Envelope>
This message might have been sent in a UDP datagram, which is a one-way interaction.
The receiver would have to understand these headers (since they’re marked
mustUnderstand) in order to process the message; when it generated a reply, it would follow the rules of the ReplyToheader and send the reply via UDP to port 6666 of host
me.com.The reply would contain the same correlationIDsent in the request, so that the receiver on me.comwould be able to match the response to the pending request.The WS-Addressing spec includes a mechanism a lot like this, which we’ll cover in Chapter 8, “Web Services and Stateful Resources.”
If your interaction requires the request-response MEP, you might choose to use the HTTP binding (or any binding that implements that MEP natively), or you might use a SOAP module that specifies how to implement the MEP across other bindings.The important goal of the framework is to enable abstractly defining what functionality you need—then you’re free to select appropriate implementations without tying yourself to a particular way of doing things.
REST-Style versus Tunneled Web Services
REpresentational State Transfer (REST)
g
refers to an architectural style of building software that mirrors what HTTP is built to do: transfer representations of the state of named resources from place to place with a small set of methods (GET, POST, PUT, DELETE). The methods have various semantics associated with them—for instance, a GET is a request for a resource’s representation, and by definition GETs should be safe operations. “Safe” in this context means they should have no side effects. So, you do a GET on my bank account URL in order to obtain your current balance, you can repeat that operation many times with no ill effects. However if the GET withdrew funds from your account, , that would clearly be a serious side effect (and therefore illegal in REST).Another interesting thing to note about GET is that the results are often cacheable: If you do a GET on a weather report URL, the results probably won’t change much if you do it again in 10 minutes. As a result, the infrastructure can cache the result, and if someone asks for the same GET again before the cache entry-expires, you can return the cached data instead of going out over the Net to fetch the same weather again.
157 The Transport Binding Framework
The HTTP infrastructure uses this caching style to great effect; most large ISPs or companies have shared caching proxies at the edge of the network that vastly reduce the network bandwidth outside the organiza-tion—each time anyone asks for http://cnn.com, the cache checks if a local, fresh copy exists before going out across the network.
We bring up REST because it shines light on an interesting controversy. REST advocates (sometimes known as RESTifarians) noticed that SOAP 1.1’s HTTP binding mandated using the POST method. Since POSTs are not safe or cacheable in the same way GETs are, even simple SOAP requests to obtain data like stock quotes or weather reports had to use a mechanism that prevented the HTTP infrastructure from doing its job. Even though these operations might have been safe, SOAP was ignoring the HTTP semantic for safe operations and losing out on valuable caching behavior as a consequence.
This issue has since been fixed in the SOAP 1.2 HTTP binding, which supports the WebMethod feature. In other words, SOAP 1.2 is a lot more REST-friendly than SOAP 1.1 was, since it includes a specific technique for utilizing HTTP GET, including all that goes along with it in terms of caching support and operation safety.
HTTP semantics are respected, and HTTP isn’t always used as a tunnel for SOAP messages.
We believe that SOAP’s flexible messaging and extensibility model (which supports both semantics provided by the underlying protocol and also those provided by higher-level extensions in the SOAP envelope) offer the right framework for supporting a large variety of architectural approaches. We hope this framework will allow the protocol both good uptake and longevity in the development community.
Features and Properties Redux
The features and properties mechanism in SOAP 1.2 is a powerful and flexible extensi-bility framework. By naming semantics, as well as the variables used to implement those semantics, we enable referencing those concepts in an unambiguous way. Doing so is useful for a number of reasons—as you’ll see in Chapter 4, “Describing Web Services,”
naming semantics lets you express capabilities and requirements of your services in machine-readable form.This allows software to reason about whether a given service is compatible with particular requirements. In addition to the machine-readability aspect, naming features and properties allows multiple specifications to refer to the same concepts when describing functionality.This encourages good composition between extensions, and also allows future extensions to be written that implement identical (but perhaps faster, or more flexible) semantics.
Now that you understand the framework and its components, we’ll go into more detail about the SOAP HTTP binding.