- From: David Orchard <dorchard@bea.com>
- Date: Wed, 23 Apr 2003 16:14:45 -0700
- To: "'Jeffrey Schlimmer'" <jeffsch@windows.microsoft.com>, "'Kenneth Chiu'" <chiuk@cs.indiana.edu>, <www-ws-desc@w3.org>
- Message-ID: <013c01c309ee$2198bbf0$fffa000a@beasys.com>
> -----Original Message----- > From: Jeffrey Schlimmer [mailto:jeffsch@windows.microsoft.com] > Sent: Thursday, April 17, 2003 11:25 AM > To: David Orchard; Kenneth Chiu; www-ws-desc@w3.org > Subject: RE: Multiple endpoints with the same interface > > > > 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? > Maybe I'm confused, but I thought that is the case. > > 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? Yeah, sorry about that. Should have closed it between the 2nd and 3rd endpoint. <service name="Purchasing"> <ultimateReceiver name="AcceptPO"> <endpoint binding="AcceptPOSoapbinding"> ...</endpoint> <endpoint binding="AcceptPOsomeotherbinding"> ....</endpoint> </ultimateReceiver> <endpoint name="unrelatedendpoint' binding="..."> ....</endpoint> </service> > > > 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. hmm, any particular reason that you (or somebody else) would care to articulate? Was there a lack of a compelling use case? Or it became too complex? I took a gander at the minutes of the paris f2f [1]. I saw the discussion that you mentioned about the ambiguity of whether same interface and differing bindings is 1 service or 2, which I think is right on the mark. I further followed into the Alexandria F2F and saw the service-type proposal - I still like having the address as a firstclass concept - and saw the vote to accept service types. But then I lost the trail :-( Cheers, Dave [1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0208.html
Received on Wednesday, 23 April 2003 19:12:20 UTC