Re: Aims and Objectives

Francis,

You use the terms event, notification, and message to refer to forms of one way
communication between producers and consumers. Are these just different uses for
messaging or are they different service models?

It is clear that 'volunteering' as used here is meant to capture some special
form of producer consumer interaction that goes beyond messaging and RPC. Is it
some form of publish/subscribe paradigm?

A basic element of composition on the web is a resource. Is composition of web
service resources covered in your composition goal? 

Given the current design of Soap 1.2, I don't believe it is possible for the
response of one service to be be constructed as a service request/message so it
is not clear how to create a pipe like composition of services without writing
code. Is this an example of what you mean by service composition?

-- Mark

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.

Received on Wednesday, 19 June 2002 01:16:34 UTC