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

RE: Aims and Objectives

From: David Orchard <dorchard@bea.com>
Date: Tue, 18 Jun 2002 16:12:05 -0700
To: <www-ws-arch@w3.org>
Message-ID: <012301c2171d$906b5980$6d0ba8c0@beasys.com>

While I totally agree with the csfs, but I think they are actually
requirements, not csfs.  I suggest making them all requirements.


> -----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

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