W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2002

Re: Aims and Objectives

From: David Booth <dbooth@w3.org>
Date: Thu, 20 Jun 2002 17:15:53 -0400
Message-Id: <>
To: Francis McCabe <fgm@fla.fujitsu.com>, www-ws-arch@w3.org

These look excellent.

At 03:59 PM 6/18/2002 -0700, Francis McCabe wrote:

>Below I present a number of additional goals and CSFs that we might like 
>to adopt.
>The motivation for these comes from our agent community; we expect 
>automatic agents to be offering web services and using web services. 
>However, I believe that these goals and CSFs are universal enough to be 
>considered in this forum. We have tried to extend the goals and CSFs found 
>in the requirements document rather than reinvent new ones.
>  Incidentally, by agent community I mean two things: FIPA (Foundation for 
> Intelligent Physical Agents) (http://www.fipa.org) and WebAgent -- a 
> loose grouping of companies including IBM, Fujitsu, Sun, HP, Mitre, 
> Intel, SAP, who are looking at agent technology in the web services area.
>Goal: Support Peer to Peer interaction using Web Services
>Why: Many business processes are not easily modeled as straightforward 
>client/server interactions; while the customer/supplier relationship is 
>still dominant, this does not imply that all (or even most) interactions 
>between them can be accurately captured using client/server architecture.
>CSF P2P.1: Web services and clients must support asynchronous event 
>notification; i.e., the supplier must be able to signal the customer of a 
>relevant event.
>CSF P2P.2: Web services must be locally discoverable: it must be possible 
>to publish a web service's description in constrained ways and to search 
>in localizable ways
>CSF P2P.3 Web services should be able to support N party interactions, as 
>in various kinds of auctions, escrow services, proxy services etc.
>CSF P2P.4 Web services must be able to support extended conversations 
>between peer web services
>CSF P2P.5 Must support volunteering of information as well as requesting 
>Goal: Service Composition
>Why: Web services are subject to the same re-use requirements as any other 
>software paradigm. This means that it is important that we can compose new 
>web services out of old ones.
>CSF Comp.1 Must be able to express the composition of services and 
>interaction patterns through XML artifacts
>CSF Comp.2 Must be able to compose services dynamically, on the fly
>CSF Comp.3 Composition model must permit the expression of and evolution 
>of composed relationships
>CSF Comp.4 Must be able to represent N party service composition (Vacation 
>= Flight+Hotel+Car Rental)
>CSF Comp.5 Must be possible for third party to certify compliance
>CSF Comp.6 Must be able to quote a conversational message inside a 
>conversational message
>CSF Comp.6.1 This may be arbitrarily deep
>CSF Comp 6.2 Must not require changing the actual quoted message
>Goal: Service Choreography
>Why: When web services are composed of the use of more than one service, 
>the order, etc of the uses of the components must be expressed
>CSF Chor.1 Permit the description of multiple steps using XML artifacts
>CSF Chor.2 Must support synchronous and asynchronous messaging
>CSF Chor.3 Must support nested and delegated choreographies
>CSF Chor.4 Must account for implicit transitions (e.g., abandoned 
>CSF Chor.5 Must support N player orchestration
>CSF Chor.6 Must support  third party verification
>CSF Chor.7 Must support volunteering of information as well as requesting 
>Goal: Semantics
>Why: It is important to be able to sufficiently describe a web service so 
>that agents can automatically decide if they want to use it. (And if you 
>have used it, whether a breach of contract has occurred)
>CSF Sem.1 Aligned with the Semantic Web (may require changes on both sides 
>of relationship)
>CSF Sem.2 publicly observable semantics (meaning of actions does not rely 
>on private agreements or on unobservable characteristics of agents)
>CSF Sem.3 Must be possible to give a semantics description of all elements 
>within a choreography or service
>CSF Sem.4 Must be possible to have an extensible description of elements 
>of a choreography or service
>Goal: Tooling support
>Why: In order to promote the effective spread of web services it is 
>important to support tool vendors in their support of applications 
>programmers developing web services
>CSF Tool.1 Permit tool vendors to support the efficient creation of web 
>services, orchestrations, semantic descriptions, compositions (and 
>evolution of same
>CSF Tool.1.1 Discourage or prohibit the use of ANY type in descriptions of 
>choreographies and services
>CSF Tool.2 Permit automatic validation of web services
>CSF Tool.2.1 Allow for automatic testing of web services and 
>choreographies, test coverage generators, document verification
>CSF Tool.3 Permit UML modeling of services, orchestrations, compositions, 
>etc. May require extensions to UML
>While this list may not be exhaustive it does address many of the `sore 
>points' that we have observed within the community.

David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Thursday, 20 June 2002 17:14:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:34 UTC