W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2006

RE: New Issue: wsaw:UsingAddressing as a policy assertion

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Thu, 5 Jan 2006 12:20:12 -0800
Message-ID: <37D0366A39A9044286B2783EB4C3C4E8012AABB9@RED-MSG-10.redmond.corp.microsoft.com>
To: <public-ws-addressing@w3.org>
[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

> >

> >

> >

> >

> >

> > >

> > >

> 

 




Received on Thursday, 5 January 2006 20:20:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:11 GMT