|
Ron,
I don't think
your wording would be sufficient. It does not say anything about the case
of non-initiating receive's without correlation sets (which, according to your
previous note, should not be allowed when the initiating receive has no
correlation set).
It also would allow
the following sequence:
initiating receive
with no correlation set
...
receive
initiate="yes"
...
receive
initiate="no"
...
which does not make
much sense.
Ugo
Ugo,
I would phrase this as
follows:
Before a correlation set is "used" (that
is, initiate = "no") in a process graph, it must be "initialized" (that is,
initiate = "yes") . This must be verified by static analysis of the
process.
This is similar to our rules about
initialization of variables before they are used. I have avoided using
<receive> in this, because csets can be initialized in other activities
in the process.
-Ron
Ugo Corda wrote:
Ron,
Let me see if I
correctly understand what you are proposing. You are saying that, whenever a
process has an initial <receive> with no correlation set, the only
other receive's allowed in that process are those that have an associated
correlation set, and which also are preceded at run-time (in a way
determinable by static analysis) by an activity (other than receive - e.g.
invoke) that initiates the value of that correlation set. All other
receive's (e.g. receive's with no correlation set, or receive's whose
temporal relationship with correlation set initialization activities can
only be determined at run-time) are not allowed.
Is that a
correct interpretation of your proposal?
Thank
you,
Ugo
Ugo,
I think what you
are describing is an indeterminant process, caused by the concurrency
introduced by the flow. A static analysis could reveal
this.
<receive>
<flow>
<receive><cset
initiate = "yes">
<receive><cset initiate = "no">
As
you pointed out, if this wasn't found by static analysis, a run-time error
could occur, if the receives were executed in the wrong
order.
-Ron
|