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

Re: single interface/service (was: Minutes, 3 July 2003 WSDesc telcon)

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 10 Jul 2003 07:33:57 -0400
To: www-ws-desc@w3.org
Message-ID: <OF2E618C33.C157EC54-ON85256D5F.003B86CB-85256D5F.003F88BF@us.ibm.com>

Jon Dart wrote on 07/09/2003 05:41:17 PM:

> Jonathan Marsh wrote:
> > Consensus favors single interface for service!
> > * jeffm the crowd cheers
> > * sanjiva wonders whether we'll be back to square one on the list as 
> >           today appears to be a lightly attended call
> Amy Lewis was unfortunately not on this call, but as you know, she's 
> been pretty vocal in opposition to this.
> I agree with her arguments, which in brief are these:
> 1. it isn't really simpler to link services via a targetResource 
> identifier, it is more complex than using XML containment. And in fact, 

I am certain that I do not agree with this position. There are many 
where it is simply not possible to lump all of the endpoints for a given
service (regardless of whether they are the same interface or not) in the
same WSDL document.

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

> logically, containment, not linking, is what is being modelled here.

How do you come to that conclusion? It is neither about linking nor about
containment. It is about *association*. A service *optionally* identifies
a resource (by its URI) that is somehow associated with the service. The 
authority that publishes the service determines the semantics of the
nature of the association or whether to bother to identify a resource
at all.

Consider that there are many, many documents that describe me: my dental
records, my medical history, by social security record, my employee 
etc. Each of these documents is associated with me by virtue of my name.
There is not one uber-document that describes me in total.

This concept has been around for centuries and up until now, people have 
not had
a hard time comprehending its utility.

> 2. "targetResource" is an unintutive name for the linking concept (if 
> not for everyone, then for many people).

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

> See also Frank McCabe's recent comments in WSA:
> http://lists.w3.org/Archives/Public/www-ws-arch/2003Jul/0045.html
> and a longer discussion in
> http://www.w3.org/2002/ws/arch/3/05/2003-05-29-ws-arch.htm
> (which reveals IMO that even a savvy group of people were confused
> by targetResource).

Hmmm... I know many equally savvy people who are equally confused about 
<service> containing multiple <ports> that are bound to different 
Quite frankly, I think that the inertia argument for leaving service with
multiple interfaces is uncompelling.

> FYI Web service composition has been a recent topic of discussion in 
> WS-Choreography, see:
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0030.html
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0031.html
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0033.html
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0034.html
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0035.html
> http://lists.w3.org/Archives/Public/public-ws-chor/2003Jul/0039.html

It is not at all clear to me what this has to do with service composition
and it is definitely not about choreography.

> But IMO a major function of a choreography description is to model the 
> pattern of data flows that connect multiple participants together.
> It doesn't replace the static grouping that WSDL provides. I think 
> choreography is solving a different set of problems (despite some of the 

> above referenced messages that seem to suggest otherwise).

I would certainly hope so.

> --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 08:42:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:31 UTC