Please chose one option for closing issue 168
1. We should guarantee that an initial start activity will complete before any other activities are allowed to execute. This will prevent race conditions, prevent us from having to discuss the dispatcher, prevent a bunch of edge cases and make sure that the existing event handler model will work just fine. See email with full info at: http://lists.oasis-open.org/archives/wsbpel/200411/msg00018.html
2. 2 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 or 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 and 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"
See email for full info at : http://lists.oasis-open.org/archives/wsbpel/200410/msg00167.html |
