W3C home > Mailing lists > Public > public-ws-addressing@w3.org > August 2005

Re: Action without UsingAddressing

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Wed, 10 Aug 2005 13:07:18 -0700
Message-ID: <42FA5E76.8050906@oracle.com>
To: Marc Hadley <Marc.Hadley@Sun.COM>
CC: paul.downey@bt.com, Francisco Paco Curbera <curbera@us.ibm.com>, Umit Yalcinalp <umit.yalcinalp@sap.com>, Arun Gupta <arun.gupta@Sun.COM>, public-ws-addressing@w3.org

Marc Hadley wrote:
> I see, so we do have an option 4 which I would characterize as:
> 4. Inclusion of wsa:Action without inclusion of wsa:UsingAddressing  is 
> purely advisory, other information is needed to determine whether  
> WS-Addressing is supported. If messages include WS-A MAPs then the  
> wsa:Action MUST be honored.
> I wonder if we should consider changing the target of wsa:Action to  be 
> the binding rather than the abstract port type/interface to  simplify 
> the logic here ? Seems like use of addressing is a binding  level thing 
> so why allow addressing properties to be specified on the  abstract 
> constructs.

This would work well for WSDL 1.1 where the binding is tightly coupled 
with the portType and one has to specify things related to input/output 
in the binding anyway.

But for WSDL 2.0, this would tie the binding to the interface (and 
therefore not reusable for other interfaces) and make bindings more 

BTW, I know we had an issue and agreed on making UsingAddressing a 
binding/port/endpoint thing and don't want to reopen that issue, but 
given the extensibility in MAPs, why is UsingAddressing a 
binding/endpoint/port specific thing rather than 
binding/endpoint/port/portType/interface specific thing?


> Marc.
> On Aug 10, 2005, at 2:47 PM, Anish Karmarkar wrote:
>> 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
>> -- 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Business Alliances, CTO Office, Sun Microsystems.
Received on Wednesday, 10 August 2005 20:07:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:10 UTC