Re: Alternatives for resolving subissue 1 in issue i017

Chris,

You raise a good point about the fact that there are usecases which do 
not lend themselves well to option 1. I would be perfectly happy to 
resolve this issue with option 2 and specify the extensibility 
point/feature as required by the WSDL 2.0 operation name mapping.

I do have a question. You said:

 > For instance, the WS-RM specification says that in the absence of a
 > specified wsa:Action, that
 > a message carrying a wsrmSequenceAcknowledgement SOAP header block
 >have a particular
 > wsa:Action value.

Given that we are talking about what happens if there is a WSDL 
specified (this particular issue) and there are default rules for the 
[action] property (specified by the WS-Addressing WSDL mappings), it 
will always be the case (in this particular scenario) that the [action] 
property is always specified (implicitly or explicitly). So, the rules 
specifieed by WS-RM will never kick-in. Isn't it?
Or did I get the scenario wrong?

Thx!

-Anish
--

Christopher B Ferris wrote:
> Anish,
> 
> As you know, the WS-I BP1.x constrains that the "wire sgnature" of a given 
> WSDL input message be unique
> within the scope of a WSDL portType/interface (the "wire signature being 
> the QName of the child
> element of the soap:Body). I argued at the time that we were discussing 
> the issue that I thought
> it would be a mistake to impose such a constraint, that one could have 
> metadata carried as
> SOAP header blocks (such as the wsa:Action) that could be used by the 
> service to determine
> what action to take, etc. That the contents of the soap:Body might not be 
> the sole determinant
> for dispatching a received message. I lost that argument, although I still 
> believe it to have been a 
> mistake.
> 
> I see this issue as a repeat of the discussions we had in the WS-I BPWG 
> regarding the uniqueness
> of the "wire signature".
> 
> Just as a service could use SOAP header block metadata to augment the 
> contents of the 
> soap:Body for purposes of dispatching the received message, so too could 
> the contents of the 
> soap:Body, or other SOAP header block metadata, also be used by the 
> service as it sees fit
> to augment the wsa:Action as a determinant for dispatching/servicing the 
> message.
> 
> Furthermore, in a WSDL1.1 context, a service can have multiple ports, each 
> binding a possibly
> different portType. Theoretically, they could all have the same 
> soap:location URI. Hence, it seems
> to me that imposing a constraint that the wsa:Action URI for a given 
> message be unique for a given 
> portType/interface is meaningless because the same wsa:Action could be 
> used across the
> various portTypes.
> 
> For instance, the WS-RM specification says that in the absence of a 
> specified wsa:Action, that 
> a message carrying a wsrmSequenceAcknowledgement SOAP header block have a 
> particular
> wsa:Action value. Let's just say that I designed my interface such that 
> there was an input message
> and a void response, and that the wsrm:SequenceAcknowledgement header 
> blocks would be
> carried on the response message (which had no soap:Body child element). 
> Each operation would
> then have an output message with the same wsa:Action URI value. Seems 
> reasonable to me, yet 
> option 1 would preclude me from doing so. The requirement that wsa:Action 
> be unique within the
> scope of a portType/interface seems arbitrary.
> 
> I think that the question that needs to be answered is: What value does 
> imposing such a constraint
> add? 
> 
> Cheers,
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://webpages.charter.net/chrisfer/blog.html
> phone: +1 508 377 9295
> 
> public-ws-addressing-request@w3.org wrote on 01/10/2005 01:33:21 PM:
> 
> 
>>Here are the alternatives for resolving subissue 1 in issue i017 [1] -- 
>>I took an action for doing this during last week's call:
>>
>>The subissue is about whether the value of the [action] property is 
>>required to be distinct within the scope of WSDL portType/interface when 
> 
> 
>>using WSDL to describe the Web service
>>
>>Please note that this is an issue only when using WSDL to describe the 
>>service and therefore potentially affects only the WSDL binding spec and 
> 
> 
>>not the core or the SOAP binding.
>>
>>Alternative 1:
>>
>>yes, it is required to be distinct within the scope of a WSDL 
>>portType/Interface. The spec currently states:
>>"An identifier that uniquely (and opaquely) identifies the semantics 
>>implied by this message."
>>If the values are not distinct within the portType/interface then one 
>>has to wonder as to why there are two distinct operations within the 
>>portType/interface that have the same semantics? More accurately, the 
>>scope should not really be the portType/interface but should also 
>>include the directionality of the message, similar to the operation name 
> 
> 
>>mapping requirement of WSDL 2.0 [2]. An added advantage of this is that, 
> 
> 
>>the value of the [action] property now can be used to figure out which 
>>WSDL-operation is being "invoked" by an incoming message at the service 
>>(since operation-names do not manifest themselves on the wire) -- when 
>>it is not clear from the contents of the SOAP Body. This has been an 
>>interop problem in the past which led to WS-I Basic Profile 1.0/1.1 
>>requirement R2710 [3][4].
>>
>>Alternative 2:
>>
>>no, it is not required to be distinct within the scope of a WSDL 
>>portType/interface. There might be reasons for allowing non-distinct 
>>values <insert-use-case-here>. WSDL interface/operations that do satisfy 
> 
> 
>>the distinctness requirement can use the WSDL feature or WSDL 
>>extensibility described in [5] (or something similar).
>>
>>[I don't think I'm doing justice to alternative 2 as I haven't come 
>>across a good usecase for this. If you do have one, please send it to 
>>the list]
>>
>>Thx!
>>
>>-Anish
>>--
>>
>>[1] 
>>
> 
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0004.html
> 
>>[2] 
> 
> http://www.w3.org/TR/2004/WD-wsdl20-20040803/#Interface_OperationName
> 
>>[3] http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#R2710
>>[4] http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#R2710
>>[5] 
>>
> 
> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/att-0010/00-part
> 
>>
>>
> 
>

Received on Monday, 17 January 2005 00:14:07 UTC