RE: Proposal: Uniqueness on the Wire Requirement for WSDL 2.0

From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
Jeffrey Schlimmer wrote:


	I do not believe that WSDL 2.0 needs to be restrictive in this case because there are interesting alternatives and because any recommended alternative is arbitrarily restrictive.

I am aware that there may be alternatives. I have stated some in the mail thread that started this, my point is that disambiguating wire signatures is a problem that has been recognized and solved already by WS-I BP. 1.0. This problem must be solved in an interoperable way 
 
[jeffsch: I disagree that the problem must be solved in an interoperable way. If a service wants to have > 1 input message with the same on-the-wire signature, why would anyone else care?]
 
and we should not need yet another profile. I am very uncomfortable with the possibility of  leaving the same issues that are addressed for interoperability for WSDL 1.1 to yet another profiling exercise. 

	SOAP header blocks provide a very interesting dispatch model, and there are likely to be strong conventions around using specific header blocks for this. For example, WS-Addressing [1] defines an Action header block that is particularly suited for this purpose.

WS-Addressing was not part of our spec last time I looked ;-) 
 
[jeffsch: Agreed. However, as a WG we do not operate on a closed-world assumption. There are various pieces of important work outside the scope of the WG, and if there are interesting, viable alternatives, we should not preclude them.]

	As Paul points out, there shouldn't be any constraint on Body data; it is the application's business and should be whatever is appropriate for a given application. (Note to self: our current design may already be overly restrictive here.) 

	 

	Put another way, if a service wants to define > 1 operation/input/@Body that point to the same GED, why would anyone else care?

As a vendor  that provide tools needs to be able to dispatch and need to disambiguate an incoming message and relate it to a specific operation. 
 
[jeffsch: Fine. Your tool can enforce whatever restriction you need to on the WSDL you generate and/or consume. I claim it is possible to build tools that generate and consume WSDL without this restriction.]
 
This is a real interoperability problem as vendors need to consume WSDLs provided by services developed by other vendors tools and need to disambiguate the incoming messages. 
 
[jeffsch: Vendors need to be able to generate client proxies from WSDL generated by servers, but we both agree there is no problem on the client side. Are you concerned about the problem of being able to generate server proxies from WSDL defined by some third-party?]
 
As you probably know, a service provider can not disambiguate between operations given an input message that may be associated with two different operations as the operation doesn't appear on the wire. 
 
[jeffsch: I claim there are >> ways that a service provider can disambiguate messages to the degree that it needs to, and since the WSDL is written from the point of view of the service, it is up to the service to ensure this property to the degree needed.]
 
By having this restriction, an interface is associated with a service, hence an endpoint would be able to distinguish the incoming messages. 

Our position is that this must be solved in an interoperable way and leaving this to specifications or specific vendor implementations are not acceptable as one vendors choice of disambiguating may not be supported by another unless it is part of the standard. Hence, one vendor will not be aware of headers or addressing choices which will solve this problem. This is a real issue for interoperability. 
 
[jeffsch: This is not a problem for tools that generate client proxies. It may be an implementation issue for tools that generate server stubs from WSDL specified by a third-party, but the assumptions of specific implementations should not be baked into a long-range specification like WSDL 2.0.]

If you would like to propose alternative ways of tackling this issue within the context of the WSD wg, I am all ears. However, not solving this problem is unacceptable. There is a solution that is already published by WS-I and we should use it. 

[jeffsch: This is not an interoperability problem. And it does not need to be solved by this WG.]