You are right that looked that way the change is "small". There is a
significant difference however. Today, I can have concurrent start
activities and the behavior is essentially what you describe, but the fact
is that any one of the start activities could potentially be hit first and
start the process; in that sense the different concurrent executions that
the process represents are all legal (possible) ones. When non-start
activities are allowed as initial activities the only legal execution
sequences are those in which start activities go first. So the process
definition (as in your flow example) is not a faithful representation of
the possible execution sequences. I think we agree on this.
Given that, I think I would need a little more than the benefit of the
doubt to agree; how about a compelling use case?
Paco
"Yaron Y. Goland"
<> To: Francisco Curbera/Watson/IBM@IBMUS
cc: wsbpeltc <>
09/16/2004 07:02 Subject: Re: [wsbpel] Issue - 81 - Proposal for Vote
PM
Please respond to
ygoland
Here is my high level understanding of BPEL as it exists today. Please
note that this is a conceptual model and is not intended to direct
actual implementation.
Step 1 - A new BPEL process is deployed to (what I call) the BPEL
dispatcher.
Step 2 - The BPEL dispatcher receives a message and determines that the
message matches a start activity.
Step 3 - The BPEL dispatcher starts a new instance of the process and
passes that instance the message.
Step 4 - The new process instance begins execution by:
Step 4a - Executing any intervening scope, flow or sequence
activities
in order to reach the start activity that matched the incoming message
and having that start activity receive the message.
Step 4b - Once the start activity has received the message
(and thus
initialized its correlation sets if any) then any other start activities
are immediately executed with the correlation sets turned into
initialize="no".
At this point we now have a fully initialized and running process instance.
The proposed language for issue 81 makes exactly one change to the
previous. Specifically issue 81 would add one sentence to the end of
step 4b - "In addition any initial activities that are not start
activities would also begin execution."
I therefore see the change proposed in 81 as both minor and consistent
with the functionality in BPEL. I believe that we should give the
benefit of the doubt to flexibility and so support this change.
Thanks,
Yaron
Francisco Curbera wrote:
