- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 10 Aug 2005 13:07:18 -0700
- 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 verbose. <Changing-topics-slightly> 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? </Changing-topics-slightly> -Anish -- > 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