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

RE: Dubray paper comments + questions

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?


* 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

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