Re: Why single-interface is broken

Michael, please see inside.

On Thu, 2003-06-26 at 20:18, Michael Rowley wrote:
> 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".

I don't see how the situation is different in WSDL 1.1: a service
provides multiple interfaces, which may be seen as different aspects of
the service, and the various ports with the same interface are
alternatives for that aspect.

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

Why exactly do you want a single URI to be able to point to that? There
will always be things which are only identifiable indirectly and by
trying to assign URIs to everything we end up with complex and ugly
URIs, which kind of defies one of the purposes of URIs. Even the bloody
xpointer-like syntax in our identifiers is too much, IMO.

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

This makes the "aspect" thingy explicit *and* allows the new feature
(non-alternative endpoints with the same interface), bringing more
complexity.

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

ServiceFace, while the most awkward, seems the closest, because my term
"aspect" just doesn't convey the meaning. Anyway, I believe we don't
need the construct.

> [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.]

Everybody is welcome on the public mailing list, 's why it's public. 8-)

Best regards,

                   Jacek Kopecky

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

Received on Thursday, 10 July 2003 06:32:33 UTC