Issue - 64 - Explicit declaration of process instantiation

[ws-bpel issues list editor<peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list. 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 document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting 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 - 64 - Explicit declaration of process instantiation

Status: open
Date added: 15 Sep 2003
Submitter: Ricky Ho
Date submitted: 15 September 2003
Description: There is no way to pass data to "initialize the variables" of a newly 
creating process instance. The only thing that you can do is to put a 
<receive ... createInstance="yes"/> as the first activity so that the 
process instance can receive external data for variable 
initialization.  This model seems attempt to treat every process instance 
"homogeneous" (they are same when they start).  The fact that each process 
instance may have different values in their process variables is just 
because they receive different incoming call in their subsequent receive 
activity.

However, since the spec requires the first basic activity in the process must be a <receive createInstance="yes"/>, the actual intention may try to make the process instance distinct rather than homogeneous.

The current mechanism has the following challenges ...

1. We need to define additional constraints (such as it must be the first activity ... etc.) which complicates the model.
2. Locating the "first activity" is not easy. What if the the first activity is a <sequence> which contains another <sequence>, the first basic activity maybe nested multiple levels down. What if the first activity is a <flow> which has multiple starting activities (some are basic activities and some are nested <flows>).

To treat every process instance distinct, I'm suggesting to use a more explicit way to capture the initialization of process instances, which includes

1. The mechanism to instantiate a new process instance
2. What variables will be initiated

Therefore, rather than using the following ....
<process>
   ....
   <sequence>
   ....
     <receive partner="buyer" portType="p1" operation="submitOrder" 
variable="var1" createInstance="yes"/>
   ....
     <receive ..../>
   <sequence>
</process>
I suggest to use this ...
<process>
...
   <triggeredBy>
     <receive partner="buyer" portType="p1" variable="var1" 
operation="submitOrder"/>
   </triggeredBy>
...
   <sequence>
   ....
     <receive ..../>
   <sequence>
</process>

Please note the following difference ...

1. <triggeredBy> is defined outside the root activity, while <receive> is defined inside the root process activity, maybe even multiple level of nesting down. There is no need to locate the first activity in the <triggerBy> case because it is explicitly defined.
2. <triggeredBy> is using a different element tag which makes the initialization step more explicit.
3. The subElement of <triggeredBy> is extensible, so we can introduce new ways to instantiate process instances. At this moment, only a <receive> can be nested inside the <triggerBy>.

Links: Ricky Ho, 13 Sep 2003     
Dieter Roller, 13 Sep 2003     
Ricky Ho, 13 Sep 2003     
Ricky Ho, 13 Sep 2003     
Ron Ten-Hove, 15 Sep 2003
Changes: 15 Sep 2003 - new issue

---

To comment on this issue, 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 - 64 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document.