- From: Jon Dart <jdart@tibco.com>
- Date: Wed, 26 Feb 2003 14:55:08 -0800
- 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