Re: Why single-interface is broken

I believe a single interface per service was chosen as the best among 
several options for solving an important problem with WSDL 1.1, which is 
the following sentence from section 2.7:

"If a service has several ports that share a port type, but employ 
different bindings or addresses, the ports are alternatives."

There is, unfortunately, no name for the thing that they are 
alternatives for.  It is important that this thing be named, so that it 
can be referenced. At my urging, David Orchard brought this up in this 
group earlier and proposed several solutions.  The single interface per 
service restriction has the effect that the things that they are 
alternatives for can be named, and the name is: "service".

The use-case is very straight forward.  Suppose you would like to 
separate the service provided from the mechanism used to communicate 
with the service (which I believe is a goal of WSDL).  Client software 
then needs to be able to refer to something that is specific to a single 
service instance, has a single interface, but does not specify the binding.

Without the single interface restriction, it is not possible to specify 
such a thing with a single URI.  You can specify the service by 
something like:
    http://mydomain.com/mywsdl#service(foo),
And you can specify the interface with:
    http://mydomain.com/mywsdl#interface(bar),
but you cannot, with a single URI, refer to something that specifies 
"any endpoint that presents the bar interface to service foo".

An alternative solution to the single-interface restriction would be to 
introduce an extra level between <service> and <endpoint>.  David 
Orchard proposed using the term <ultimateReceiver> for this.  So a 
service element might look like this:

<service name="Purchasing">
   <ultimateReceiver name="AcceptPO" interface="AcceptPOInterface">
     <endpoint binding="AcceptPOSoapbinding">
	 ...
     </endpoint>
      <endpoint binding="AcceptPOsomeotherbinding">
	....
      </endpoint>
   <ultimateReceiver name="checkStatus" interface="StatusCheckInterface">
      <endpoint name="checkStatusEndpoint' binding="...">
         ....
      </endpoint>
</service>

Then it is possible to refer to some meaningful thing, independent of 
binding, with a URI like: 
http://mydomain.com/mywsdl#ultimateReceiver(bar).  Note with this 
explicit extra level it then becomes possible to have two endpoints that 
present the same interface but are explicitly _not_ alternatives to one 
another.

I'm not sure "ultimateReceiver" is the right term.  Perhaps 
"serviceFace" or "destination" would be better.

[I've been following this issue for months, but only recently heard that 
I might be allowed to contribute, even though I'm not a member of the 
working group.]

Michael Rowley


Amelia A. Lewis wrote:

>Okay.
>
>Single interface per service is proposed as a "simplification" (the term
>was used repeatedly).  It's the only argument that I can recall in favor
>of this.
>
>I suggest that it is not a simplification.  By introducing redundancy,
>it introduces errors.  By introducing errors, without specifying how
>these errors are to be handled, it reduces interoperability.
>
>Example:
>
><interface name="A" />
>
><interface name="B" />
>
><binding name="Aimpl" implements="A" />
>
><binding name="Bimpl" implement="B" />
>
><service name="aService"> <!-- first error -->
>  <endPoint binding="Aimpl" />
>  <endPoint binding="Bimpl" /> <!-- one of the foregoing two lines is
>the second error -->
></service>
>
>Legal and reasonable in WSDL 1.1, apart from the changes of element and
>attribute names.
>
>Illegal in WSDL 1.2.  The lack of specification of the interface
>implemented by the service is an error.  Will it be flagged?  Imagine
>that this WSDL is created stepwise.  First, interface A, binding Aimpl,
>and endPoint A were all created; a validation tool may have noted the
>lack of an interface specification on the service, but perhaps offered
>only a warning (or perhaps not even that) to the author.  Later,
>additional functionality was added, using a different network paradigm
>that could not be adequately supported by the existing binding; a second
>interface, implementation, and endpoint were added.
>
>A non-WSDL-validating tool will not note the errors at all.  A WSDL
>validating tool will note the first error, and then probably decide that
>endpoint Bimpl is illegal.  If interface="B" is added to the service,
>then it will instead decide that endpoint Aimpl is illegal.  The
>harassed and frustrated developer splits them into separate services,
>and removes the interface again (if there's only one endpoint in a
>service, you can be certain that there will be tools that do not enforce
>the user to declare the interface at the service level).  Same harassed
>developer looks at @targetResource, says "Huh?  WTF is that?  A resource
>is associated with an endpoint, in any rational web-aware world, what's
>this weirdness?" and goes on.  The WSDL works again, sort of, after all.
>
>Redundancy is *bad*.  Specifying interface twice is *bad*.  If it's
>going to happen at all, error-handling MUST be specified in sufficient
>detail that two processors faced with the same description report the
>same thing.
>
>Amy!
>  
>

Received on Thursday, 26 June 2003 14:18:52 UTC