今回の JBoss BPM Suite のヒント/トリック集では、JBoss BPM Suite が提供する「ワークフローの制御パターン(Control Workflow Patterns)」についてご説明します。
この投稿ではまず、vdAtHKB03で定義された基礎のフロー制御パターンにふれます。そして、BPM-06-22で定義されているBPMN2の仕様により、BPM Suiteでのサポートが制限されるパターンについて解析します。
この投稿で、フローの制御パターン 全20種類をすべてカバーします。まず、5つの基礎的な制御フローパターンを説明し、次に高度な分岐や同期パターンなど 15のパターンを説明します。
パターン
オリジナルの研究論文では、著者は5つの基礎的な制御パターンをカバーしています:- Sequence - ワークフロープロセス内のアクティビティは、同じプロセス内に存在する直前のアクティビティが完了した後、有効になります。
- Parallel Split - ワークフロー内でシングルスレッドが複数スレッドに分岐するポイント。分岐されたスレッドは同時もしくは任意の順序で実行できます。
- Synchronization - ワークフロープロセス内で並列で動作しているサブプロセスやアクティビティが1つのスレッドに収束するポイント。
- Exclusive Choice - ワークフロープロセス内で、制御データや条件により複数分岐の中から1つ選択されるポイント。
- Simple Merge - ワークフロープロセス内で、複数分岐先が同期せずに収束するポイント。分岐先の処理が、どれも並列に実行されていないことが前提となるパターンです。
- Multi-choice - ワークフロープロセス内で、制御データや条件により複数ある分岐先の中からいくつか選択されるポイント
- Synchronizing Merge - ワークフロープロセス内で、複数パスが1つのスレッドに収束されるポイント。複数パスが実行されている時、有効なスレッドはすべて同期されます。1つのパスのみ実行されている時、代わりのパスは同期されずに収束されます。このパターンは、すでに実行されたパスが、他のパスが完了するのを待つあいだ再び実行されないと仮定されています。
- Multi-merge - ワークフロープロセス内で、複数パスが同期せずに収束するポイント。複数パスが並列で実行された場合、収束ポイント以降のアクティビティは収束ポイントを通過する毎に実行されるでしょう。
- Discriminator - ワークフロープロセス内で、いずれかの入力パスが実行しているアクティビティが完了するまで後続のアクティビティを実行しないポイントです。いずれかのアクティビティが完了した後、残りのアクティビティが完了しても後続のアクティビティを実行しません。すべての入力パスが実行しているアクティビティが完了した際、Discriminator は初期化され、再び前述した処理を行います。(リセット機能は重要です。でなければ、ループを使うコンテキストで利用することができません)
- Arbitrary Cycles - ワークフロープロセス内で、1つ以上のアクティビティを繰り返し実行するポイント。
- Implicit Termination - 設定されたサブプロセスは、何も処理することがない場合に終了されます。ワークフロー内で実行中のアクティビティがなく、どのアクティビティも実行されることがない状態です。(デッドロックも発生していない状況です)
- Multiple Instances Without Synchronization - 1つのコンテキスト(ワークフローインスタンス)に焦点をあてた場合、複数のアクティビティインスタンスが生成される可能性があります。また、管理用スレッドの生成を管理する機能(facility)があります。個々の管理用スレッドはそれぞれ独立しています。また、これらスレッドを同期する必要はありません。
- Multiple Instances With a Priori Design Time Knowledge - 1つのプロセスインスタンスで、アクティビティが複数回実行されます。ワークフロープロセスの設計時に、プロセスインスタンスでは何回アクティビティが実行されるか把握できます。すべてのアクティビティが完了した場合、他のアクティビティを開始する必要があります。
- Multiple Instances With a Priori Runtime Knowledge - ある状況下で、アクティビティが複数回実行されます。ある状況下で何回アクティビティが実行されるかは、状況の内容やリソースの空き状況により異ります。実行時のある段階(アクティビティの実行が必要になる前)で把握されます。すべてのアクティビティが完了した場合、他のアクティビティを開始する必要があります。
- Multiple Instances Without a Priori Runtime Knowledge - ある状況下で、アクティビティが複数回実行されます。ある状況下で何回アクティビティが実行されるかは、ワークフロープロセスの設計中も、実行中(アクティビティの実行が必要になる前)にも把握されることはありません。すべてのアクティビティが完了した場合、他のアクティビティを開始する必要があります。パターン9 との違いは、いくつかのアクティビティがすでに実行中であったり実行が完了していても、再度アクティビティを実行できる点です。
- Deferred Choice - ワークフロープロセスの中で、複数ある分岐先の中から1つ選ばれます。XOR-splitとは対照的に、明示的に分岐先が選択(例えば データや条件に基づいて)されず、複数の選択肢が提供されます。AND-splitとは対照的に、1つの分岐先のみ実行されます。つまり、分岐先の1つが実行され、残りの分岐先は無効化されます。重要な注意点ですが、選択は可能な限り遅くなります。分岐先の処理が開始されるまで、実際には選択が遅延されます。
- Interleaved Parallel Routing - アクティビティのセットが任意の順番で実行されます:セット内のアクティビティはそれぞれ実行されます。実行順序は実行時に判断され、複数アクティビティが同時に実行されることはありません。(あるワークフローインスタンス内で、2つのアクティビティが同時に実行されることはありません)
- Milestone - 指定された状態にある場合にのみアクティビティが実行されます。つまり、期限切れではないマイルストーンに到達した時にアクティビティが実行されます。A、B、Cという3つのアクティビティがあると仮定します。アクティビティA はアクティビティBが実行済みでアクティビティCが実行されていない状態にのみ有効化されます。つまり、Bの実行前にAは有効化されません。また、Cの実行後にAは有効化されません。
- Cancel Activity - 有効化されたアクティビティが無効化されます。つまり、アクティビティの実行を待っているスレッドが削除されます。
- Cancel Case - ケース(ワークフローのインスタンス)が削除されます。(プロセスのある箇所で複数アクティビティが実行されていたとしても、関連するすべてのスレッドは削除されます)
JBoss BPM Suite
前述した基礎的な制御パターンがカバーされているか製品を確認し、下記マトリックスにまとめました。JBoss BPM Suite が直接サポートしている場合、+ と表記します。直接サポートされていない場合、+/- と表記します。スパゲティのようなダイアグラムやコーディングが必要な場合、サポートがされていないと判断し - と表記します。パターン | JBoss BPM Suite |
Sequence | + |
Parallel Split | + |
Synchronization | + |
Exclusive Choice | + |
Simple Merge | + |
JBoss BPM Suite の製品概要マトリックスでは、以下のように高度な分岐や同期処理を潜在的にサポートしていることがわかります。
パターン | JBoss BPM Suite |
Multi-choice | + |
Synchronizing Merge | + |
Multi-merge | + / -* |
Discriminator | + / -* |
Arbitrary Cycles | + |
Implicit Termination | + |
Multiple Instances Without Synchronization | + |
Multiple Instances With a Priori DT Knowledge | + |
Multiple Instances With a Priori RT Knowledge | + |
Multiple Instances Without a Priori RT Knowledge | -** |
Deferred Choice | + |
Interleaved Parallel Routing | + / -* |
Milestone | -** |
Cancel Activity | + |
Cancel Case | + |
* BPMNの仕様による制限
** BPMNの仕様ではサポートされていない
お気付きになられたかもしれませんが、JBoss BPM Suite は vdAtHKB03 でまとめられた制御パターンをほとんどサポートすることができます。限定的なサポートのみとなったパターンについては、BPM-06-22 で説明されている BPMNの仕様に起因するものです。
JBoss BPM Suite は、制御パターンを充分サポートできていることがご理解いただけたかと思います。
今後の投稿で、制御パターンが充分サポートできていることをご理解いただけるようなサンプルプロジェクトを提供する予定です。ぜひ、ご注目ください。
原文: Red Hat JBoss BPM Suite - support matrix Control Workflow Patterns Eric D. Schabell
「この訳は違うだろ」と思われた方はお知らせください、修正します。記事の要約 ->「BPM Suite は、ほぼすべてのワークフロー制御パターンをサポートします。BPMN2の仕様により機能制限されるところがあるから、全部はカバーできません」
返信削除学術的な文章なので、「こんなパターンもあるんだぁ」ぐらいに思ってください。きちんと読みたい方は、workflow pattern の原文にチャレンジしてください。descrption だけでなく example もあるのでイメージしやすいです。