Re: Aims and Objectives

There are multiple levels at work here:

one-way messaging,  (or fire and forget method invocation) is one thing, 
being notified of an event is at a slightly higher level and 
volunteering is at an even higher level.

We have a couple of core use cases:

1. The traditional business cycle:
   a. place order
   b. receive goods, along with delivery note
   c. receive invoice
   d. receive statement -- noting that a statement may cover more than 
one invoice
  e. send money, along with remittance advice -- noting that a given 
payment may cover more than one invoice, or just part of an invoice or 
some combination

Only the first step in this sequence can be reasonably modeled as a 
traditional client/server HTTP/GET kind of activity. All the other steps 
are somewhat asynchronous and typically extend over many weeks.

(Have you noticed that when you buy something over the web, only the 
first part is done `on-line', the rest is handled via email and snail 
mail? There is a message here for all those who think that apache can 
take over all business functions)

2. The car rental scenario:
   a. How can I help you?
   b. I'd like to hire a car
   c. When, where, etc
   d. Denver, next week
       Do you have a convertible?
   e. For an extra $10/day
   f.  BTW since you're going to Denver, perhaps you'd like a ski 
package; we have a special today
   g. I have a special upgrade coupon I'd like to use
   etc. etc. (Incidentally, that last step might take place when actually 
picking up the car)

Again, you cannot do this using conventional API-style modes of 
interaction since its pretty unlikely that the customer exposes a method 
for ski packages!

Frank McCabe





On Tuesday, June 18, 2002, at 10:16  PM, Mark Hapner wrote:

>
> 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 12:03:46 UTC