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

RE: Correlation Requirements

From: Burdett, David <david.burdett@commerceone.com>
Date: Thu, 21 Aug 2003 11:37:47 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1D57@c1plenaexm07-b.commerceone.com>
To: 'Assaf Arkin' <arkin@intalio.com>, "Burdett, David" <david.burdett@commerceone.com>
Cc: Keith Swenson <KSwenson@fsw.fujitsu.com>, 'Monica Martin' <monica.martin@sun.com>, 'Martin Chapman' <martin.chapman@oracle.com>, 'Yves Lafon' <ylafon@w3.org>, jdart@tibco.com, 'Ugo Corda' <UCorda@seebeyond.com>, 'Cummins Fred A' <fred.cummins@eds.com>, public-ws-chor@w3.org

Assaf said ...

>>>Are you saying that a choreography would select one of two alternative
flows based on this state, or that there are two different choreographies,
depending on which type of order is being sent?<<<

It all depends, for example I can think of three ways of solving this
problem all of which could be appropriate depending on the circumstances.

1. IT's A BUSINESS PROCESS
You could imagine a business process (i.e. it's under the control of a
single entity) that decides independently which of two choreographies to
use. In this case, the decision would probably be part of a BPEL or some
other process-oriented language and not in the choreography

2. IT's A COMPOSED CHOREOGRAPHY
In this case you have two separate choreographies one for
"export-restricted" and one for "non-export restricted" orders. These
separately defined choreographies are then referenced by a third higher
level choreography that uses "choreography composition" to combine them.

3. IT's ONE BIG CHOREOGRAPHY
This is similar to the second example above, except that all the
interactions in the choreoraphy are in one single choreography definition so
there is no referencing of separately defined choreographies.

Which style you use is a choreography design decision that depends on such
things as:
a) Whether all the parties involved need to know about combined choreography
or can treat them as separate. If they don't then you can do the BPEL
approach, if they do, then you need to do have one big choreography of
compose two choreographies.
b) The degree of commonality between the choreographies, if they are
similar, then you might want to do one big choreography to avoid the
duplication.
c) Whether or not there are some pre-existing choreographies that you can
just reuse. If they already exist then a composed choreography could be the
way to go.

As in all design decisions, there is rarely one right way of doing things
that applies to all situations ...

Hope this helps

David
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Wednesday, August 20, 2003 4:49 PM
To: Burdett, David
Cc: Keith Swenson; 'Monica Martin'; 'Martin Chapman'; 'Yves Lafon';
jdart@tibco.com; 'Ugo Corda'; 'Cummins Fred A'; public-ws-chor@w3.org
Subject: Re: Correlation Requirements


Burdett, David wrote:

>Assaf
>
>You said ...
>
>  
>
>>>>You have very specific structures like RN vs OAG and you want to avoid
>>>>        
>>>>
>dependency on those so as to allow multiple over-the-wire formats (as you
>discuss below). But there's also the content model or information structure
>that is important to convey. If you send me some message that is
>semantically a PO, that's not very helpful if I can't find some line items,
>billing address, etc in there.<<<
>
>I totally agree. But I would separate this problem into three parts:
>1. Define the relevant states - by specifying in the choreography, *what*
>"states" are relevant. For example the fact that an order contained goods
>that had export restrictions, might have a substantive effect on the flow
of
>the choreography. In this case, the state "ExportRestrictedOrder", or
>something like it, would need to be defined.
>
Are you saying that a choreography would select one of two alternative 
flows based on this state, or that there are two different 
choreographies, depending on which type of order is being sent?

arkin

>2. Determine document formats compatible with the choreography. For
example,
>there will be rules that uses information about an order and the parties
>involved to determine whether or not it is export restricted. This means
>that, before you can use a particular choreography, you need to make sure
>that the order document format (or information derivable from eleswhere
>using data in the document) contains the required information. Once you
have
>done that analysis, you can specify which choreographies can be used which
>document formats.
>3. Define the choreography binding. Finally, once you have identified
>compatible combinations of document format and choreography, you can build
>an implementation and specify exactly which choreography, document formats,
>message formats, security, RM protocol, etc. as well as the services you
are
>going to use. You can also bind the state, e.g. "ExportRestrictedOrder" to
>an executable set of conditions that allows the value of the state to be
>determined for any order instance. At this point, you are specifying the
>"how".
>
>David
>  
>
Received on Saturday, 23 August 2003 08:56:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:27 GMT