|
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
Ugo Corda wrote:
Ron,
It looks like the condition you describe cannot always be detected via
static analysis. Imagine a process where the initiating <receive> (with
no correlation set) is followed by a flow. One branch of the flow
contains an invoke with correlation set (and initiate="yes"), while the
other branch has a receive, also with the same correlation set (and
initiate="no"). Evidently the order of execution required to avoid the
error you mention would be invoke followed by receive. But that might
only be known at run-time.
Even worse, under identical conditions the generation of the error might
be implementation-dependent. Suppose that the message is sent to the
receive before the invoke is executed. One implementation might decide
to cache the message and activate the receive only after the invoke is
executed, in which case the receive might correlate with the set value
established by the invoke (no error). But another implementation might
just generate the error right away as soon as the message is received
before the invoke.
Ugo
-----Original Message-----
From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
Sent: Friday, August 13, 2004 1:04 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 120 - What are the semantics
when an initial <receive> has no correlation set?
Ugo,
If we rule out singletons, then non-initiating <receives>s in a
process MUST be correlated to an existing process instance.
If the BPEL engine receives a message for a
non-initiating <receive>
activity, and that message cannot be correlated to an
existing process
instance, it is an error. If there is no chance of the message being
correlated (the <receive> has no correlation set that can be used for
this purpose), it is still an error. The question is: is it a
run-time
error, or one detected during static analysis of the <process>?
-Ron
Ugo Corda wrote:
Even if we rule out singletons, we should still clarify what happens
when multiple instances exist at the same time as a consequence of
multiple messages being sent to the initial <receive>. If no
correlationSet exists to distinguish the various instances, what
happens to successive messages (non instantiating) sent to the
instances? Do all the instances get a copy the message? Is it
implementation-defined?
Ugo
-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Friday, August 13, 2004 11:00 AM
To: Ugo Corda
Cc: Ron Ten-Hove; wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 120 - What are the semantics
when an initial <receive> has no correlation set?
It occurs to me that we can break this problem down a little more.
One can trivially imagine a web service that consists of exactly one
request/response pair that receives a message, processes
it, sends a
response and exits. Such a webservice would have no need to use
correlation sets. Therefore I think we can be sure that at a
minimum we
want to make it possible to define a BPEL that has a single start
activity with no correlation set that doesn't create a singleton.
What this argues to me is that the default interpretation of
a BPEL with
a start activity with no correlation set is that it is not a
singleton.
Therefore what 120 really should be about is - do we want to
intentionally add an attribute or other mechanism to specify
that a BPEL
process is intended to be a singleton?
We already know we can simulate a singleton in BPEL by having an
instance with a start activity that is only known to the deployment
environment and then having all subsequent messages sent to
the single
BPEL instance. But I readily admit that this is a less than clean
solution. It is best when possible to directly express one's
semantics.
So I think we can then rephrase the issue once again to -
Is it worth
defining explicit singleton behavior in BPEL 2.0 (or whatever
we call it)?
To which, given our other priorities, I think the answer is
no. But I
realize that my answer is just a matter of opinion.
To unsubscribe from this mailing list (and be removed from
the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
ave_workgroup.php.
|