W3C home > Mailing lists > Public > www-ws-desc@w3.org > July 2005

RE: soap:header extensibility with mU primer example

From: David Orchard <dorchard@bea.com>
Date: Wed, 13 Jul 2005 11:14:22 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF1122DEEC@ussjex01.amer.bea.com>
To: "Jonathan Marsh" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>
How is this any different than taking an endpoint that doesn't support
ws-security, then adding a ws-policy attachment that says ws-security
must be used (and ws-security says set the mu="true")?  


One way of looking at your position is that you think that a client
should never put a mustUnderstand on a header block that is described in
WSDL but it's allowed to do it on anything that might be described in
any other spec that is referenced by Policy or f&p. 


I think it strange to allow only Policy/feature authors the ability to
say something that WSDL 2.0 straight up can describe.





From: Jonathan Marsh [mailto:jmarsh@microsoft.com] 
Sent: Wednesday, July 13, 2005 11:00 AM
To: David Orchard; www-ws-desc@w3.org
Subject: RE: soap:header extensibility with mU primer example


Sorry Dave, but we don't find this motivation very compelling.  This
seems like the clumsiest way imaginable to introduce an incompatible
version.  We have a variety of other mechanisms that could be employed,
including introducing a new name for the new operation, introducing a
new endpoint, or adding an app-level version identifier into the message
body with appropriate failure semantics.  If this is the best motivation
you can come up with, we would rather see the mU capability removed.


Speaking for Microsoft not as chair,




From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of David Orchard
Sent: Tuesday, July 12, 2005 3:48 PM
To: www-ws-desc@w3.org
Subject: soap:header extensibility with mU primer example


A proposed section for the Primer if people accept the example and


Additional  Additional mandatory elements in header.


A primary motivation for soap:mustUnderstand is to enable a client to
ensure that a service understands a soap header block that the client
sends.  Imagine that the reservation interface is controlled by a 3rd
party such as a travel consortium.  The travel consortia decides to make
the NumberOfGuests a soap header block rather than part of the body,
perhaps on the initial version or a subsequent version.  There are a
variety of reasons for this.  The extension could be handled in a well
factored design at the service by a specialized piece of software.   A
3rd party specifying the header blocks is why Web Service specifications
will often require that the mustUnderstand flag is set to true. 


The binding using mustUnderstand is:


<operation ref="tns:opCheckAvailability">


         <wsoap:header wsoap:mustUnderstand="true"




Any client that uses the new interface will set the soap:mustUnderstand
attribute in the message.  If the service receiving the messages does
not understand the extension, it will fault.





Received on Wednesday, 13 July 2005 18:14:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:55 UTC