- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Thu, 5 Jan 2006 12:20:12 -0800
- To: <public-ws-addressing@w3.org>
- Message-ID: <37D0366A39A9044286B2783EB4C3C4E8012AABB9@RED-MSG-10.redmond.corp.microsoft.com>
[Since I rely on formatting in this message, I'm also attaching a version of this message in HTML.] Per my action item, here are two concrete proposals to address this issue in Section 3.1. The first generalizes the UsingAddressing element slightly to allow its reuse as a policy assertion (or any other framework that is based on QNamed elements): 3.1 UsingAddressing Extension Element WS-Addressing defines an empty global element, wsaw:UsingAddressing, that may be used to indicate that an endpoint conforms to the WS-Addressing specification in description languages or policy frameworks that use namespaced XML elements to indicate capabilities or requirements. The wsaw:UsingAddressing element MAY appear as an extension element in a WSDL description. In this case, the wsdl:required attribute MAY be used to indicate whether WS-Addressing Message Addressing Properties are required in messages received from service requesters. Table 3-1 outlines the requirements on messages sent from an endpoint based on the contents of any preceding input message and how the use of addressing is indicated in the WSDL. Table 3-1. MAPs Present in output message MAPs in Input message UsingAddressing Present UsingAddressing Not Present wsdl:required="true" wsdl:required="false" Yes, using SOAP headers with a soap:mustUnderstand value of "true" REQUIRED REQUIRED REQUIRED or fault Yes, using another protocol or using SOAP headers with a soap:mustUnderstand value of "false" REQUIRED REQUIRED OPTIONAL No Fault OPTIONAL. If using SOAP, MAP headers MUST NOT have a soap:mustUnderstand attribute with a value of "true" OPTIONAL. If using SOAP, MAP headers MUST NOT have a soap:mustUnderstand attribute with a value of "true" If WS-A is engaged, use of the message addressing properties MUST be fully compliant with this specification; in particular, senders MUST use all message addressing properties mandated by the Web Services Addressing 1.0 - Core[WS-Addressing-Core], applicable WS-Addressing protocol bindings (e.g. Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP]), and this specification, and MUST follow all applicable WS-Addressing normative requirements. The wsaw:UsingAddressing extension element SHOULD appear as a child of the wsdl:binding element. Alternatively, the wsaw:UsingAddressing extension element MAY instead be included as a child of the wsdl20:endpoint (or wsdl11:port) when an endpoint intends to indicate compliance with WS-Addressing for a specific endpoint only. The inclusion of the wsaw:UsingAddressing extension element indicates that the applicable WS-Addressing specifications are supported within the constraints of the WSDL binding being used. That is, uses of the WS-Addressing specifications that may violate or are inconsistent with the semantics of the endpoint's WSDL binding are not supported unless explicitly stated by some other mechanism. Specifically, when included in a SOAP binding, the wsaw:UsingAddressing extension element identifies the use of Web Services Addressing 1.0 bound to SOAP as defined by Web Services Addressing 1.0 - SOAP Binding[WS-Addressing-SOAP]. The presence of the wsaw:UsingAddressing extension element in the binding or endpoint (port) components of the endpoint description does not change the semantics of the binding. E.g. in the case of the WSDL SOAP/HTTP synchronous binding for request-response operations, the presence of the wsaw:UsingAddressing extension element does not change the requirement that the response message be sent over the same HTTP channel over which the request was received. In this case, the wsa:replyTo header in the request MUST NOT contain an address with a value different from the anonymous URI. When the wsaw:UsingAddressing element is associated with WSDL constructs through means other than direct use as a WSDL extension (e.g. through a policy framework), the meaning of such association is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension. Note that the association of wsaw:UsingAddressing to WSDL constructs where the wsaw:UsingAddressing WSDL extension element is not allowed is not meaningful. Example 3-1. Indicating use of WS-Addressing using wsaw:UsingAddressing in WSDL 2.0 <binding name="reservationSOAPBinding" interface="tns:reservationInterface" type="http://www.w3.org/2005/08/wsdl/soap12" wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP"> <wsaw:UsingAddressing wsdl:required="true" /> <operation ref="tns:opCheckAvailability" wsoap:mep="http://www.w3.org/2003/05/soap/mep/request-response" /> <fault ref="tns:invalidDataFault" wsoap:code="soap:Sender" /> </binding> Example 3-2. Indicating use of WS-Addressing using wsaw:UsingAddressing in WSDL 1.1 <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsaw:UsingAddressing wsdl:required="true" /> <operation name="GetLastTradePrice"> <soap:operation soapaction="http://example.com/GetLastTradePrice" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> 3.1.1 WSDL 2.0 Component Model Changes Use of WS-Addressing adds the following REQUIRED properties to the WSDL 2.0 component model: * A property of the binding or endpoint named {addressing required} of type xs:boolean. The property value is the value of the wsdl:required attribute information item on the wsaw:UsingAddressing extension element, if present; otherwise "false". The second proposal is less general, and just specifically blesses the reuse in policy assertions (although still in a general way): 3.1 UsingAddressing WSDL Extension Element ... 3.3 UsingAddressing Assertion The wsaw:UsingAddressing element may also be used as a policy assertion in a policy framework that expresses assertions as namespaced elements. The meaning of such an assertion is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension. When the wsaw:UsingAddressing assertion is associated with WSDL constructs, the meaning of such association is semantically equivalent to the use of wsaw:UsingAddressing as a WSDL extension. Note that the association of wsaw:UsingAddressing to WSDL constructs where the wsaw:UsingAddressing WSDL extension element is not allowed is not meaningful. > -----Original Message----- > From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing- > request@w3.org] On Behalf Of Jonathan Marsh > Sent: Monday, December 05, 2005 9:54 AM > To: Yalcinalp, Umit; public-ws-addressing@w3.org > Subject: RE: New Issue: wsaw:UsingAddressing as a policy assertion > > > I agree with all you say. The other concern that I have is that > although wsaw:UsingAddressing appears to be appropriate for use as a > policy assertion, not having that scenario documented will discourage > that appropriate (and we believe beneficial) use. > > IOW, if we had separate wsdl extension and policy assertion specs, there > would be calls for a profile to use only one of these mechanisms. In > our view, there are long-term benefits in a policy assertion, although > there are short-term difficulties in defining just a policy assertion at > this time. > > > -----Original Message----- > > From: public-ws-addressing-request@w3.org > [mailto:public-ws-addressing- > > request@w3.org] On Behalf Of Yalcinalp, Umit > > Sent: Friday, December 02, 2005 12:35 PM > > To: public-ws-addressing@w3.org > > Subject: RE: New Issue: wsaw:UsingAddressing as a policy assertion > > > > > > Apologies if you get this twice. Somehow the email will not appear in > > the archives. > > > > -----Original Message----- > > From: Yalcinalp, Umit > > Sent: Friday, Dec 02, 2005 12:17 PM > > To: 'Jonathan Marsh'; public-ws-addressing@w3.org > > Subject: RE: New Issue: wsaw:UsingAddressing as a policy assertion > > > > > > > > > -----Original Message----- > > > From: public-ws-addressing-request@w3.org > > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of > > > Jonathan Marsh > > > Sent: Thursday, Dec 01, 2005 5:15 PM > > > To: public-ws-addressing@w3.org > > > Subject: New Issue: wsaw:UsingAddressing as a policy assertion > > > > > > > > > The WSDL Binding specification defines both a WSDL extension > > > and a SOAP > > > module for indicating the use of WS-Addressing. Other WS specs that > > > Microsoft is implementing such as WS-ReliableMessaging, > > > WS-AtomicTransactions, and the various security > > > specifications all rely > > > on policy assertions to indicate the use of their respective > features. > > > In the long term, we'd like to use policy assertions consistently to > > > represent all these SOAP extensions. > > > > > > As a result, Microsoft sees a need for a policy assertion indicating > > > WS-Addressing is in use. Our preference is to use this marker as > the > > > primary flag rather than either the WSDL extension or the SOAP > module > > > even within our short-term products. > > > > > > > > In other standards groups like the OASIS WS-RX TC, the policy > > > assertions > > > are developed alongside the spec, by the same experts and on the > same > > > timeline. If we were starting WS-Addressing today, I believe we > would > > > push for a similar ownership regime within the WS-Addressing > > > WG, rather > > > than relying on external groups to define such policy assertions > after > > > the fact. > > > > > > > > Ideally, we would like to see the wsaw:UsingAddressing > > > element converted > > > to a policy assertion rather than a WSDL extension. The semantics > of > > > this assertion/extension should be virtually identical to > > > what we'd need > > > (although it's currently more complicated than we'd prefer), > > > describing > > > the engagement of Addressing, the setting of the action > > > values, and the > > > consequences on the MEPs. The main change would be to explicitly > > > describe the element as a policy extension. Some simplification > might > > > be obtained since the WS-Policy framework defines > > > wsp:Optional through a > > > mechanical transformation, reducing the amount of prose needed to > > > describe the optional behavior currently defined for > > > wsdl:required="false". > > > > > > > > Secondarily, we'd like the use as a policy assertion sanctioned as > on > > > option in the spec alongside the WSDL extension. > > > > > > > Jonathan, > > > > I am trying to understand why you are positioning this as a mutually > > exclusive decision, WS-Policy assertions vs. WS-Addressing element > > extension and speaking of a need for a conversion. > > > > As one of the editor's of the WS-RX tc, let me make the observation > that > > after all WS-Policy assertions are global elements. UsingAddressing > > element/Anonymous element (which we are currently discussing in the > wg) > > are elements as well. In my opinion, whether we call them > > UsingAddressing element vs. WSAddressingAssertion element does not > > really change the technical definition of these elements. It would be > a > > technical fallacy to present them as two separate beasts. If the > > concern is the usage SOAP module, that is a separate debate in my > > opinion. Policy assertions for a specific domain are not defined > within > > the WS-Policy namespace, they are defined within a specific domain's > > namespace. We already have that with WS-Addressing. > > > > Therefore, definition of these extensions can be easily used as Policy > > assertions. The only thing that is of concern is the expression of > > optionality as you have observed, but it seems to me that that could > be > > easily handled by careful editorial handling without derailing the > > timeline. > > > > > > > > > We recognize this request poses some timeline challenges, in > > > developing > > > a version-neutral policy assertion prior to standardization of the > > > policy framework, but feel these issues are tractable. > > > > > > > I feel that we should not position the task of the wg to define markup > > to indicate that WS-Addressing is engaged as a WS-Policy assertion vs > > WSDL extension. Then this boils down to whether your concern is more > > related to labelling the document where this element and its semantics > > is described as a WSDL binding document instead of a Policy assertion > > document. IMO, the contents would be pretty darn similar anyway, > > wouldn't they? > > > > I have illustrated, and I am sure you are well knowledgeable in this > as > > well, that using the same elements as Policy assertions is NOT really > an > > issue here. Therefore, I am trying to understand what you are really > > asking the wg to consider at this point in concrete terms. Not define > > the markup or define the markup so that there is no conflict and there > > is potential to use it with WS-Policy? ...Change the slant of the WSDL > > binding document so it is interpreted as a WSAddressing Policy > Assertion > > document and its implications when attached to WSDL? > > > > Thanks for the clarification in advance, > > > > --umit > > > > > > > > > > > > > > > > >
Attachments
- text/html attachment: wsaw..UsingAddressing as a policy assertion.htm
Received on Thursday, 5 January 2006 20:20:35 UTC