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

Aims and Objectives

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Tue, 18 Jun 2002 15:59:02 -0700
To: www-ws-arch@w3.org
Message-Id: <FBA96BE0-830E-11D6-967A-000393A3327C@fla.fujitsu.com>

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 action

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.
Received on Tuesday, 18 June 2002 18:59:09 UTC

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