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

Amelia A. Lewis wrote:

>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.
>  
>
I am baffled as to why you think it is not a problem for the client. 
Lets take on of these examples, shall we? If my service requires a 
specific header to make this distinction and my tools that know about 
this introduce this little secret souce as a header, I would have 
clients built with my tools to nicely contact my service. This does not 
mean that the client did not need to understand or *not be aware* of the 
service's requirement, it is just that my clients were built with this 
specific tool that introduced service's requirement on the wire for 
them. Hmm.

In other words, are we saying that interoperability is not a problem of 
WSDL?

What an interesting idea.

--umit

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

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com