RE: Abstract Bindable Choreography

 Martin

Apologies for the delay in responding but I have had a hard disk corruption
which prevents my laptop from booting. Anyway detailed responses below.

David

-----Original Message-----
From: Martin Chapman
To: 'Burdett, David'; 'WS Choreography (E-mail)'
Sent: 4/4/2003 12:36 PM
Subject: RE: Abstract Bindable Choreography

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. 
<DB>Also agreed.</DB>

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? 
<DB>Yes, but see later ...</DB>

  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. 
<DB>Also agreed, but see later ...</DB>

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 
<DB>... I haven't ...</DB>

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!
<DB>I agree totally, the question is how do we do it. I *think* that you are
suggesting one specification that describe a choreography definition that
contains, in one definition, both the message sequencing AND strongly typed
definitions of what goes in each message. 

If you define a choreography to include both of these then a change to
either means you HAVE to define a new choreography. So, for example, if you
change a message definition to include a customs declaration or change an
order format to include shoe sizes because it's in the footwear industry,
then you would HAVE to create a new choreography definition even if the
sequence of the messages had not changed - or am I missing something.

Now this might be OK if the number of different message formats that you
could get was limited, but it's not because of various legal and industry
requirements - predict there will be thousands.

On the other hand if you separate the choreography definition into two
parts:
a) an abstract definition of the sequence of the messages, and
b) the detailed strongly typed content of the messages that can be bound to
the abstract definition
... then you can change the latter without changing the former. I think this
is a *good idea* as it will result in far fewer choreography definitions and
much greater reuse.
</DB>
 

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