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

While I agree with you, I'm certain that WS-I will define a constraint that 
wire signatures must be unique.

Anne

At 10:16 AM 10/27/2003, 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.
>
>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 14:29:54 UTC