- From: David Orchard <dorchard@bea.com>
- Date: Thu, 24 Oct 2002 22:48:33 -0700
- To: "'Burdett, David'" <david.burdett@commerceone.com>, "'WS Architecture \(E-mail\)'" <www-ws-arch@w3.org>
- Message-ID: <00e901c27bea$289b5f30$2d0ba8c0@beasys.com>
RE: eCommerce Choreography Use CaseDavid,
I think that you are looking for a different type of choreography than I am.
I think you want a template or class of choreography, and then various nodes
can be instances of that. Your requirement seems to be: "In order to reduce
costs, a set of interactions (aka choreography) must be re-usable.
Individual nodes only have to instanciate and publish information related to
their instance of the re-usable choreography (ie publish a URI). "
I also think you are introducing a few new glossary terms that i'll take a
stab at:
choreography template - a reusable abstract template for a choreography.
choreography instance - a realization of a choreography template, typically
with location information published.
Let's noodle on this a bit more. Seems like WS-Coordination is a type of
choreography template as well.
I'm also not in favour of adding new use cases. To be honest, if the travel
use case isn't good enough for choreography, I want to drop the travel case
completely. Given that wsci, wsfl, etc. used travel scenarios, I find it
difficult to believe that a travel scenario isn't useful. Hence why I want
to morph the travel case into whatever is necessary.
Cheers,
Dave
-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Thursday, October 24, 2002 7:18 PM
To: 'David Orchard'; 'WS Architecture (E-mail)'
Subject: RE: eCommerce Choreography Use Case
David
Firstly, my response to your initial email did not make it to the WS
Architecture list so if anyone want's to understand what David is commenting
on, the original text is below.
Comments on your comments are inline below, but on a general point, is
there a problem with adding in a new use case and associated requirements at
this stage? I am also thinking on suggesting another use case that focuses
on service oriented composition. Thoughts?
David
-----Original Message-----
From: David Orchard [mailto:dorchard@bea.com]
Sent: Thursday, October 24, 2002 4:07 PM
To: 'Burdett, David'; 'WS Architecture (E-mail)'
Subject: RE: eCommerce Choreography Use Case
David,
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>
[David Burdett] That still wouldn't make it a peer-to-peer communication
where each participant new the complete choreography involving multiple
participants. To do that you would have to change the choreography of the
travel reservation service.
And what if the interaction between the travel service and an airline
was discovered earlier?
[David Burdett] The interactions in the travel reservation service are
all peer to peer, what we really need is a more complex set of interactions
where each participant independently recongizes that they need to follow the
same choreography and so that they only need to discover the urls for
message delivery before they can start exchanging information as they have
pre-programmed their business process engines to comply with the
pre-specified choreography. I don't see how your suggestion would help.
How about making the airline booking and/or hotel confirmation arrive
from the airline asynchronously? Then they could arrive in various orders.
[David Burdett] That would help, but you would be sychronizing
essentially the same type of message.
Would these changes/additions then make it sufficient to talk about
choreography?
[David Burdett] Don't think so since it still wouldn't I think reflect
all of the different requirements that the eCommerce use case suggests.
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 Friday, 25 October 2002 01:53:28 UTC