Re: Two logical WSDL documents describing the same service

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.

I think that we have a responsibility, in designing WSDL, to keep in 
mind the requirements of languages that are going to use WSDL as a 
building block.  In fact, I believe that most of the arguments for 
single-interface per service were of precisely this category.

Given single-interface per service, a web services registry/catalog API 
can have expect to create certain APIs (note that I'm being broader 
than UDDI/ebXML registry here, because I know of at least one other 
product that can act in this function, and because I am doubtful that 
either of those high-profile APIs are particularly mature, at this 
point).

In the following, I'm going to use type(qname) syntax to indicate WSDL 
components.  So, interface(foo:bar) indicates the interface with 
attribute bar in a WSDL with a targetNamespace attribute associated 
with prefix foo.  Otherwise, I'm going to use a rather chatty 
pseudocode format.

User: give me service(*:*) implementing interface(foo:bar).  API is 
designed to return a list/collection/array, since this is known to be 
likely to have multiple hits.

Registry: joe:service, fred:service, erik:service

User: [chooses fred:service, based on some heuristic or at random] give 
me endpoints for service(joe:service).  Again, the API expects and thus 
permits multiple returns (you can guess where I'm going with this 
already, no?).

Registry: endpointA location=http://fred/service, endpointB 
location=http://fred/service/mgt

User: [has an oddity to cope with: service shows two endpoints on a 
single server, which is odd, but maybe doesn't notice, and has (some 
percentage) chance of choosing endpointB] constructs message for 
interface(foo:bar) and sends it to endpointB.

Service: fault: operation not supported

User: Huh?

Suppose that this becomes widespread.  The API is already frozen, so we 
can't supply a parameter to the registry in our endpoint request (give 
me endpoints for service(joe:service) implementing interface(foo:bar)). 
  So the user tries to verify before use.

User: give me interface(*:*) implemented by service(joe:service)

Registry (option 1): fault: invalid state.  This happens if the 
registry permits multiple registries, but is trained to return a single 
interface when asked what interface a service implements.

Registry (option 2): foo:bar, foo:baz.  This happens after reports of 
problems.  The registry adjusts the API to return a list.  If this can 
happen, though, then the registry API can change to allow an interface 
parameter to be passed together with the request for endpoints.  In 
other words, the registry ignores the WSDL requirement that each 
service implement a single interface.

Registry (option 3): fault: no service(joe:service) known.  This 
happens after reports of problems with option 1, when the registry 
decides to do validation of attempted registries.  It now detects the 
conflict, and following the direction indicated in the WSDL 
specification, it does not permit a single service to implement 
multiple interfaces.

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).

If other groups (did this solution originate in the architecture 
group?) need a way of associating endpoints implementing different 
interfaces with one another, because their conception of a service 
permits multiple interfaces, then we need to either question our 
restriction, or we need to introduce a means of creating this 
association.

<association>
   <serviceReference name="qname" role="qname" />{2,}
</association>

association might need to have a name attribute as well; it effectively 
becomes the equivalent of a WSDL 1.1 service (or the wider conception 
of a web service that includes endpoints implementing multiple 
interfaces).  This would permit the single interface restriction to 
remain, while creating a means for developers to say "these things go 
together, okay?"  (the role attribute is questionable, actually; where 
is it defined?  But maybe it wouldn't be necessary?)

Amy!

Received on Friday, 9 January 2004 13:00:25 UTC