RE: [wsbpel] Issue - 64 - Explicit declaration of process instantiation

[Ricky Ho <riho@cisco.com>]

I'm not trying to introduce a new term and I agree with you that
<receive> is perfectly fine.  In fact inside the
<triggeredBy>, there is a <receive>.

The difference is whether the initialization activity get buried inside
the main activity of the process.  My suggestion is that it should
be defined outside the main activity.  Basically, I think it is
desirable to have a clear-cut starting point.

My model doesn't fit well if there is multiple starting points which need
to join later (in Ron's example).  In such case (I guess this is the
minority), my model can be degenerated to the existing model by putting
an empty inside the initialization.

Best regards,
Ricky

At 06:38 PM 9/16/2003 +0200, Eckenfels. Bernd wrote:

Hello Ricky,
 
I agree that it is a good thing to allow process instantiation with additional data. In fact our business engine is doing that: based on external rules an incoming event is mapped to an WSCall (Partner/PT/Operation) and to additional parameters. This is then used to send a trigger message to a waiting receive. The receive has the "normal" payload parts, but also a parameter part, which contains stuff like "this prticular event expects a response", "this particular busienss partner uses certificate x" ...
 
That way we can have a single process definition, which works for multiple partners (i.e. event sources), without the need of explicite conditionals in the process.
 
(I think this is what you have described in your requirements).
 
But since it is possible with the actual receive instantiate=yes to expect an additional part (which is not part of the intrface definition with the business part, but part of the implementation bindings), I dont see the need for explicite triggeredBy Elements.
 
In fact, eben an on-demand process, which is sarted by a time event can be modelled as a receive (waiting for the time trigger message).
 
Greetings
Bernd
Chief Architect
--
SEEBURGER AG - Edisonstr.1 , D-75015 Bretten, Germany
Fax: +49 (0)7252 96-2400 - Phone: +49 (0)7252 96-1256
mailto:b.eckenfels@seeburger.de - http://www.seeburger.de

-----Original Message-----

From: ws-bpel issues list editor [mailto:peter.furniss@choreology.com]

Sent: Monday, September 15, 2003 8:35 PM

To: wsbpel@lists.oasis-open.org

Subject: [wsbpel] Issue - 64 - Explicit declaration of process instantiation

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>.