Re: [wsbpel] Issue 6 - Rough draft of proposal for vote

["Yaron Y. Goland" <ygoland@bea.com>]

I'll answer both your and Edwin's questions in the same e-mail since I 
believe your concerns to be similar.

I do believe that N-out-of-M happens, although in our experience much 
less rarely then the simple orJoin semantics defined below. It is to 
support N-out-of-M that I proposed issue 142 - Break & Continue. The 
appropriate application of Break and Continue can model N-out-of-M 
semantics.

But, and again this is just our experience, we find that in the majority 
of cases users just want simple or-join semantics and so under the 
general rule of easy things should be easy and hard things possible I 
propose this solution to issue 6 for easy things and issue 142 for hard 
things.

As for the appropriateness of termination, we generally find that 
termination has proven to be the most desired semantics for orJoins 
amongst our users. I make no claim to universality, I can only relate 
our own experiences. In these cases once a flow has finished the 
activities of the remaining flows are not terribly useful but if we 
leave them running (with their results ignored) this causes all sorts of 
nasty concurrency problems. By just immediately terminating (with the 
bpws:forcedTermination handler for clean up, if any is needed) then we 
leave a lot fewer things to go wrong.

	Thanks,

		Yaron

andrew.francis@elf.mcgill.ca wrote:

> 
> 
> Quoting "Yaron Y. Goland" <ygoland@bea.com>:
> 
>  > A very common business process design pattern is to have multiple
>  > simultaneous actions where only one of the actions needs to complete in
>  > order for the process to continue. A classic example is a search
>  > operation. The proposal given below enables the programmer to directly
>  > express this pattern in the BPEL process.
> 
> On the "Workflow Patterns" website, van aalst describes two constructs:
> "discriminator" and "N-out-of-M" join. What you are describing sounds
> like the "discriminator." The discriminator waits for one activity to
> complete before starting the next activity. The remaining parallel
> activities are allowed to complete but the results are ignored. This
> differs from Issue's six's description that talks about terminating
> "unnecessary" concurrent activities.
> 
> If this is the case, why not construct the more general case, the
> "N-out-of-M" join and allow the option to terminate or ignore outstanding
> concurrent activities?
> 
> Cheer,
> Andrew
> 
> "Workflow Patterns" website
> http://tmitwww.tm.tue.nl/research/patterns/patterns.htm
> 
> 
> 
> 
> 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. 
> 
>