- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Fri, 4 Apr 2003 12:36:47 -0800
- To: "'Burdett, David'" <david.burdett@commerceone.com>, "'WS Choreography \(E-mail\)'" <public-ws-chor@w3.org>
- Message-ID: <004601c2fae9$e9c0b600$6501a8c0@us.oracle.com>
see below -----Original Message----- From: Burdett, David [mailto:david.burdett@commerceone.com] Sent: Friday, April 04, 2003 12:09 PM To: Martin Chapman; 'Burdett, David'; 'WS Choreography (E-mail)' Subject: RE: Abstract Bindable Choreography Martin I agree that you can represent these flows using UML, but I think that if you were to do that you would miss some of the potential benefits that are easier to get using XML. I also understand and accept that we should not include diagrammtic representations within the scope of what we do, on the other hand if you want to communicate a choreography to someone then literally, one diagram is worth a thousand words! So why do we need a formal representation of choreographies in XML? I'm not questioning a formal representation of choreographies in xml (otherwide why are we here). I question the utility of a formal representaion if one is getting too abstract. Here's my reasoning ... 1. The only reason for standardizing anything is to make interoperability easier to achieve as the information being described needs to be shared. Agreed, and interop can only actually happen if the actual types are agreed upon and documented. 2. Choreography definitions (e.g. the sequence of exchanging business documents between partners) is an example of information that MUST be shared if interoperability is to occur therefore there is benefit in having a standard representation for it. Yes but interop can only happen if the types are agreed. 3. Now we *could* agree that UML be that standard representation as an interchange format so that the information can be exchanged for example between the parties involved in eCommerce on the other hand we could use XML, so which is better? 4. To answer the question of which is better, let's think what the representations could be used for. I can think of two main reasons: a) So they can be used at design-time to make sure that you build a solution that meets the constraints implied by the choreography so how rigid are the constraints - does it include document/data types? b) So they can be used at run-time to make sure that a choreography is being correctly followed. This must be strongly typed for interop to happen. 5. At design time you need to know: a) The role you are going to play in the choreography (e.g. are you a buyer or a seller) b) The sequence in which you MUST exchange messages in order to comply with the rules of your role If a formal representation of the choreography exists, then a business process design tool could use it in some automated to check that a design is correct. and dont forget the messgae formats themselves 6. Ensuring a choreography is being correctly followed at run time is also important especially when you consider how complex a choreography can get (e.g. consider the international procurement use case I discussed on the last call). Here's the reason why: a) You can't control what the other roles in a choreography do. Therefore if they send a message out of the expected sequence, then your solution won't work. Therefore at run-time you have to check that a choreography is being followed correctly and raise errors if it is not. b) If you want to check that a choreography is being followed correctly then you need to be able to identify in a message, the choreography that is being followed as well as the specific message within the choreography that is being sent - a SOAP header would be ideal for this So really what you are doing is running a state machine that validates that the sequence of messages run in a choreography is correct. The alternative is to design all the exception handling into your business process. This makes the busines process design more complex. 6. So which should you use, UML or XML? Now UML does have an XML represenation, but it is proprietary (I think) to Rational and focuses on describing the structure of any UML document rather than the structure of a choreography. On the other hand using XML to define a choreography would provide a development environment neutral definition which is specifically designed for the purpose. It would be easier to feed into a state machine that was validating that a choreography was being correctly followed at run-time. If you doent want choreo definitions to be strognly typed to message formats then all i am saying is that i dont thinkwe need to invent anything new. By the way XMI (xml model interchange) is an OMG standard. If you do want strongly typed choreographies (whic are definitely needed for interpop) then lets do the job we were chartered to do! I get the impression that there is an easy solution to these two views tho if we have the notion of template types in schema, wsdl, and/or our langauge. Thoughts? David -----Original Message----- From: Martin Chapman [mailto:martin.chapman@oracle.com] Sent: Friday, April 04, 2003 10:12 AM To: 'Burdett, David'; 'WS Choreography (E-mail)' Subject: RE: Abstract Bindable Choreography David, I have a strong feeling that you can get what you want by exstiing technologies such as UML. In the past I have used use cases and activity diagrams to express reusable interactions between parties. Diagramtic notations are explicitly out of scope of our charter, and I'm not sure if there is any benefit in a specific xml language to express the same thing. Martin. > -----Original Message----- > From: public-ws-chor-request@w3.org > [mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David > Sent: Thursday, April 03, 2003 11:09 AM > To: WS Choreography (E-mail) > Subject: Abstract Bindable Choreography > > > There has been some discussion around the idea of an abstract > bindable choreography so I thought I would provide an example > in the form of a diagram (PDF) which shows the flow > associated with the placement of an order and an XML > representation of the same in a declarative style. I strongly > suggest you look at the diagram first. > > Comments welcome ;-) > > David > <<PlaceOrderChoreography.pdf>> > <<PlaceOrderChoreography.xml>> > > 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, 4 April 2003 15:38:15 UTC