BPMN 2.0エンジンと各社BPMツールの実装

BPMN 2.0エンジンの登場と実装方式の変化

BPMN 2.0準拠をいち早く表明し、ヒューマン・セントリックBPMとインテグレーション・セントリックBPMを兼ね備えたツールとして登場したのが、米Oracleの「Oracle BPM Suite 11g」です。

同社はこれまで、「Oracle SOA Suite」で提供するBPELベースのサービス・インテグレーション機能、つまりインテグレーション・セントリックBPMしか提供できていませんでした。

ところが、買収した米BEA Systemsの製品でヒューマン・セントリックBPMである「BEA AquaLogic BPM」（現Oracle BPM Suite）を、Oracle SOA Suite 11gの基盤上に再構築したのです。

しかも、BPMN 2.0の実行可能モデルからプロセスを直接的に駆動できる"BPMN 2.0エンジン"を開発したのです。

米Intalio（BPMNのプロセス・モデルからBPELを自動生成してプロセスを駆動する技術の先駆者）も、最近になって、米Oracleのこの動き（BPMN 2.0エンジン）に追従しました。これまでのBPELエンジンに加え、BPMN.2.0に準拠したプロセス駆動エンジン（米Oracle同様に、BPMN 2.0エンジンと称している）を、新たに搭載したのです。

米Intalioでは、このうえで、ビジネス・アクティビティ・モリタリング（BAM）、ビジネス・ルール・エンジン、ヒューマンタスク・マネージャ（人の割り当てルール管理）など、ヒューマン・セントリックBPMで必須な機能を追加し、充実させる計画を発表しています。

"BPMN 2.0エンジン"という用語を使ったのは、米Oracleが初めてでしょう。BPMN 2.0エンジンが登場したことにより、BPMNプロセス・モデルの実装方式は、大きく変化するものと思われます。図13に、BPMN 2.0の実装に関して筆者が考える「プロセス特性による実行エンジンの選び方」を示します。

従来、システム連携機能が多く求められるプロセスでは、BPMNで表記したモデルをBPELに再記述する必要がありました。しかし、BPELでの実装方式には、以下のような問題が存在しました。これらの理由から、BPELを介さずにBPMNを直接駆動するやり方が望まれたのです。

• BPMNプロセス・モデルからBPELに、完全には自動変換できない
  • BPELは"システムの作業"プロセスの定義を前提にしているので、"人の作業"に必要なロール／スイムレーンの定義要素がない
  • ループバック（手戻り）が多いヒューマン・プロセスでは、BPEL変換後のXML記述構造をかなり手直しする必要がある
• プロセス・モデルがBPMNとBPELの2つになるので、管理／開発が重複する
• BPELは、ビジネス・ユーザーとのコミュニケーション言語としては使えない

図13は、BPMNモデルを、人間中心プロセスとシステム中心プロセスに階層構造化しています。

上位の人間中心プロセスの実装は、従来のヒューマン・セントリックBPMで採用されている「（1）BPMN直接駆動」が、標準的な実装方式になります。

例外処理が多く複雑なプロセス・パターンを持つシステム中心プロセスは、直接駆動できるBPMNエンジンが存在しなかったため、「（3）BPELに変換」後、手修正を加えてSOA基盤上に実装する方式で対処していました。

しかし、BPMN 2.0エンジンの登場によって、システム中心プロセスは「（2）BPMN直接駆動」の方式に移行できるようになります。

とはいえ、インターネット株取引システムのような、"人の作業"の介入が全作業の5％未満、あるいはゼロであるSTP（Straight Through Processing: ループバックがない前進処理）タイプのシステム中心プロセスであれば、BPMNで詳細定義は行わず、直接BPEL定義から始める選択肢もあります。

なぜなら、システム中心プロセスは、たとえBPMNで記述／管理したとしても、ビジネス・ユーザーにとっては関心がなく、ブラック・ボックスのままでも構わないからです。事実、Oracle BPMSの場合は、BPMNからBPELへの変換機能は提供していません。

Oracle BPMSの基盤となるSOA Suite 11gでは、後述する「SCA」（Service Component Architecture）を採用したグラフィカルなサービス統合設計環境も提供しています。これにより、システム中心プロセスの実装方式として「（4）SCAに変換」のパスも採用できるようになりました。BPELへの依存度は、ますます少なくなってきています。

OracleによるBPMN 2.0プロセス・モデリング

Oracle BPMSは、BPMNプロセスのモデリング環境を「BPM Studio」（「JDeveloper 11g」のプラグイン）として提供しています。多くのBPMN 2.0図形要素の中から、アクティビティ・タスクの図形要素を例に、実際のBPMツールと比較してみましょう。

図14に、BPMN 2.0タスク・タイプとOracle BPMSの比較を示します。

タスクとは、プロセスを構成するアクティビティの最終分割単位（原子単位）です。"人の作業"と"システムの作業"に識別されたアクティビティとも言えます。BPMN 2.0では、図14に示す通り、7つのタイプを定義しています。

このタスク・タイプは、第2回の図5で説明したモデリング・ステップの進行にしたがって識別範囲が拡大し、最終段階の実行可能モデルでは7タイプに詳細化されます。

Oracle BPMSでは、この7タイプのすべてが使えます。さらに、ユーザー・タスクとして、起票タスクやグループ承認タスクなどのように、ローカルで拡張しています。

第2回の図8で例示した分析モデルを、Oracle BPMSに実装して、実行可能モデルとした例を、図15に示します。

図8（分析モデル）と図15（実行可能モデル）を比較すると、次の2点に大きな違いがあることが分かります。

1. 図8の分析モデルで示した顧客プールとシステム・サービス・プール、および、それらの間の、メッセージのやり取りを表す部分（コラボレーション図）が削除されている
2. ユーザー・タスクの前に、サービス・タスクが組み込まれている

1. は、おおかたのBPMSが、現在のところ、企業の内部プロセスの実行だけを対象にしているためです。

2. は、画面処理の背後からサービスをコールするか、ワークフローから直接コールしてユーザー・タスクにデータを受け渡すか、いずれの方法を採用するかによって、モデルは変わります。例図では、後者を選択しています。