RE: Aims and Objectives

I am very much in favor of the proposed additional goals and CSFs. I think
that agent technology is the future generation of Web Services.
  Cheers, Katia

-----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 6: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 20:20:18 UTC