why does that matter? the elephant in the room that we call the
"dispatcher" has to deal with this stuff, but as far as the process is
concerned, it shouldn't care, should it? we have avoided talking about
the dispatcher at all, and i would think that this question falls into
that domain.
danny
Ugo Corda wrote:
Maciej,
Thank you for the rewrite.
I think you should also spell out what happens with respect to
correlation set initialization. In other words, is it done at the time
the new process is created, or at the time the normal execution flow
reaches the instantiating activity?
Ugo
-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Wednesday, October 20, 2004 7:56 AM
To: Ugo Corda
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
Ugo,
Sorry for the confusion, I've adjusted my proposal (basically
in my previous narrative "createInstance=rendezvous" should
be read as "createInstance=yes and containing
initiate=rendezvous correlation set"). Adjusted text:
I propose we adopt the "less magic" approach described in the
issue description. This means that the semantics of process
instantiation would be as follows: 1. The arrival of message
that matches an activity marked with createInstance=yes (and
not matching an existing process
instance) causes a new process instance to be created. This
message is termed the "instantiating message" for that
process instance. The createInstance=yes activity that was
used to justify the instantiation is termed the
"instantiating activity" for that process instance.
2. Once a process instance is created, all its activities
are executed in the order dictated by the structure of the process.
3. When a <receive> or <pick> activity with
createInstance=yes containing a initiate=yes correlation is
executed, the message "received" will be the "instantiating
message" of the process instance. 4. When a <receive> and
<pick> activity with createInstance=yes containing a
initiate=rendezvous correlation is executed, the message
"received" will be either:
a ) the "instantiating message" if said activity is the
"instantiating activity"
b ) some other message matching the correlation key from
the "instantiating message" if said activity is not the
"instantiating activity"
Key changes to text:
6.4:
OLD: This is done by setting the createInstance attribute of
such an activity to "yes". When a message is received by such
an activity, an instance of the business process is created
if it does not already exist (see Providing Web Service
Operations and Pick).
NEW: This is done by setting the createInstance attribute of
such an activity to "yes". When a message that matches such
an activity is received, an instance of the business process
is created if it does not already exist (see Providing Web
Service Operations and Pick).
OLD: To be instantiated, each business process must contain
at least one such "start activity." This must be an initial
activity in the sense that there is no basic activity that
logically precedes it in the behavior of the process.
NEW: To be instantiated, each business process must contain
at least one such "start activity." ----strike---
11.4:
OLD: A receive activity annotated in this way MUST be an
initial activity in the process, that is, the only other
basic activities may potentially be performed prior to or
simultaneously with such a receive activity MUST be similarly
annotated receive activities.
NEW: -----strike----
13.5.3:
OLD: If the event handler is associated with the global
process scope, the event handler is enabled as soon as the
process instance is created. The process instance is created
when the first receive activity that provides for the
creation of a process instance (indicated via the
createInstance attribute set to "yes") has received and
processed the corresponding message. This allows the alarm
time for a global alarm event to be specified using the data
provided within the message that creates a process instance,
as shown in the following example:
NEW: If the event handler is associated with the global
process scope, the event handler is enabled as soon as the
process instance is created.
Note: alarm time for a global alarm event /cannot/ be
specified using the data provided within the message that
creates a process instance!
On Tue, 2004-10-19 at 19:53, Ugo Corda wrote:
Maciej,
I suggest you rewrite your initial proposal keeping
"createInstance"
and "initiate" separate. Right now, you are conflating the two (you
are, for instance, talking about
"createInstance=rendezvous"), which
makes the proposed language confusing.
Ugo
P.S. Talking about rendezvous, shouldn't the two initial
receive's in
the Multiple Start Activities example (sec. 16.3.2) have
initiate="rendezvous" instead of initiate="yes"?
-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Tuesday, October 19, 2004 5:08 PM
To: Ugo Corda
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
Ugo,
My understanding is that if in a process we find an activity
with createInstance=yes / initiate=yes, then that must be the
/sole/ createInstance activity in that process. (11.4
suggests that only in the case of rendezvous are multiple
createInstance activities permitted).
With createInstance="yes" / initiate="rendezvous" we can have
multiple createInstance activities, but for that case we have
(rendezvous) semantics (section 11.4 + Issue 37):
1. all activities will synchronize on the same correlation
set 2. there will be exactly one "winner" activity that sets
the correlation,
3. all the other activities will "lose", and respect the
correlation.
How the winner is chosen is out of scope, but we know exactly
one winner will be chosen.
-maciej
On Tue, 2004-10-19 at 12:21, Ugo Corda wrote:
Maciej,
I think the rendezvous issue made
such cases technically illegal (i.e. you can only have one
createInstance=yes activity).
I am not sure what you are referring to. Could you
please clarify?
Thank you,
Ugo
-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Tuesday, October 19, 2004 7:16 AM
To: Ugo Corda
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue - 168 - Proposal To Vote
Ugo,
You are correct. Although, I think the rendezvous issue made
such cases technically illegal (i.e. you can only have one
createInstance=yes activity). In the case of
"createInstance=rendezvous", my first instinct would
be to say
that processes with this ambiguity are illegal and should be
detected by static analysis.
-maciej
On Mon, 2004-10-18 at 18:49, Ugo Corda wrote:
Maciej,
What about the case where the "instantiating message"
matches more
than one activity marked with createInstance=yes? Your
proposed
wording does not explicitly rule that out, but in such
a case the
concept of "instantiating activity" would become
ambiguous, in the
sense that it would not be clear which one of those
activities could
be labeled that way.
Ugo
-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com]
Sent: Monday, October 18, 2004 11:22 AM
To: wsbpel@lists.oasis-open.org
Subject: [wsbpel] Issue - 168 - Proposal To Vote
I propose we adopt the "less magic" approach described in
the
issue description. This means that the semantics
of process
instantiation would be as follows: 1. The
arrival of message
that matches an activity marked with
createInstance=yes/rendezvous (and not matching an
existing process
instance) causes a new process instance to be
created. This
message is termed the "instantiating message" for that
process instance. The
createInstance=yes/rendezvous activity
that was used to justify the instantiation is termed the
"instantiating activity" for that process
instance. 2. Once
a process instance is created, all its activities are
executed in the order dictated by the structure of
the process.
3. When a <receive> or <pick> activity with
createInstance=yes is executed, the message
"received" will
be the "instantiating message" of the process
instance. 4.
When a <receive> and <pick> activity with
createInstance=rendezvous is executed, the message
"received" will be either:
a ) the "instantiating message" if said
activity is the
"instantiating activity"
b ) some other message matching the
correlation key from
the "instantiating message" if said activity is not the
"instantiating activity"
Key changes to text:
6.4:
OLD: This is done by setting the createInstance
attribute of
such an activity to "yes". When a message is received by
such an activity, an instance of the business process is
created if it does not already exist (see Providing Web
Service Operations and Pick).
NEW: This is done by setting the createInstance
attribute of
such an activity to "yes". When a message that
matches such
an activity is received, an instance of the
business process
is created if it does not already exist (see
Providing Web
Service Operations and Pick).
OLD: To be instantiated, each business process must
contain at
least one such "start activity." This must be an initial
activity in the sense that there is no basic
activity that
logically precedes it in the behavior of the process.
NEW: To be instantiated, each business process
must contain
at least one such "start activity." ----strike---
11.4:
OLD: A receive activity annotated in this way MUST be
an initial
activity in the process, that is, the only other basic
activities may potentially be performed prior to or
simultaneously with such a receive activity MUST
be similarly
annotated receive activities.
NEW: -----strike----
13.5.3:
OLD: If the event handler is associated with the
global process
scope, the event handler is enabled as soon as the process
instance is created. The process instance is
created when the
first receive activity that provides for the
creation of a
process instance (indicated via the createInstance
attribute set
to "yes") has received and processed the
corresponding message.
This allows the alarm time for a global alarm event to be
specified using the data provided within the message that
creates a process instance, as shown in the
following example:
NEW: If the event handler is associated with the
global process
scope, the event handler is enabled as soon as the process
instance is created.
Note: alarm time for a global alarm event /cannot/ be
specified using the data provided within the message that
creates a process instance!
On Mon, 2004-10-04 at 17:14, ws-bpel issues list editor
wrote:
This issue has been added to the wsbpel issue list with
a status
of
"received". The status will be changed to
"open" if the TC
accepts it
as identifying a bug in the spec or decides it should
be accepted
specially. Otherwise it will be closed without further
consideration
(but will be marked as "Revisitable")
The issues list is posted as a Technical Committee
document to the
OASIS WSBPEL TC pages on a regular basis. The current
edition, as a TC
document, is the most recent version of the document
entitled in the
"Issues" folder of the WSBPEL TC document list
- the next
posting as a
TC document will include this issue. The list editor's
working copy,
which will normally include an issue when it is
announced, is
available at this constant URL. Issue - 168 - Semantics
of instance
creation
Status: received
Date added: 4 Oct 2004
Categories: State management
Date submitted: 30 September 2004
Submitter: Maciej Szefler
Description: Discussions of issue 81 : Are start
activities that
aren't createInstance activities legal? have brought
to light a
certain deficiency of clarity in the current
specification
with
respect to issue of instance creation. The present spec
makes various
vague and somewhat contradictory statements as to how
createInstance
activities should be handled.
On the one hand, the spec suggests that process
creation
is
"implicit"
and that the createInstance flag is merely an annotation
that defines
which message events cause an instance to be created
and that once
created the process instance processes all activities
in the same
manner largely oblivious to the value of that
annotation.
On the other hand, the spec restricts the set of
activities
that are
"initial" activities, and establishes exceptional
semantics
(for process-level event handlers) that could
be construed
to imply that
createInstance activities are actually activated before
any other
activities, irrespective of their actual location in
the process.
I posit that the former interpretation provides a
concise and
manageable view of the instance creation process. By
making
the spec
consistent with it we can define execution
semantics of a
single process instance without reference to instance
creation. We
can handle
instance creation simply and separately by stipulating
that
a process
instance is created when a message event that
would match
one of the
createInstance activities is received. This message
event is
"allocated" to that activity, so that when that
activity
is
actually
activated (in the normal course of process instance
evaluation) it
will receive the said event.
The major implication of this model on execution
semantics is the
elimination of the notion of "initiate" activities.
This concept
becomes unnecessary. One might object on the basis that
without the
initiate activity restrictions the following
process would be
perfectly legal:
<sequence>
<invoke .../>
<receive createInstance="yes" .../>
</sequence>
Such a process certainly seems objectionable.
However, the
details of
normal execution semantics would make such a process
unlikely. That is
to say, the <invoke> would need to use a message
variable (for the
request), and that variable could not have been
initialized unless
some activity preceded the <invoke>. One might then
object with the
following:
<sequence>
<receive createInstance="no" .. var="foo"/>
<invoke ... inVar="foo"/>
<receive createInstance="yes" ..>
</sequence>
However, in this process the first receive is
invalid unless a
correlation set is used. But in order to use the
correlation set, it
first needs to be initialized, and the only way
to do that
is with an
invoke or a receive/pick that precedes it, so
you're back
to needing a
<receive> to precede the <invoke>. This receive would
have to have
createInstance="yes" lest it run into the same problem.
But if this
receive had createInstance="yes" then the same
annotation on the
second <receive> would be invalid.
Now, one might get cleverer still and object
based on the
following somewhat convoluted process:
<sequence>
<assign>
<copy>
<to variable="foo"/>
<from> literal </from>
</copy>
</assign>
<invoke ... inVar="foo">
<correlation name="cset1" initiate="yes"
pattern="in"/>
</invoke>
<receive createInstance="no" ..>
<correlation name="cset1" initiate="no" />
</receive>
<receive createInstance="yes" ..>
</sequence>
However the above construct would result in ALL process
instances
having the same correlation set value, which
does not make
any sense.
But one could still object by changing the pattern to
"out" on the
invoke, and asserting that the partner generates
unique output
messages for each invocation thereby yielding unique
correlation keys.
But even this very brink of the edge case forces us to
change nothing
in the semantics. The only significant
implication is that
in certain
unlikely circumstances, the implementation might have to
handle <invoke>s and non-createInstance
<receive> before it
has a
chance to
offload the createInstance message to the
createInstance <receive>
(i.e. it needs to provide a "memory" for the
message that
created the
instance). The only plausible use case for this kind of
behavior
is
for initialization of static content.
Finally, adopting uniform execution semantics would
lead us to
elimination of the exceptional language in the spec that
requires that
process-level alarm handlers can use data that would
normally only be
valid after a receive activity completes. This is not so
onerous, as
it is possible to move a process-level event handler
into a scope
following the initial receives.
Changes: 4 Oct 2004 - new issue
____________________________________________________________________
__
To comment on this issue (including whether it
should be
accepted), please follow-up to this announcement on the
wsbpel@lists.oasis-open.org list (replying to this
message should
automatically send your message to that list), or ensure
the subject
line as you send it starts "Issue - 168 -
[anything]" or
is
a reply to
such a message. If you want to formally propose a
resolution to an
open issue, please start the subject line "Issue - 168
- Proposed
resolution", without any Re: or similar.
To add a new issue, see the issues procedures document
(but
the address for new issue submission is the
sender of this
announcement).
Choreology Anti virus scan completed
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/leave_wo
rk
group.php.
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/leave_wo
rk
group.php.
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/leave_workgroup.php.
|