Re: Two logical WSDL documents describing the same service

Amy,

I agree that a system stupid enough to suck down random WSDL documents and 
be unable to function when it sees two logical WSDL documents that define 
the same service would have a problem, but I don't think that's a problem 
the WSDL language can or should address.  Any system that needs to suck 
down random WSDL documents should either:

(a) Have some way to say "Hey, I already have a definition for that 
service.  You're not allow to have more than one in my system, so one of 
them must be bogus.  Which one is correct?"

(b) Say "I understand versioning, so one of these must be a newer version", 
and if they look compatible, then accept them.  If they don't look 
compatible (i.e., incompatible interface signatures), then reject one or 
both of them.

(c) Say "Hmm, these interfaces look incompatible.  Since I know from other 
sources that they're both legitimate, they must be defining multiple facets 
of the same service.  That's cool, I know how to deal with that."

But again, this is outside of our responsibility to define.

At 10:18 AM 12/18/2003 -0500, Amelia A Lewis wrote:
>Summary response: disagree.
>
> >From the point of view of a catalog or register, the distinguishing
>characteristic of a service description is its namespace.  As each new
>namespace is encountered, it is added to a cache, map, registry, etc.
>which provides access to the service description by its namespace.
>
>Redefining the same namespace results in a clash.  If a
>catalog/registry/whatsit user says "what's this namespace http://joe?"
>expecting a single answer, the registry/catalog/whatsit either picks one
>(which may be the wrong one), or provides some sort of error that
>indicates "more than one exists".  This leaves the requester expected to
>disambiguate the result, at best, and at worst leaves the requester with
>a 50% chance of receiving the wrong description.
>
>WSD WG probably can't mandate that each namespace be unique (although
>that's a pretty clear expectation for namespaces, on the whole, when no
>recommendation is made as to how to "combine" different documents that
>define the same namespace), since we deal with a single description at a
>time.  Possibly a registry/catalog/baz API/description/recommendation
>could clarify this.  But, given that the only available identifier is
>now considered to be an incomplete identifier, it would be nice to know
>what sort of other data should be used to disambiguate.
>
>Amy!
>(in late-breaking news, I consider the single-interface restriction on
>services to be a broken design; many will be *shocked* to learn of this,
>I'm certain)
>On Wed, 17 Dec 2003 22:22:59 -0500
>David Booth <dbooth@w3.org> wrote:
>
> >
> > At the last WS Architecture F2F meeting, a question arose about
> > whether the WSDL 2.0 specification has anything to say about a single
> > service being described by two different WSDL documents.  I took an
> > action to write to the WSD WG to ask.
> >
> > The question arose in the context of discussing WS Management: A
> > single service wishes to expose a functional interface for its regular
> > users, but it also wishes to expose a management interface.  Since a
> > Web service description (WSD) in WSDL 2.0 is not allowed to specify
> > more than one wsdl:interface, one obvious approach would be to write
> > two WSDL documents that define different interfaces -- a functional
> > interface and a management interface -- but that specify exactly the
> > same targetNamespace and service name, so they are describing the same
> > service.  In fact, they might even specify the same endpoint address.
> >
> > This problem may sound familiar, because it's exactly the problem that
> > the proposed @targetResource attribute was intended to address.   But
> > in this case it skips the additional attribute.
> >
> > At present, our Part1 document says that you cannot have two
> > interfaces for the same service.  HOWEVER, my understanding of the
> > context of that is that it pertains only to a *single* logical WSDL
> > document[1] -- not multiple logical WSDL documents.  (By "logical WSDL
> > document" I mean the infoset or WSDL components obtained from a single
> > WSDL document and any of its includes, imports, etc.  See [1] if
> > you're unclear about what I mean .)  Since this issue of single versus
> > multiple logical WSDL documents[1] has only recently been raised, I
> > don't think we've addressed the question of multiple logical WSDL
> > documents describing the same service in this context.
> >
> > My own reasoning about this is as follows.
> > 1. The WSDL 2.0 spec should only define the meaning of any *single*
> > valid sentence in the language, i.e., only any *single* logical WSDL
> > document. 2. Therefore, the WSDL 2.0 spec should have nothing to say
> > about the meaning or validity of two logical WSDL documents (each
> > independently valid) when considered together.
> > 3. In the Web in general, it is entirely normal to have multiple
> > documents that describe the same resource.  Each such document may add
> > to your knowledge of that resource.  Furthermore, following an "open
> > world assumption", you should never assume that you know *everything*
> > about a particular resource.  The idea of having two WSDL documents
> > that describe the same resource seems entirely consistent with this
> > view. 4. Therefore, I see nothing wrong with using two logical WSDL
> > documents to describe the same service, even if those documents
> > specify different interfaces.  If someone wants to create a
> > PrinterService whose PrintDocument interface is defined in one WSDL
> > document, but whose ManagePrinter interface is defined in another WSDL
> > document, they are free to do so.
> >
> > Do others agree with this analysis?
> >
> >
> > 1. http://lists.w3.org/Archives/Public/www-ws-desc/2003Nov/0085.html
> >
> >
> >
> > --
> > David Booth
> > W3C Fellow / Hewlett-Packard
> > Telephone: +1.617.253.1273
> >
>
>
>--
>Amelia A. Lewis
>Architect, TIBCO/Extensibility, Inc.
>alewis@tibco.com

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Thursday, 8 January 2004 10:28:27 UTC