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

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Andrew,

    Humm... an interesting line of thought here.

    It seems to me that BPEL isn't a great example of a workflow modelling language, executable or otherwise. The question really ought to be: can we take a fairly rich workflow model (with cycles, notions of different sorts of work performers, work-item assignment, etc) and generate BPEL that can be used (in conjunction with suitable services) to execute the given model?

    The specific patterns cited, discriminator or N-out-of-M join, do pose challenges for direct mapping to BPEL. I suspect that a suitably ugly construct of nested scopes, fault handlers, and event handlers could be contrived to provide an executable process that would conform to these patterns. Not the sort of thing you want a business analyst creating by hand, mind you.

    One could imagine a tool that could allow the user to create and edit a high-level workflow model, directly using the patterns catalogued at van Aalst's site, which could be transformed mechanically into BPEL for execution in an environment equipped with proper supporting services. Of course, a very clever programmer (one of the fabled rocket scientist types) could directly implement such patterns in BPEL, but such people are rare, and only a few of them are qualified as business analysts as well....

-Ron

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.