Re: Two logical WSDL documents describing the same service

David, I totally agree with Amy here.

Let me try to reformulate what I was trying to say before in a shorter
form:

WSDL is not a totally self-contained language, it expects that its
components (especially services, probably interfaces) will be used by
the outside world. To allow this, WSDL introduces the 'name' on its
components, with properties very similar to those of a URI:

As a single URI unambiguously (as far as possible) identifies a resource
within a world (usually the internet, but there may be different views
of it from different intranets and various closed systems - different
worlds), a QName used as a name unambiguously identifies one thing
within one symbol space. Sadly, we're stuck with multiple symbol spaces
of QNames for now.

A resource (identified by a URI or two) can certainly have multiple
facets. It can be a union of multiple things, too. If two resources are
numbers, I can add them. If one of them is a union of two numbers, I
cannot add them (in the traditional meaning of addition) any more. If I
want to take the "first number" facet of the resource, this must be
identified differently from the sole resource's URI.

With QNames the symbol space dictates the meaning of a QName. The WSDL
Service symbol space says at the moment that each QName in this space
has exactly one interface (by reference to a QName from the WSDL
Interface symbol space). The WSDL language gets to define what its
symbol spaces mean and no external system may change it if it claims to
be WSDL-compliant. A thing with multiple interfaces cannot be referred
to by a symbol from the WSDL Service symbol space.

A system can define its symbol space of things that can, in fact, have
multiple interfaces. But things in this space cannot consist of multiple
references to different instances with the same QName in the WSDL
Service symbol space, because logically, there never is more than one
instance with one name in that space. So far, all this is implied by the
WSDL language using the attribute 'name' of the type QName and saying
that there are several symbol spaces for the several WSDL component
types.

There is one notable exception where these nice rules are broken -
versioning, i.e. a change in the definition of one symbol, with multiple
versions coexisting in one system. This causes problems and if we want
to say anything on this topic, we may formulate a warning that caution
must be exercised when designing and running such systems. This is by no
means a neutral statement.

Hope I made myself clearer,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/



On Fri, 2004-01-09 at 18:58, Amelia A Lewis wrote:
> On Jan 9, 2004, at 12:06 PM, David Booth wrote:
> > Does that help clarify what I meant?
> 
> Yes.  But you won't like my response, I suspect.
> 
> Acknowledging that the WSDL 2+3 hack may be necessary is effectively 
> equivalent to suggesting that single-interface per service is broken.  
> Which, of course, is my position.

[snip]

> In short: the WSD WG and the current WSDL specification are not 
> currently "neutral" on the issue of the WSDL 2+3 hack.  The 
> specification, by requiring a single interface per service, offers that 
> as a guideline (perhaps one could argue it is a guarantee?) to 
> languages building on top of it.  An indication in the tutorial which 
> is tantamount to "oh, we didn't really mean it; here's a workaround 
> that allows you to use the name of the service as a means of relating 
> disparate interfaces to one another" is effectively undermining the 
> single-interface per service requirement.  Any processor which may have 
> to deal with more than one WSDL at a time must, in effect, ignore the 
> single-interface per service requirement.  OR it must implement that 
> restriction.  By pointing out how it is possible to work around the 
> restriction, we are effectively encouraging the creation of two 
> mutually non-interoperable domains for service descriptions.  In one 
> domain, single-interface per service is checked only within a single 
> WSDL (and its imports).  It is, in short, useless for the purpose which 
> I understood it to be created: to allow service discovery and 
> categorization.  In the other, it remains useful for service discovery, 
> because when a service attempts to register itself with multiple 
> interfaces by the mechanism of splitting itself into multiple 
> deployment WSDLs, it is rejected (in fact, interop in this area is 
> further fragmented, because some are likely to drop the service 
> altogether for invalidity, while others will refuse to accept the 
> second registry, and still others will regard the second registry as 
> replacing the first).

[snip]

Received on Tuesday, 13 January 2004 10:49:12 UTC