- From: Assaf Arkin <arkin@intalio.com>
- Date: Wed, 26 Feb 2003 13:55:31 -0800
- To: "Jean-Jacques Dubray" <jjd@eigner.com>, "'bhaugen'" <linkage@interaccess.com>, <public-ws-chor@w3.org>
> -----Original Message----- > From: Jean-Jacques Dubray [mailto:jjd@eigner.com] > Sent: Wednesday, February 26, 2003 1:35 PM > To: 'Assaf Arkin'; 'bhaugen'; 'Jean-Jacques Dubray'; > public-ws-chor@w3.org > Subject: RE: Dubray paper comments + questions > > > > Assaf: > > >>It's the chicken and egg problem and neither spec is free of that. > [JJ] I think that we had already concluded that this is not really such > a problem. Clearly what ever is the outcome, the specification need to > allow for starting from either point of view: collaboration or > executable business process and derive the other one. I don't think it > is an issue anyways: how could we design a technology that does not > allow for that? Absolutely right. > You don't seem to speak about the third level (long-running behavior of > system components). Any thoughts on that level? 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 16:57:35 UTC