My apologies; I misspelled Wil van der Aalst's name.
-Ron
Ron Ten-Hove wrote:
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.
|