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

RE: eCommerce Choreography Use Case

From: David Orchard <dorchard@bea.com>
Date: Thu, 24 Oct 2002 16:07:24 -0700
To: "'Burdett, David'" <david.burdett@commerceone.com>, "'WS Architecture \(E-mail\)'" <www-ws-arch@w3.org>
Message-ID: <00cd01c27bb2$1e21ec50$2d0ba8c0@beasys.com>
RE: eCommerce Choreography Use CaseDavid,

Excellent observations, muchos thanks.

What if we made it such that a machine was interacting with the travel
reservation service instead of a human?  This is a great example of
converting a web site into a web service and expanding markets </marketing>

And what if the interaction between the travel service and an airline was
discovered earlier?

How about making the airline booking and/or hotel confirmation arrive from
the airline asynchronously?  Then they could arrive in various orders.

Would these changes/additions then make it sufficient to talk about
choreography?

Cheers,
Dave
  -----Original Message-----
  From: Burdett, David [mailto:david.burdett@commerceone.com]
  Sent: Thursday, October 24, 2002 2:33 PM
  To: 'David Orchard'; 'WS Architecture (E-mail)'
  Subject: 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
  >
  >
Received on Thursday, 24 October 2002 19:12:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:09 GMT