- 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 UTC