Ron,
Good point. I think
it really depends on how hidden the correlationID is in the case of
engine-managed correlation. If the correlationID is only visible, say, at
the transport level, there is of course no chance of static analysis. But what
if, for instance, the correlationID is declared at the WSDL level (and qualified
as such - so I am more thinking in terms of WSDL 2.0). Wouldn't it be something
equivalent to the current c-sets?
Ugo
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:
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
|