[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 64 - Explicit declaration of process instantiation
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 >.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]