- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 8 Jul 2005 12:37:51 -0700
- To: <www-ws-desc@w3.org>
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