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 <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
<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;
<mailto:david.burdett@commerceone.com;>  Web: http://www.commerceone.com
<http://www.commerceone.com>  
> 
>