- 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