W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2003

Re: Why single-interface is broken

From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
Date: Fri, 27 Jun 2003 15:17:57 +0200
Message-ID: <3EFC4405.8030900@crf.canon.fr>
To: Michael Rowley <mrowley@bea.com>
CC: "Amelia A. Lewis" <alewis@tibco.com>, WS Description List <www-ws-desc@w3.org>

This makes senses.

Regarding the name of the "extra" element, I don't think 
<ultimateReceiver> works, because the SOAP node that plays the role of 
the ultimateReceiver may be not be the node specified by the <endpoint> 
element, but an intermediary upstream on the message path that happens 
to like the message and feels it can play the SOAP ultimateReceiver role.

Hence I prefer your other suggestions.


Michael Rowley wrote:

> 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.
Received on Friday, 27 June 2003 09:18:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:43 UTC