I'm trying to understand the versioning case for
wsoap:header/@mustUnderstand and I'm getting lost again.

Under the replacement scenario, I might deploy a service A with WSDL A.
Later I replace service A' with WSDL A', with mustUnderstand="true".  A
client that hasn't been updated to A' will get back a failure, which is
an indication that the service has been updated in an incompatible way.
That seems good, but it's not clear to me (1) why I would be deploying
an incompatible service at the same endpoint, and if so (2) why I
wouldn't indicate this using an application-level construct, (3) why I
would rely on a feature of the SOAP binding to indicate this
incompatibility, and {4} why this isn't a problem for body content not
just SOAP headers.

Under the parallel update scenario, I might deploy a service B with WSDL
B, and a new incompatible version at B' with WSDL B'.  A client that
talks WSDL B' can presumably talk with both B and B'.  A client that is
used to talking WSDL B can continue to talk to B, but will fail when
talking to B'.  Why isn't this a case of a client talking gibberish to a
service?  That is, if I send a purchase order to my stock quote service,
I'd hope something would fail regardless of any mustUnderstand in the
WSDL.  The discovery method for a client who only talks to services with
WSDL B, yet returns services on (incompatible version) WSDL B', WSDL C,
or WSDL Z, is simply broken.

Can someone explain the versioning (or any other use case) again to me?
I thought I had it on the call, but when I tried to think it through it
slipped my grasp.

Received on Friday, 8 July 2005 19:38:41 UTC