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

ユーザー・インタフェース設計

ユーザー・タスクの実装設計は、ヒューマン・インタラクション（人の介入）の画面設計が主な作業になります。Oracle BPMSを例に、話を進めます。

Oracle BPMSのユーザー・インタフェース設計は、JSF（JavaServer Faces）をベースにした「データ・モデル連動型画面構築フレームワーク」を採用しています。このため、事前に、XMLスキーマで定義したデータ・モデルが必要です。この考え方は、BPMN 2.0が規定している実行可能モデリング・アプローチを踏襲しています。

図16に、Oracle のXMLスキーマ・デザイナを示します。この図は、第2回の図9で示したダイアグラムとほぼ同じ表現形式を採用しています。サード・パーティ製品を用いて事前に定義したデータ・モデルをXMLスキーマの形式でインポートすることもできます。

図16で定義したXMLスキーマから、入出力に必要なデータを選択します。BPMオペレーションで必要になる定型フレーム（データの回送者、有効期限、"承認・確定"ボタン、"却下"ボタンなどを配置）を組み込んだフォーム・テンプレートを基に、画面を生成できます。図17が、その生成画面例です。

この画面の"内容"フレームにあるオブジェクトが、XMLスキーマから生成された入出力データ項目です。データに構造体がある場合は、その構造にしたがってフレームが自動構成されるので、1つの親に対して複数の子があるグリッド型の表現も、容易に設計できます。

データ項目のラベルは、XMLスキーマとして定義した要素名から、自動編集されます。英語名の場合は、英語のラベルを日本語に上書きしながら、その対訳をリソース・ファイルに記録することで、バイリンガル画面にすることもできます。

また、この画面はJSFをベースにしているので、生成された画面を親画面に、図18のタスク・フロー（画面遷移図）を使って別途開発した参照画面をリンクし、ユーザービリティを高めることができます。従来のアプリケーション・システム開発とは異なり、画面遷移はタスクごとの小片に分割され、全体の画面遷移は、ワークフローがダイナミックにコントロールします。

プロセスとユーザー・インタフェースの結びつき

従来のアプリケーション・システム開発では、ユーザー・インタフェースはデータベースと強く結び付いていました。しかし、BPMにおけるユーザー・インタフェース開発は、プロセス・データ・プールにあるデータ・モデルが、データ格納の中心になります。

したがって、データ・プール上のデータ・オブジェクトとユーザー・インタフェースをパラメータで結び付けるという、極めてシンプルな構造になります。

ユーザー・インタフェースの設計手順も、従来のシステム開発とは異なります。具体的には、ビジネス・プロセス・モデリング→データ・モデリング→ユーザー・タスク別ユーザー・インタフェース、という流れで設計することになります。

徹底した"コードレス化"が進む、SOAの開発技術: SCA

欧米企業の事例では、BPMは平均3～6カ月という短い期間で、現場業務に効果をもたらすことが確認されています。ただし、これは「人対人」や「人対システム」のプロセスを中心とする、ヒューマン・セントリックBPMの分野に限った話です。

一方、インテグレーション・セントリック、つまり、業務のサービス要件に従ってシステムを統合する作業は、依然として開発難易度が高く、変化対応力の点で満足できるレベルには達していません。

しかし、BPELの策定母体であるOASISは2007年、新たに「SCA」（Service Component Architecture）と呼ぶサービス部品プログラミング・モデルの仕様を策定しました。米IBMや米Oracleなどの大手ベンダーが、同仕様をSOA製品に実装しています。

SCAを実装したSOA製品によって、インテグレーション・セントリックの難易度が高いという問題は、改善されつつあります。こうしたツールを使うと、あたかも電子回路図を設計するような感覚で、ビジネス・サービス層のコンポジット・サービス（複合機能部品）を組み立てることができます。

図19は、Oracle SOA Suite 11gで利用できる、コンポジットの設計環境です。

右辺にある「外部参照」部には、Webサービスの基本部品を配置します。左辺の「公開されたサービス」部には、WSDL（Web Service Definition Language）で定義したサービス・インタフェースを配置します。中央のコンポーネントに配置した、メディエータと呼ぶデータ変換およびルーティング・サービスを介して、右辺の基本部品を組み合わせ、左辺の要求仕様に合致したサービスをアッセンブルする仕組みです。

ここでは、プロセス・モデリングでトップダウン的に導き出した"システムの作業"の外部仕様を、左辺にWSDLとして定義します。一方、既存リソースから再編した基礎部品を基にボトムアップで統合ロジックを設計する概念で、第1回の図3中段に示したビジネス・サービス層およびWebサービス層の設計を支援します。

サービスの組み立てや修正に際し、もはやJavaやC++などのコーディング知識は必要ありません。モデル駆動型の開発を実践できる時代が、すでに到来しているのです。

以上で、BPMN 2.0を中核にした、モデル駆動型開発に関する解説を終わります。

欧米のBPM技術の知見者の中には、このような新しいモデル駆動型開発の登場を「The Third Wave」（第3の波）あるいは「Tipping Point」（転換点）と呼ぶ人がいます。従来のアプローチとは不連続な関係にあり、ある意味で挑戦的であるからです。ツールと標準は、整いつつあります。残るのは、それを使う人の意識改革のような気がします。

次回（最終回）では、BPMN 2.0で新たに登場した、カンバセーション図、コレオグラフィ図など、企業間連携にかかわるビジネス・プロセス・モデリングについて解説します。