- 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