The pattern you cited was banned in a previous message in this
thread. To reiterate, we could add the following constraint:
An initiating <receive> that does not initialize a
correlation-set must be followed (in the process graph) by an
<invoke> that does initialize a c-set, before any other
<receive> or <onMessage> activities. This must be verified
by static analysis of the <process> graph.
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 wording doesn't address the use of multiple correlation sets
properly, but is easier to understand. As in my previous message, I
wasn't trying to create text for inclusion in the spec; I was trying to
illustrate a simple idea. I'm sure we could wordsmith this all into
spec-ese, once we've settled on the ideas we want to capture.
-Ron
Ugo Corda wrote:
Message
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
|