W3C home > Mailing lists > Public > public-ws-chor@w3.org > March 2003

Re: Web services composition

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 18 Mar 2003 10:06:33 -0800
Cc: public-ws-chor@w3.org, www-ws-arch@w3.org
To: Mark Baker <distobj@acm.org>
Message-Id: <59E87D06-596C-11D7-B616-000393A3327C@fla.fujitsu.com>

On Tuesday, March 18, 2003, at 09:39  AM, Mark Baker wrote:

> Hi Frank,
> On Sun, Mar 16, 2003 at 09:25:47PM -0800, Francis McCabe wrote:
>> According to the WS-choreography charter, and according to the WSA
>> requirements, it is stated that Web services should be recursively
>> composable.
>> However, I have to say that this goal appears to conflict with another
>> goal/property of Web services: that a Web service is identified using 
>> a
>> URI. (The URI part is not relevant to the following discussion, but 
>> the
>> identification bit is.)
> Yes, I think some of the feedback that Paul Prescod and I provided to
> choreography style solutions reflects that.  REST style composition via
> routing enabled by a layered architecture, is much more straightforward
> and doesn't have any of these problems AFAIK, as a composite service is
> identified by a URI.
> This is the value of the uniform interface, and I've yet to see any
> large scale composition occur that didn't follow this pattern, (though
> not necessarily with REST's uniform interface, but still with a generic
> interface of some sort).

This appears to miss my point completely. It has nothing to do with 
REST vs the rest.

Either you have a programmatic element that represents the composite 
service or you don't. In the former case, we are not talking about 
service composition within the framework of the architecture (since its 
a prerogative of any service provider how it delivers its services); in 
the latter we have the issues I identified.

What is needed is an extra level of indirection: separate notions of 
service and of transport endpoint; plus the description to glue them 
back together.

Received on Tuesday, 18 March 2003 13:06:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:57 UTC