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

Re: Internal processes and/or external choreographies (was RE: Events and States ...

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 11 Apr 2003 09:56:41 -0700
Message-ID: <3E96F3C9.2090808@intalio.com>
To: Martin Chapman <martin.chapman@oracle.com>
CC: "'Burdett, David'" <david.burdett@commerceone.com>, "'Cummins, Fred A'" <fred.cummins@eds.com>, jdart@tibco.com, public-ws-chor@w3.org

I agree.

We have different opinion on how much capabilities we want in the 
language in terms of what it can describe. Some want a language that is 
only capable of expressing shared states that are general enough but 
satisfactory for most B2B use cases. Others want more capabilities that 
*in addition* to the above and not as replacement, also support more 
complex scenarios, e.g. the ones you would see in A2A or optionally 
exposing part of the white/black box.

We can go either way, but if we fail to consider the importance of the 
"glue" requirement, I have the feeling we will end up with a superb 
specification that has no practical use.


Martin Chapman wrote:

>Maybe the answer is staring us in the face:
>When we talk about external definitions we seem to be implying a shared
>state machine. There is a common understanding between all parties about
>who is playing what role, what states each role can  get into, the
>(shared) state of the process itself etc. [is this what is commonly
>called a global model?]
>On the other hand an internal defintion seems to define a state machine
>that is not shared  (tho may or may not be visible i.e. could be black
>box or white box). So what states you need, what tranistions you make,
>how you name other parties is totally private.
>Obviously the two have to be glued together at some point.
>As a group we have to decide whether we are working on shared state
>machines vs priavte ones, or both. In all case we will have to look at
>the "glue" requirements.

"Those who can, do; those who can't, make screenshots"
Received on Friday, 11 April 2003 12:58:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:00 UTC