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

Re: single interface/service

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 10 Jul 2003 12:53:26 -0400
To: jdart@tibco.com
Cc: www-ws-desc@w3.org
Message-ID: <OF77F14631.A8C3F266-ON85256D5F.005B44BE-85256D5F.005CC8B3@us.ibm.com>

"Jon Dart" <jdart@tibco.com> wrote on 07/10/2003 12:35:20 PM:

> Christopher B Ferris wrote:
> > Anne's example of the UBR as a resource with multiple endpoints, each
> > managed by a different authority is a perfect example of why it is not
> > always possible to achieve this manner of association using 
> > 
> Apologies, I haven't seen this example. If you need to associate 
> multiple endpoints from different WSDLs, then I can see why you'd choose 

> a linking mechanism. But the use case is not clear to me.

see http://lists.w3.org/Archives/Public/www-ws-arch/2003Jul/0054.html

> > 
> >>logically, containment, not linking, is what is being modelled here.
> > 
> > 
> > How do you come to that conclusion? It is neither about linking nor 
> > containment. It is about *association*. 
> To be clearer, my point was there's logically a single containing 
> entity. You can call it a resource or a service or something else. But 
> it's 1 parent -> multiple children. Not some other multiplicity (in UML 
> speak).

I just don't see it that way at all. 

> > Let's not get all wound up over names. We can always assign it a more
> > intuitive name if that is of concern to some. We can call it "Thing_1"
> > for now;-)
> Indeed the name can be changed. But I think there's also some confusion 
> about what the name signifies.

`When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it 
means just what I choose it to mean -- neither more nor less.' 


> --Jon


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
Received on Thursday, 10 July 2003 12:53:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:25 GMT