RE: soap:header extensibility with mU primer example

Which proposed example?  The proposed example I had was for
NumberOfGuests, and I used an analogy to WS-Security.  Requiring
WS-Security headers on messages is by definition adding to the content
of the soap envelope.  My point is that a WSDL that contains a policy
statement that says use WS-Security transitively adds a mustUnderstand
header block into a soap envelope, so why deny a WSDL author the same?
I guess I could define NumberOfGuests Specification that says
mustUnderstand must be set, and then use Policy to associate the
NumberOfGuests spec with an interface or binding, but that seems against
where WSDL is going.  Or do you think that every thing that could be
specified for a soap header with mU must only be specifiable using
ws-policy?

 

If the Primer example is unmotivating for the feature, then the feature
won't get added and we won't need a primer example.  I offered a primer
example because it seems useful to use primer examples to illustrate and
explain features of WSDL 2.0.

 

The aspect that I think is the hardest for people to buy into is the
notion that the service provider might not control the interface they
are offering.  All WS-* specifications define either soap header blocks
or bodies, and the service provider can either offer them or not.  

 

Perhaps a different example.  

 

Imagine I have a specification for some messages.  Maybe WS-Transfer, or
some Travel Alliance application messages or whatever.  If the service
provider wants to provide that interface and they also want the client
to send some additional required information, how do they do it?  They
can't change the WS-Transfer interface operation definition of "Get".
What I'm proposing allows them to do exactly what they need: re-use the
interface and specify additional required information.  

 

  _____  

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
Sent: Wednesday, July 13, 2005 4:19 PM
To: David Orchard; Jonathan Marsh; www-ws-desc@w3.org
Subject: RE: soap:header extensibility with mU primer example

 

Sorry David, but you confused me. 

 

Your proposed example is not talking about a QoS which does not really
change the message payload, but adding to the content of the message. I
am not clear about your analogy to usage of policy at all. We are
talking about the content of messages, not adding metadata that governs
the content with the way the mU is used here.  I am not favor of  the
approach since it fuses these two  concepts. Further, the writeup does
not really motivate a Primer reader to understand why one would really
choose this approach over others Jonathan mentioned. I am getting
somewhat concerned about adding more material to the Primer  at this
point as well. 

 

 

Cheers, 

 

--umit

 

 

	
  _____  


	From: www-ws-desc-request@w3.org
[mailto:www-ws-desc-request@w3.org] On Behalf Of David Orchard
	Sent: Wednesday, Jul 13, 2005 11:14 AM
	To: Jonathan Marsh; www-ws-desc@w3.org
	Subject: RE: soap:header extensibility with mU primer example

	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.

	 

	Dave

	 

	
  _____  


	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,

	Jonathan

	 

	
  _____  


	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 motivation.

	 

	Additional 5.2.5.4.  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">

	       <input>

	         <wsoap:header wsoap:mustUnderstand="true"
element="tns:NumberOfGuests"/>

	       </input>

	    </operation>

	 

	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.

	 

	Cheers,

	Dave