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

What concerns me here is the lack of consistency between the current
resolution of this issue (do nothing) versus that of the "one interface per
service" issue. In your reply to Paul you correctly wrote Jeff that "there
is nothing preventing a WSDL author from adopting the unique QED approach
today". But the same thing can be said about there being nothing preventing
a WSDL author from using only one interface in a given service. And yet this
group felt the need to impose this restriction on the WSDL author. Why the
difference? I think we should be consistent (and I am in favor of us taking
the least prescriptive approach on both).
 
Regards,
 
William

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Jeffrey Schlimmer
Sent: Friday, October 24, 2003 5:57 PM
To: Umit Yalcinalp
Cc: WS Description List
Subject: 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.]