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

Re: Dubray paper comments + questions

From: Jon Dart <jdart@tibco.com>
Date: Wed, 26 Feb 2003 14:55:08 -0800
Message-ID: <3E5D45CC.1040802@tibco.com>
To: Assaf Arkin <arkin@intalio.com>
Cc: public-ws-chor@w3.org

I think a lot of this may be necessary, but (to revisit an earlier issue 
raised on the list) I'm not sure that the requirements for choreography 
necessitate a full-blown workflow modelling language. In fact, I have 
some concern that the existing proposals may be overly complex for 
modelling useful types of WS interaction (especially in a B2B context), 
while being less than adequate for more general worklow purposes, in 
which not everything is directly in service of a WS message exchange. 
Which is why the proposal to separate specification of message flow from 
control flow was attractive, at least IMO.

--Jon

Assaf Arkin wrote:

> 
> I do assume that we're talking about long-running behavior all along which
> explains a lot of the complexity of the spec.
> 
> In a long-running behavior you would have complex flows that are chained to
> each other. You can capture a simple flow with something like a sequence,
> but that doesn't extend well. You will probably want to break the complex
> flow into smaller flows and chain them together, which is where we introduce
> spawn and call*.
> 
> In a long-running behavior you would also have flows that repeat multiple
> times within some state and that may be subject to how many messages are
> exchanged (or in reverse, capture the message exchange), which explains the
> need for nested processes.
> 
> And of course you need to address the time issue, whether you want to
> express a minimal passage of time (e.g. delay) or put a time constraint on
> the completion of a flow (e.g. onTimeout).
> 
> And probably some other requirements. Anything specific?
> 
> arkin
> 
> * The notion of recursive composition which is captured in this way and also
> with nested processes is very interesting, since it allows you to draw
> conclusions about a fine grained entities, then about a composition
> including multiple entities, and a composition including multiple
> compositions, and so forth. Seeing how formal process models do it, we've
> structured the language in a similar manner to allow the same form of
> recursive composition/analysis.
> 
> 
> 
>>JJ-
>>
>>
>>
>>
>>
> 
> 
> 
> 
Received on Wednesday, 26 February 2003 17:59:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC