O, semantics, where art thou?

XML Nation

Home

Pluralsight Blogs

Syndication

Archives

There's nothing like someone else posting on a topic I've been thinking about a lot lately to push me to finally write a post about it. So it is with this post about message semantics from Steve Maine. Here are my somewhat organized thoughts on the matter...

In the earliest days of SOAP, the body of a message carried an application-specific payload. It was generally agreed that that payload conveyed intent. The HTTP SOAPAction header was a representation of intent at the protocol level, which made it possible to know (or to think you know) what a SOAP message contains without parsing the message. In the original draft of SOAP, the SOAPAction (once called the SOAPMethodName) header URI was derived from the namespace URI and localname of the first element child of the SOAP body. That pattern was dropped before SOAP 1.1.

A lot of people agree that you don't want to use SOAPAction to convey anything that is not otherwise in your SOAP message and that relying on a transport-level mechanism for processing is really not a good idea. That said, ASMX uses the HTTP SOAPAction header to dispatch requests by default. You can tweak a service to use the element name of the message body instead. Some toolkits will only use the element name of the message body. (It is also worth noting that using SOAPAction or any other transport level mechanism in conjunction with message-oriented security is not a good idea. The WS-I security profile suggests that SOAPAction should not be used if you are using WS-Sec, et. al., in place of HTTPS.)

While SOAPAction is generally deprecated by all, WS-Addressing's Action header is being embraced, at least by some. In his talk at the Applied XML DevCon, Don said that the Action header conveys message intent. He did not mention its relationship to the content of the message body, if any. He did mention that message intent bears little or no relationship to the definition of a portType/operation.

To understand the rationale for that position, consider the WS-MetadataExchange specification, which defines a message for retrieving a contract (XSD, WSDL, Policy, etc.) from a service. We need such a mechanism because we can't rely on HTTP GET for two reasons: some service may not use HTTP and, more importantly, even if they do, there is no standard way to know how to map a service endpoint to an URL that retrieves contract documents (?WSDL is just a convention). For this to work, the messages that WS-MetadataExchange defines have to work the same way across all services, independent of the service's portType/operation (although frankly, there may be no operation exposed in the contract for getting metadata, as it is entirely hidden in the plumbing).

This model of defining standard messages independent of portType/operation carries over into all the higher-level WS-* specs, including WS-Eventing, WS-Enumeration and WS-Transfer, in addition to WS-MetadataExchange. That's why these specs are defined in terms of message structure not WSDL. They only include WSDL definitions as non-normative appendices.

Okay, so we have these specs that define messages with meaning independent of portType/operation. If two different portType/operations refer to the same message, they mean the same thing. At least, that’s how it appears so far. However, there are at least two other data points worth considering.

The first is this post from Jeff Schlimmer, who observes that while a WS-Addressing Action URI may reflect the namespace URI and localname of an element inside a message body, this is a convention, nothing more. Certainly that’s the model followed by the WS-Eventing, WS-Enumeration, and WS-MetadataExchange specs. WS-Transfer is the only WS-* spec that doesn’t embrace this model. Instead, it uses an Action URI and an empty body to represent a GET request and an Action URI with any body to represent a GET response. In order to support models like this, Jeff observes, it is useful to view the Action URI and not the message body as the thing that carries semantic intent.

The second is that, despite Don’s observation that portType/operation doesn’t mean anything; the default for a SOAPAction in ASMX is derived from the name of your operation, not the message being sent. Similarly, in the latest draft of the WS-Addressing spec, if you don’t include a wsa:Action attribute on the input/output elements in your WSDL, a default value is constructed for you based on your portType/operation name.

If all of this makes your head spinning, it should, because there is a lack of consistency here. If I’m designing a Web service, where do semantics exist? Are they in the message body, where they started? Are they in one or both of the action URIs? If they aren’t in SOAPAction because we don’t want to count on a header, should they be in wsa:Action, which is also a header? Can portType/operation define semantics (as the default values of various action headers suggest) or not?

I think this issue can be boiled down to three simple questions that we have to answer. If the WS-Addressing WG at the W3C doesn’t answer them, expect WS-I to warm up the profiling engines. Here they are: