An initial
(createInstance) receive
without correlation will in most cases be followed by a reply – in
other
words, it will be a service operation that creates an instance and
returns
(among other things) tokens for future interactions. A following
invoke
instead of reply is possible but less common IMHO, the problem being
that the
originator of the initial message itself is probably an instance and it
did not
provide explicit means for correlating back to it, so the reply
mechanism uses
implicit (aka engine managed) correlation to return the long-running
correlation tokens.
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:
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
which does not make much
sense.
-----Original
Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Monday, August
16, 2004
12:06 PM
To: Ugo Corda
Cc: wsbpel@lists.oasis-open.org
Subject: Re:
[wsbpel] Issue - 120
- What are the semantics when an initial <receive> has no
correlation
set?
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:
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?
-----Original
Message-----
From: Ron Ten-Hove
[mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Monday,
August 16, 2004
10:46 AM
To: Ugo Corda
Cc: wsbpel@lists.oasis-open.org
Subject: Re:
[wsbpel] Issue - 120
- What are the semantics when an initial <receive> has no
correlation
set?
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