Re: Action without UsingAddressing

Marc Hadley wrote:
> On Aug 9, 2005, at 5:41 PM, Anish Karmarkar wrote:
> 
>>>>
>>>>> 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 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.
>>>>
>>>>
>>> That sounds just like my #2 above - what am I missing ?
>>>
>>
>> #2 says that the presence of wsaw:Action is equivalent to the  
>> presence of <wsaw:UsingAddressing wsdl:required='false'/> (when  such 
>> a marker is absent). This means that the service does support  
>> WS-Addressing, but WS-Addressing is not required.
>>
>> Whereas what I'm stating above (as a reinterpretation of #3) is  that 
>> the presence of wsaw:Action does not necessarily mean that the  
>> service supports WS-Addressing.
>>
> I'm still a bit confused, why would the WSDL have a wsa:Action in it  if 
> the service doesn't support WS-Addr ?
> 

To override the default action rules when a service implementing the 
interface/portType does support WS-Addressing.

Consider the case where the 'abstract' part of the WSDL is written by 
someone else. A WSDL containing the service element imports that WSDL 
and implements the abstract part. Since wsaw:Action is on the 
input/output of an operation (the 'abstract' WSDL), is the service 
required to support WS-Addressing?

There are two possible cases here:
1) The abstract WSDL was written to allow services that support WS-Addr 
as well as services that do not support WS-Addr. For services that 
support WS-Addr, wsaw:Action is introduced to override the default 
action rules (because the default, for whatever reason, is not 
suitable). Therefore the presence of wsaw:Action does not require the 
service to necessarily support WS-Addr.
2) wsaw:Action was included to do two things: (a) override the default 
action rules, and (b) to say that ws-addressing must be supported.

Based on the current status of the WSDL binding, wsaw:Action is meant to 
override the default action rules and not overridden to mean 
<wsaw:UsingAddressing wsdl:required='false'/>. In fact, in section '3.1 
UsingAddressing Extension Element,' we specifically allow this element 
to appear only on the binding element or the port/endpoint element. We 
further go on to say in section '3.2 WSDL SOAP Module':
"Note that this module is not meaningful when used on WSDL constructs 
where wsaw:UsingAddressing is not allowed."

Given this, I prefer to not overload wsaw:Action to mean 
<wsaw:UsingAddressing wsdl:required='false'/>. This also allow the 
flexibility to override the default action rules without requiring that 
WS-Addr be supported.
But to be clear, I'm not opposed to overloading wsaw:Action as long as 
we make the overloading explicit in section 4 (as well as modify section 
3.1 and 3.2).

Hope that makes it clearer.

-Anish
--

Received on Wednesday, 10 August 2005 18:47:29 UTC