Via
Savas,
this paper on Microsoft's
take on a holistic view of the various Web Services specifications.
I agree with
most of this, especially that SOAP is the lowest point in the Web Services stack
(more specifically I believe SOAP to be the transfer protocol and defining
property for Web Services).
However I
fundamentally disagree with the latter parts of the WS-Addressing description
(which are presented normatively in the
WS-Addressing specification).
If I extrapolate from all we've seen lately (including the latest
WS-Eventing
draft, and now this) I predict that within 12 months all
information in SOAP messages will appear inside a reference properties or
reference parameter element. How would this make you feel:
<soap:Envelope ... >
<soap:Header>
<wsa:MessageID>
http://honest-joes-computer-spares.com/order#adc334321345defe394f
</wsa:MessageID>
<wsa:To>http://honest-joes-computer-spares.com/sales</wsa:To>
<wsa:Action>http://honest-joes-computer-spares.com/buy-stuff</wsa:Action>
<jw:item>disk drive</jw:item>
<jw:quantity>10</jw:quantity>
<jw:salesman>Peter Parker</salesman>
</soap:Header>
<soap:body/>
</soap:Envelope>In effect, we send a message not to a Web Service but to a specific resource
hosted by the service (Peter Parker) and contextualise the interaction with that
resource with some interaction-specific metadata (in this case 10 disk drives).
I can deal with the fact that WS-Addressing lets people do things I don't
agree with (like WS-RF), but do we really need
Microsoft - a pillar of architectural sense - setting such a bad example? For instance the document points out
this aspect of WS-Addressing:
When using an endpoint reference to construct a message for the endpoint, the
sender is responsible for including all reference properties and reference
parameters as header blocks.
Why am I as the consumer of a service now lumbered with (presumably durably?)
storing all this stuff on behalf of the service? The only reason I can see for
this is where the designer of the service hasn't created a protocol consisting
of sufficiently descriptive messages and so each message requires augmentation
to reach its intended internal-to-the-service destination. It goes on to say:
Typically, the base address and reference properties identify a
given deployed service and the reference parameters are used to identify
specific resources that are managed by that service.
Well that's a cunning stunt - on the one hand the best architectural thinking
tells us that:
"The boundaries of a service are well-defined when they are
incorporated into a distributed application. Other services do not see the
internal workings, implementation details, or resource representations of a
service" (Don Box, MSDN TV:
part 1,
part 2)
Yet on the other hand WS-Addressing allows us to reference precisely those
resources. Arguments about the opacity of the parameters simply don't cut it
here: one of the famous four tenets is utterly violated.
So is there a happy ending to this? Yes, at least I think there probably is.
Microsoft have, with the exception of a significant part of WS-Addressing and
some rather weird
HTTP over SOAP over HTTP stuff, outlined a sensible framework for a global
Web Services architecture. Sure there will be arguments over which competing
protocol to use in some places, but this grand architectural vision is a step in
the right direction.
Today's Web Services Arch-Villain: <wsa:ReferenceParameters> and <wsa:ReferenceProperties>
Today's Web Services Super-Hero: The URI
Update: Thanks to Savas for pointing out SOAP
binding error in the example.