Re: Alternatives for resolving subissue 1 in issue i017

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, 10 January 2005 19:22:51 UTC