RE: Action without UsingAddressing

 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Francisco Curbera
> Sent: Monday, Aug 01, 2005 6:42 AM
> To: Anish Karmarkar
> Cc: Arun Gupta; public-ws-addressing@w3.org; 
> public-ws-addressing-request@w3.org
> Subject: Re: Action without UsingAddressing
> 
> 
> I don't agree with the wsdl:required='false' analogy. That 
> only means that
> the client processing the WSDL may ignore a certain WSDL 
> extension, in this
> case wsaw:UsingAddressing. Maybe I am missing something but I 
> don't think a
> wsdl:required='false' allows the service to exhibit random 
> behavior. That
> service is promising to honor WSA for incoming WSA compliant 
> messages but
> also to accept non WSA messages.

Agreed, see below. 

> 
> As for Arun's question, my view is that a server that does 
> not include the
> wsaw:UsingAddressing marker in the binding cannot be assumed to be
> following WSA. Of course, services may have additional unpublished
> behaviors, but those are not part of the public contract so they don't
> exist from a WSDL perspective. Based on the WSDL, a client should only
> assume WSA compliance when explicitly stated in the binding.

I agree. 

However, I think Arun's question is whether we can assume that it is an
error when wsaw:UsingAddressing marker does not exist in WSDL and the
endpoint still conforms with WS-Addressing. In my email, I argued that
this should not be an error condition as the behaviour may be governed
by policies external to WSDL. Therefore, my intention is to talk about
conformance/behaviour only when the wsaw:UsingAddressing marker is
present what it means, but not to treat it as an error when the marker
is not present in WSDL. 

Namely: 
- wsaw:UsingAddressing present in WSDL (the service supports WS-A).
Follows your definition above. 

- wsaw:UsingAddressing not present in WSDL: The endpoint may or may not
support WS-Addressing depending on whether there is additional
metadata/policy that governs the endpoint. Therefore, we should not
enforce or assume conformance when it is absent. 

That is my view anyway. 

> 
> Paco
> 
> 

--umit

> 
>                                                               
>                                                               
>                    
>                       Anish Karmarkar                         
>                                                               
>                    
>                       <Anish.Karmarkar@oracle.        To:     
>   Arun Gupta <Arun.Gupta@Sun.COM>                             
>                    
>                       com>                            cc:     
>   public-ws-addressing@w3.org                                 
>                    
>                       Sent by:                        
> Subject:  Re: Action without UsingAddressing                  
>                            
>                       public-ws-addressing-req                
>                                                               
>                    
>                       uest@w3.org                             
>                                                               
>                    
>                                                               
>                                                               
>                    
>                                                               
>                                                               
>                    
>                       07/29/2005 03:32 PM                     
>                                                               
>                    
>                                                               
>                                                               
>                    
> 
> 
> 
> 
> 
> Arun Gupta wrote:
> > In that case two WSDL processors can process the same WSDL 
> differently.
> > For instance, one WSDL processor may ignore wsaw:Action and 
> the other
> > processor may use it for sending SOAP messages. Is that an 
> acceptable
> > behavior ?
> >
> 
> I would think so. The WSDL spec does not say whether attribute
> extensions are mandatory or not.
> 
> This is no different than having wsa:UsingAddressing element with a
> wsdl:required='false'. In such a case, WSDL processor A may choose to
> engage WS-Addressing and WSDL processor B may not choose to engage
> WS-Addressing. Which is fine, since the service advertised it as so.
> 
> > Since wsaw:UsingAddressing is the normative way to define 
> the intent to
> > conform to WS-Addressing, I think we need to define a consistent
> > behavior in the WSDL binding to that effect. Basically stating that
> > wsaw:Action on an operation need to be processed only if
> > wsaw:UsingAddressing exists. Is that too strong a statement ?
> >
> 
> I think it is too strong a statement. It is possible that 
> WS-Addressing
> is engaged even if wsa:UsingAddressing is not specified in 
> WSDL. One way
> this may happen is (as Umit mentions in her email) through policies.
> 
> > -Arun
> >
> > Anish Karmarkar wrote:
> >
> >>
> >> There aren't any required/mustUnderstand rules for attribute
> >> extensions (which is what wsaw:Action is) in WSDL. If 
> wsaw:Action is
> >> present without a wsaw:UsingAddressing on the corresponding
> >> binding/port then I would think it would be up to the WSDL 
> processor
> >> to decide whether it wants to ignore wsaw:Action or not 
> (in which case
> >> it will have to engage ws-addressing).
> >>
> >> -Anish
> >> --
> >>
> >> Arun Gupta wrote:
> >>
> >>>
> >>> If the WSDL does not contain wsaw:UsingAddressing in either
> >>> wsdl:binding or wsdl:port but some of the wsdl:portType/
> >>> wsdl:operation(s) contain wsaw:Action, what is the 
> expected  behavior
> >>> in such case ?
> >>>
> >>> I would expect that we ignore wsaw:Action on wsdl:operation. WSDL
> >>> Binding does not seem to say anything about such a case.
> >>>
> >>> -Arun
> >>
> >>
> >>
> >
> 
> 
> 
> 
>

Received on Monday, 1 August 2005 19:12:13 UTC