- From: David Booth <dbooth@w3.org>
- Date: Thu, 20 Jun 2002 17:15:53 -0400
- 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 >action > >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 >conversations) >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. -- David Booth W3C Fellow / Hewlett-Packard Telephone: +1.617.253.1273
Received on Thursday, 20 June 2002 17:14:31 UTC