OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]