Re: Action without UsingAddressing

Marc Hadley wrote:
> An interesting thread but I think its drifted away from the original  
> question which was: if I don't include a wsa:UsingAddressing in my  WSDL 
> but I do include a wsa:Action, is the processor expected/ required to 
> (i) include addressing MAPs and (ii) honor the action  value declared in 
> the wsa:Action. IOW, is inclusion of a wsa:Action  equivalent to 
> inclusion of a wsa:UsingAddressing and if so is it  equivalent to one 
> with wsdl:required=true or false ?
> 
> Maybe I've misunderstood, but it doesn't sound like we have any  
> consensus on this yet. 

My recollection of the thread is that, it was heading towards a 
consensus. For example [.1] [.2].

[.1] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Aug/0004.html
[.2] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jul/0173.html

> Here are the options as I see them:
> 
> 1. Inclusion of wsa:Action is equivalent to inclusion of  
> wsa:UsingAddressing with wsdl:required=true (messages MUST include  wsa 
> MAPs and wsa:Action MUST be honored)
> 
> 2. Inclusion of wsa:Action is equivalent to inclusion of  
> wsa:UsingAddressing with wsdl:required=false (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 (messages MAY include wsa MAPs and if so  wsa:Action MAY 
> be honored)
> 
> 4. Something else.
> 
> I don't like 1 since it seems to circumvent wsdl:required and will  
> require special wsa aware WSDL processors. 2 and 3 seem OK, I have a  
> preference for 2.
> 

I don't like #1 either, as WSDL does not provide a way to mark an 
attribute extension as mandatory.

I'm not sure I like #2 (based on the current status of the WSDL binding).
Inclusion of wsaw:UsingAddressing with wsdl:required='false' means that 
the service supports WS-Addressing. An invoker of the service may or may 
choose to engage WS-Addressing, but if it does then the service will 
support it.
There is no such guarantee implied by a wsaw:Action. I.e., if a service 
implements a portType/interface that has wsaw:Action on its messages, 
one cannot necessarily conclude that WS-Addressing is supported by the 
service.
If we do decide to go down this path then it should be made very clear 
in the wsdl binding spec that the presence of wsaw:Action is equivalent 
to <wsaw:UsingAddressing wsdl:required='false'/>

I tend to favor #3 (except for the last 'MAY'), but would like to phrase 
it differently:
When WS-Addressing is engaged for a particular service/operation/message 
(irrespective of the value of wsaw:UsingAddressing) and wsaw:Action is 
present, all the rules around wsaw:Action MUST be followed. Inclusion of 
wsaw:Action does not affect the interpretation of wsaw:UsingAddressing. 
This implies that if wsaw:Action is present in WSDL and the 
corresponding message on the wire has wsa:Action but this wsa:Action 
does not adhere to the semantics of wsaw:Action then this is a violation 
of the spec.

> Chad anyone ?
> 

Chad to the rescue.

> Marc.
> 
> 
> On Aug 9, 2005, at 7:05 AM, paul.downey@bt.com wrote:
> 
>>
>> Paco rather sensibly said:
>>
>>
>>> The problem is essentially: is the WSDL
>>> description required to be exhaustive? I agree that the answer is  
>>> NO, but I
>>> think this is probably for the WSDL working group to clarify.
>>>
>>
>> I agree. I can't see how a WSDL document could ever be exhaustive,
>> e.g. how can I describe that my endpoint is secured using Basic  
>> Authentication
>> and your account must be in credit without resorting to the "spec  
>> which shall
>> not be named"?
>>
>> And just because we're about to provide a mechanism for describing  that
>> WS-Addressing is engaged, why should that invalidate services which
>> happen to have WSDLs that don't make use of it?
>>
>> WSDL is just a description, which can be complete or incomplete as the
>> publisher wishes it to be.
>>
>> OTOH if a WSDL explicitly stated WS-Addressing isn't in use and  then the
>> service required it, well that might be a different matter.
>>
>> Paul
>>
>>
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
>

Received on Tuesday, 9 August 2005 19:13:37 UTC