- From: David Orchard <dorchard@bea.com>
- Date: Tue, 18 Jun 2002 16:12:05 -0700
- To: <www-ws-arch@w3.org>
While I totally agree with the csfs, but I think they are actually requirements, not csfs. I suggest making them all requirements. Cheers, Dave > -----Original Message----- > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On > Behalf Of Francis McCabe > Sent: Tuesday, June 18, 2002 3:59 PM > To: www-ws-arch@w3.org > Subject: Aims and Objectives > > > > 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. > >
Received on Tuesday, 18 June 2002 19:12:00 UTC