RE: [i061] WSA WSDL Binding Issue (Action without UsingAddressing)

I have an action to synthesize these options into a single proposal.
First some analysis.

My assumptions are:
1) Using WSDL 2.0 as a guide, an attribute extension alone cannot cause
required changes in messages.
2) Other mechanisms may be in use to indicate that addressing is in use
than <wsaw:UsingAddressing> (e.g. a policy assertion or an extension for
another protocol which profiles WSA headers); such mechanisms could
conceivably define actions inconsistent with wsaw:Action attributes
though that doesn't seem wise.
3) Clients and services can put in any old headers they want.
4) Headers marked mustUnderstand, but not indicated as required in the
contract, might cause faults.

The interaction of WSDL, the WS-A WSDL spec, SOAP, and the contract
including (but not limited to) a particular WSDL, lead to three overall
scenarios:

WSDL includes <wsaw:UsingAddressing wsdl:required="true"/>.
  Client MUST (according to WS-A WSDL spec) insert actions as defined 
  by wsaw:Action and the defaulting mechanism in this spec.  Failure 
  to do so MUST (according to WS-A WSDL spec) be reported by an error.
  mustUnderstand can be set or not, but the server MUST NOT (according 
  to the contract) generate a mustUnderstand error on these headers.  
  A message coming from the service MAY (according to SOAP) contain wsa
  headers, these headers MAY (according to SOAP) be marked as 
  mustUnderstand, and MUST (according to WS-A WSDL spec) use the values 
  defined by wsaw:Action and the defaulting mechanism.

WSDL includes <wsaw:UsingAddressing wsdl:required="false"/>.
  Client MAY (according to WS-A WSDL spec) insert actions as defined 
  by wsaw:Action and the defaulting mechanism in this spec. 
  mustUnderstand can be set or not, but the server MUST NOT (according 
  to the contract) generate a mustUnderstand error on these headers.  
  A message coming from the service MAY (according to SOAP) contain
  wsa headers, these headers MUST NOT (according to the contract) be
  marked as mustUnderstand, but MUST (according to WS-A WSDL spec) use 
  the values defined by wsaw:Action and the defaulting mechanism.

WSDL omits <wsaw:UsingAddressing/>.
  The client MAY (according to SOAP) add any old headers it wants, 
  including wsa headers, using wsaw:Action and the defaulting mechanism 
  or not.  mustUnderstand MAY (according to SOAP) be set or not, but the

  server MAY (according to SOAP) generate a mustUnderstand error on 
  these headers.  A message coming from the service MAY (according to 
  SOAP) contain wsa headers, these headers MAY (according to the 
  contract) be marked as mustUnderstand, and MAY use the values 
  defined by wsaw:Action and the defaulting mechanism.  A client
  receiving headers marked mustUnderstand MAY (according to SOAP)
  generate a mustUnderstand error.

The last case illustrates why wsa:Action has no normative effect outside
the context of wsaw:UsingAddressing.  I believe option 3 is the only one
that has this property, so I'll simply expand on the text of 3 a bit.

3': Inclusion of wsaw:Action without inclusion of wsaw:UsingAddressing
is purely advisory. In other words, a client MAY include wsa MAPs in
messages it sends to the service, either on the clients own initiative
or as described elsewhere in the service contract.  It MAY use the
values of wsaw:Action in these headers.  Additional mechanisms defining
the value of [action] are under no constraint from this spec to be
consistent with wsaw:Action.

I don't know whether 3 implies any change to the text of the spec, or if
it's clear enough as it is.


> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-
> addressing-request@w3.org] On Behalf Of Arun Gupta
> Sent: Thursday, August 11, 2005 4:06 PM
> To: W3C WS-Addressing Public List
> Subject: WSA WSDL Binding Issue (Action without UsingAddressing)
> 
> 
> If the WSDL does not include wsaw:UsingAddressing in either
> wsdl:binding
> or wsdl:port but one or more wsdl:portType/wsdl:operation contain
> wsaw:Action, the expected behavior in such a case is unclear. Here are
> the six possible options:
> 
> 1. Inclusion of wsa:Action without inclusion of wsa:UsingAddressing is
> equivalent to inclusion of wsa:UsingAddressing with
> wsdl:required=true.
> IOW, messages MUST include wsa MAPs and wsa:Action MUST be honored.
> 
> 2. Inclusion of wsa:Action without inclusion of wsa:UsingAddressing is
> equivalent to inclusion of wsa:UsingAddressing with
> wsdl:required=false.
> IOW, messages MAY include wsa MAPs but if so wsa:Action MUST be
> honored.
> 
> 3. Inclusion of wsa:Action without inclusion of wsa:UsingAddressing is
> purely advisory. IOW, messages MAY include wsa MAPs and if so
> wsa:Action
> MAY be honored.
> 
> 4. Inclusion of wsa:Action without inclusion of wsa:UsingAddressing is
> purely advisory. IOW, the messages MAY include wsa MAPs and if so
> wsa:Action MUST be honored.
> 
> 5. Inclusion of wsa:Action without inclusion of wsa:UsingAddressing is
> equivalent gets ignored. IOW, messages MUST not include wsa MAPs.
> 
> 6. Something else
> 
> In 3 and 4, other information is needed to determine whether
> WS-Addressing is supported.
> 
> The spec needs to provide a clear guidance on what needs to happen in
> such a case. 2 or 3 seems ok and I have a preference for 2.
> 
> -Arun
> 
> --
> got Web Services ?
> Download Java Web Services Developer Pack from
> http://java.sun.com/webservices
>

Received on Friday, 2 September 2005 23:21:25 UTC