Re: Action without UsingAddressing

Marc Hadley wrote:
> Comments below.
> 
> On Aug 9, 2005, at 3:13 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 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.
>>
> 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.

HTH.

-Anish
--

> 
> Marc.
> 
>>
>>> 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.
>>
>>
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
> 
>

Received on Tuesday, 9 August 2005 21:41:17 UTC