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

Re: Action without UsingAddressing

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Tue, 09 Aug 2005 15:57:42 -0400
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Cc: paul.downey@bt.com, curbera@us.ibm.com, umit.yalcinalp@sap.com, arun.gupta@Sun.COM, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-id: <757C968D-764A-4559-9B44-402AEF4B802B@Sun.COM>
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 ?


>> 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 19:57:49 UTC

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