[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]