- From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Date: Fri, 27 Jun 2003 15:17:57 +0200
- 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. Jean-Jacques. 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