Re: Two logical WSDL documents describing the same service

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

Received on Thursday, 18 December 2003 10:20:40 UTC