- From: Jeffrey Schlimmer <jeffsch@windows.microsoft.com>
- Date: Thu, 17 Apr 2003 11:25:13 -0700
- To: "David Orchard" <dorchard@bea.com>, "Kenneth Chiu" <chiuk@cs.indiana.edu>, <www-ws-desc@w3.org>
> From: David Orchard [mailto:dorchard@bea.com] > > If I understand the CCA requirement, they would like to differentiate > between ports that are semantically equivalent versus not equivalent > whithin a single service. This leads me to 2 questions: > > 1. If two ports are semantically equivalent, is there any way of talking > about the single thing that they represent? It seems to me that there is > no way of saying what the thing is, nor expressing equivalence of the > endpoints for the singe thing. In WS-ReliableMessaging, this "thing" is > called the ultimate receiver or the initial sender. Each may have > multiple endpoints that are equivalent as they represent the ultimate > receiver or initial sender. > > 2. Is it possible to express that equivalence of porttypes also depends > upon which service they are part of? The problem that I see is that > sometimes it's not just the porttypes that determine equivalence, it is > service + porttype. I could have 2 equivalent port types, but when used > in different services they aren't equivalent. Are you suggesting that whether two wsdl:endpoints (nee wsdl:ports) are semantically equivalent is orthogonal to whether they are defined within the same wsdl:service? > I think these are separate issues, maybe I'm mistaken. Though it does > seem, again maybe naively, that they could be satisfied with roughly one > construct. Something like > <service name="Purchasing"> > <ultimateReceiver name="AcceptPO"> > <endpoint binding="AcceptPOSoapbinding"> > ...</endpoint> > <endpoint binding="AcceptPOsomeotherbinding"> > ....</endpoint> > <endpoint name="unrelatedendpoint' binding="..."> > ....</endpoint> > </service> Did you mean to close the ultimateReceiver element to indicate which endpoints were equivalent? > Then CCA could put endpoints that represent the same ultimate receiver in > one construct, and put endpoints that don't represent the same ultimate > receiver yet have the same interface in one service. I'm sure there's > more that could be done about expressing the identity of the ultimate > receiver and other things, but this gives a rough outline. > > I don't know if this has been talked about. If it has, I'd appreciate any > pointers. The general issue was discussed at one of the face-to-face meetings last year, perhaps as early as the Paris meeting. As I recall, given two workarounds, the sentiment of the WG was that the status quo was sufficient.
Received on Thursday, 17 April 2003 14:25:24 UTC