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

[Ricky Ho <riho@cisco.com>]

Dieter,

There maybe two models of treating "process":

Model 1
======
Each process instance is an active, autonomous executing entity.  They 
manage their own lifecycle and have no direct control on others.  They 
interact with each other via message passing.

Model 2
======
Process is a passive "function/subroutine".  Process instance is created 
when it is "called" by another process instance.  The caller will receive a 
respond when the "callee"   finishes.  So there are some lifecycle 
dependencies between the caller and callee.  Also the caller and callee 
doesn't interact via message passing.  The caller pass in parameters when 
make the call, those parameter is used to initialize the callee when it starts.


I believe both model is legitimate and should be supported.  My motivation 
of proposing explicit declaration of process instantiation is trying to 
provide a better support of model 2.  Yes, I also propose that we should 
support "call" and "spawn".

And these two model are NOT mutually exclusive.  My suggestion is to 
provide another way for process interaction, I'm not suggesting to replace 
the current mechanism.

Also, because analyzing concurrent execution is hard and error-prone, 
people usually attempt to design sequential activities first and push the 
concurrent execution to the outer layer as much as possible.  Because outer 
layer tends to be more coarse-grain, this reduce the complexity of 
analyzing concurrent execution behavior.  This is what I observe from many 
enterprise user who model their business processes.

Therefore, I think model 2 happens much more frequent than model 1.

Now go back to your question ...

Yes, method 1 avoid the problem by modifying the process into two physical 
representation to deal with each combination of starting message.  But I 
don't see the duplicated code problem since we can factor out the common 
portion of business logic to another process definition.

In method 2, when the "triggeredBy" is empty, when to create the process 
instance is up to the vendor implementation.  The vendor can decide to 
create many process instances and put them into a resource pool.  Or they 
can decide to defer the process creation until the first message is 
received.  I believe this is the same as the current BPEL model.  Am I 
wrong ??  In other words, in method 2, it falls back to model 1.

I'm also curious why can't the engine automatically detect the first 
<receive> and start the process.  Why the user need to declare 
(createInstance="yes") and worry about if this is not the first <receive> 
activity.

Best regards,
Ricky

At 02:20 PM 9/17/2003 +0200, Dieter Roller wrote:

>Ricky,
>
>I'm not sure that I understand how you want to solve the multiple start
>activities.
>
>In Method 1 the actual representation of the business process, which says
>upon receipt of either message the business process is started, is gone.
>What we end up is with a physical representation of two different views of
>the same process. Any change to the real process must then be propagated
>down to the  two physcial representations of the process. I think this is
>hard to comprehend as a mental model.
>
>In Method2 I'm not sure that I understand what causes a process instance to
>be created.
>
>Cheers,
>
>dieter
>
>
>
>
>|---------+---------------------------->
>|         |           Ricky Ho         |
>|         |           <riho@cisco.com> |
>|         |                            |
>|         |           09/16/2003 01:47 |
>|         |           AM               |
>|         |                            |
>|---------+---------------------------->
> 
 > >---------------------------------------------------------------------------------------------------------------------------------------------|
>   | 
 >                                                                       |
>   |       To:       wsbpel@lists.oasis-open.org 
 >                                                                       |
>   |       cc: 
 >                                                                       |
>   |       Subject:  Re: [wsbpel] Issue - 64 - Explicit declaration of 
> process  instantiation                                                    |
>   | 
 >                                                                       |
>   | 
 >                                                                       |
> 
 > >---------------------------------------------------------------------------------------------------------------------------------------------|
>
>
>
>Ron, thanks for bringing up the multi-start points.
>
>First I consider most business processes have a single, well-defined
>starting point.  For this kind, I hope I've convinced that explicitly
>declare the initialization is a merit.
>
>Now go back to your scenario (which I hope to be a rare situation), then
>there maybe 2 ways to handle that.
>
>
>Mechanism 1: Define multiple process
>=============================
>ProcessA:  Receive buyer request first
>ProcessB:  Receive shipper request first
>
>In other words, I have multiple processes.  Depends on which is the first
>message being received, I'll select the corresponding process to
>start.  Therefore, within each process, I have a well-defined single
>starting point.
>
>
>Mechanism 2: Define an empty triggeredBy
>================================
>In this case, the process instance is started without any variable
>initialization, and the variables are initialized at the first moment of
><receive>.  This is the same as current BPEL model.
>
>
>Best regards,
>Ricky
>
>At 08:20 AM 9/15/2003 -0700, you wrote:
> >Ricky,
> >
> >    Doesn't explicitly separating start activities lose the ability to
> > have multiple starts, which are used to support non-deterministic start
> > conditions? For example, a shipping company may have a process for
> > receiving shipment requests from a purchaser and seller; where both must
> > send messages before the shipment can be arranged. However, the purchaser
>
> > and seller have no way to co-ordinate to assure that one of them is the
> > first to send a message to the shipping company (i.e., parallelism in the
>
> > global process). To handle this type of situation, we must be able to
> > model the idea that multiple start points (activities) are possible, and
> > that once the process is started (a particular start activity is "fired",
> > the other start activities become "normal" non-start activities instead.
> > (This all hinges on correlation of course).
> >
> >    It seems to me that the lack of more explicit start activities is a
> > benefit, at least with respect to non-deterministic start. Or are you
> > suggesting that the <triggeredBy> element of a process be added to the
> > current BPEL vocabulary, to make it more readable?
> >
> >Cheers,
> >-Ron
>
>
>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
>.