RE: eCommerce Choreography Use Case

David

Firstly, I'm suggesting the eCommerce is an additional use case and not a
replacement for the travel reservation use case as it illustrates a number
of additional ways in which web services could be used. These are described
below:

PEER-TO-PEER MULTI-PARTY COMMUNICATION
In the travel reservation service, the user always interacts via the travel
service from a form. This very much like a web client-server relationship
and means that the user does not need to know anything about how the travel
service interacts with the airlines and the payment service. In the
eCommerce example, each participant (buyer, seller, shipper) is an equal
peer of each other and has to know the complete process so that they can
correctly interact.

EXTERNALLY DEFINED CHOREOGRAPHY
In the travel reservation service, there is a requirement for the travel
service to discover how to interact with the airlines and with the payment
service. It then handles each interaction dynamically depending on ontology
definitions that allow it to do the mapping of the content of the messages.
In the eCommerce example, the choreography (i.e. sequence of exchanging
messages) has been defined by a separate third party that all the three
participants recognize they must conform to and which they HAVE to build
into their implementations.

CHOREOGRAPHY REUSE
The eCommerce example is simplified as it does not include the generation of
errors nor the compensating message flows and processes which must be
excecuted to handle them. Therefore a complete choreography would actually
contain many more steps. Because of this complexity there is a lot of
benefit in reusing the same standardized choreography with many buyers,
sellers and shippers in order to reduce implementation costs. EDI has done
this in the past by publishing implementation guides that describe the
inter-party choreographies as text. Implementations that use languages such
as BPEL or WSCI will need to be constrained so that they can both recognize
which choreography they are following and adapt their behavior accordingly.

THE CHOREOGRAPHY IS INDEPENDENT OF THE MESSAGE CONTENT
The content of each message varies depending on the context in which it is
used, for example if the choreography is being used nationally, then no
customs documents are required. At a lower level the content of individual
documents can change for example an order placed in the chemical industry
could have additional chemical hazard information on it. This means that the
individual schemas will be different. However, the actual sequence of
messages and their basic meaning does not change. So the eCommerce example
describes a need for defining a choreography that is independent of the
detail of the content of each message. This could also have an impact on
service definition, as if, for example, there is a slightly different
definition for each order docment depending on industry, it could mean that
each participant (buyer, seller, shipper) would have to define separate WSDL
definitions. Thoughts?

PARALLEL PROCESSING
The travel reservation service follows a linear process. The main
parallelism is (I think) in searching for flights and hotels, for example.
In the eCommerce example, activities can occur in different time orders
(e.g. sending the booking confirmation and sending the order response) as
they are generated by different organizations.

EDI RELATED
This process flow is modelled closely on actual EDI process flows which will
be one of the main uses for Web Services. Therefore including a fairly
complex realistic EDI example is a good idea.

I'd appreciate your thoughts David.

Regards

David

-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Thursday, October 24, 2002 10:46 AM
To: 'Burdett, David'; 'WS Architecture (E-mail)'
Subject: RE: eCommerce Choreography Use Case


David,

This looks like an interesting use case.  But I don't understand the
motivation for it.  How does the travel reservation service not provide for
requirements determination?

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Burdett, David
> Sent: Wednesday, October 23, 2002 6:28 PM
> To: WS Architecture (E-mail)
> Subject: eCommerce Choreography Use Case
>
>
> Folks
>
> I promised to draft a set of requirements for choreography
> definitions. The
> first step is to prepare a use case and, as the requirements
> are taking me
> longer than I would have hoped, I thought you might like to
> see just the use
> case first.
>
> The use case describes an international eCommerce transaction
> involving a
> Korean electronics supplier, a US manufacturer and an
> air-freight company.
> It basically covers the ordering and delivery of goods using
> a SOAP based
> exchange of XML documents.
>
> Details are in the attached PDF file.
>
> Comments are welcome.
>
> Regards
>
> David
>  <<eCommerce Use Case.pdf>>
>
> Director, Product Management, Web Services
> Commerce One
> 4440 Rosewood Drive, Pleasanton, CA 94588, USA
> Tel/VMail: +1 (925) 520 4422; Cell: +1 (925) 216 7704
> mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com
>
>