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

I believe that Jeffrey has stated this very well.  WSDL certainly does
*not* need constraints on how a service may be defined, and as he has
here clearly stated, the lack of a single defined means for recognizing
an operation from its wire format is a problem for *service*, not
*client* (fsvo "client") code.  While it may be correct to demand that
WSDL insure that generated clients be able to determine a signature
unambiguously, I agree that it is incorrect to require all services to
be generated so straitly.

Amy!
On Fri, 24 Oct 2003 17:56:59 -0700
Jeffrey Schlimmer <jeffsch@windows.microsoft.com> wrote:

> 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.]
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 27 October 2003 10:16:17 UTC