Ugo,
Agreed, <receive>s subsequent to the initiating
<receive> must use an initialized c-set.
That brings to mind the topic of engine-managed correlation. This
would render any sort of analysis of <process> declared
correlation sets useless, and the previous paragraph as well.
For example, if the underlying messaging protocol used by the
engine is ebXML MS, it could use ebXML conversation IDs or message IDs
to provide correlation to existing process instances "under the covers"
in a fashion that is invisible to the <process>. Portable? No.
Useful? Yes, since we don't need to add correlation information to the
business-level messages.
-Ron
Ugo Corda wrote:
Message
Yet
another case that just came to my mind (similar to what we have been
discussing, even though the premises are different). I have multiple
instances of the same process, and each instance was correctly
initialized with its own c-set value. Now all the instances are waiting
on the same receive which has no c-set. What happens? (I don't think we
say anything explicit right now about cases like this).
Ugo
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:
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
|