W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

RE: Abstract Bindable Choreography

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


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




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


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 


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC