RE: Multiple endpoints with the same interface

> -----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