W3C home > Mailing lists > Public > www-ws-desc@w3.org > April 2003

RE: Multiple endpoints with the same interface

From: Kenneth Chiu <chiuk@cs.indiana.edu>
Date: Thu, 24 Apr 2003 14:50:28 -0500 (EST)
To: David Orchard <dorchard@bea.com>
cc: www-ws-desc@w3.org
Message-ID: <Pine.GSO.4.53.0304241409090.4613@mishrak.extreme.indiana.edu>

On Wed, 16 Apr 2003, David Orchard wrote:
> 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.

I'm not sure I completely follow this.  I mainly just want
to know if I have missed some new thinking.  I agree that
with the spec the way it is now, there would be no way to
differentiate between ports that are different "paths" to
the same "thing", and ports that are fundamentally different

Perhaps a concrete example can clarify this.  Suppose there
is a remotely-operated electron microscope with two guns,
but only one specimen stage.  A natural CCA component for
this microscope might have two CCA ports of the same type
for the two guns, and one CCA port for the stage.

But it seems that this cannot be cleanly mapped directly to
WSDL.  If we use 1.1, the two ports of the same portType are
"semantically equivalent", so presumably control the same
physical mechanism.  With 1.2, I think there are also
problems, but the exact nature will depend on whether or not
one service is allowed to implement multiple interfaces.

So the solution is to make services more fine-grained, and treat
the notion of "port" a bit differently.  Each CCA port is
mapped to a separate WSDL service.

The 1.1 terminology just confused the issue, of course.  I
think renaming WSDL portType to interface will make the
CCA -> WSDL mapping seem more natural.

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

I suppose this would be possible.  But I think port type
equivalence is okay.  It's ports where we have had to make a
decision that might not seem that natural at first.

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

Yes, we could probably do something like this.  But I think
we would prefer to keep the extensions to a minimum.
Ideally, the mapped WSDL service(s) should be the same as what
a WSDL expert would have designed were she presented the
fundamental problem without any knowledge of the CCA design.

> I don't know if this has been talked about.  If it has, I'd appreciate any
> pointers.
> Cheers,
> Dave
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> > Behalf Of Jeffrey Schlimmer
> > Sent: Wednesday, April 16, 2003 1:18 PM
> > To: Kenneth Chiu; www-ws-desc@w3.org
> > Subject: RE: Multiple endpoints with the same interface
> >
> >
> >
> > The WG explicitly decided to keep the status quo from WSDL 1.1. As you
> > note, you can work around this with multiple services.
> >
> > Alternatively, you may be interested in the solution to R085 and/or
> > R131:
> >
> > R085: The description language SHOULD allow describing Messages that
> > include references (URIs) to typed referents, both values and
> > Services.
> > (From PP. Last discussed 11 April, 2002.)
> >
> > R131: The WG SHOULD define components that may be used within Messages
> > to refer to other WSDL components. (From DO. See also R085 and R120.
> > Last discussed 6 Feb 2003.)
> >
> > http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/requirements/
> ws-desc-re
> qs.html (ed copy)
> A recent thread on this latter point begins at
> http://lists.w3.org/Archives/Public/www-ws-desc/2003Apr/0035.html.
> --Jeff
> > -----Original Message-----
> > From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
> On
> > Behalf Of Kenneth Chiu
> > Sent: Tuesday, April 15, 2003 10:27 PM
> > To: www-ws-desc@w3.org
> >
> >
> > We are working on a mapping from the U.S. Dept. of Energy
> > Common Component Architecture (CCA) to WSDL.  CCA components
> > may have multiple ports of the same type, each representing
> > a different "instance".
> >
> > Because WSDL 1.1 stated that multiple ports of the same
> > portType provide "semantically equivalent behavior" we have
> > been mapping each CCA port to a separate service.
> >
> > What is the current thinking for 1.2?  The latest draft
> > doesn't seem to have any guidance on the semantics of
> > multiple endpoints of the same interface in one service.
> >
> > Kenneth Chiu
> > Indiana University
Received on Thursday, 24 April 2003 15:50:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:54:42 UTC