システム開発においては「設計と実装との間に大きなギャップがある」といわれています。そしてそのギャップには、業務を熟知した設計者と実装技術にたけたIT技術者といった知識面でのギャップ、設計から実装までに時間やお金がかかるといったコスト面でのギャップ、2つの側面があります。前者は使い物にならないシステムの原因になったり、後者はシステム構築の機会を失う原因になったりします。設計と実装をシームレスにつなぐこと、それはシステム開発において渇望されている課題の1つです。
設計と実装をシームレスにつなぐために、BPMNで記述したビジネスプロセス図からプロセス実行言語であるBPEL4WSを生成できるようになっています。今回は、ビジネスプロセス図を記述した次のステップとして、フローを検証し、BPEL4WS生成に必要な情報を補足し、BPEL4WSを生成するといった一連の流れについて説明します。
ビジネスプロセスを実装する話の前に、BPMNで記述したフローを検証するポイントについて紹介します。設計と実装をシームレスにつないで正確な引き継ぎができたとしても、元の設計図面が間違っていれば意味がありません。実装フェーズに移る前にしっかりと設計図面をチェックしておくことが重要です。
図1のフローでは2つの問題点を含んでいます。1つは作業時間を考慮しなくても問題点が分かるもの、もう1つは作業時間を考慮しながらフローを見ていくと問題点が明らかになるものです。頭の体操を兼ねて問題点を探してみてください。
デッドロックとは、業務フロー上のある個所においてフローの到着を待っているが全く流れてこない状態を指します。まさに業務が途絶えるような状態です。図1においてもデッドロックになる個所があります。例えば、ゲートウェイ(1)と(2)が両方とも「Yes」となるケースを考えてみてください。そのようなケースでは、タスクCが実行されず、タスクB、C、Dを通過する3つのフローを待っている結合(Join)においてタスクCからのフローを待ち続けてしまいます。一見、ANDゲートウェイで分流してANDゲートウェイで合流しているので分流と合流の対応が取れているようにも見えますが、その間にXORゲートウェイがあるためにデッドロックになってしまうのです。業務要件の観点からは業務が途絶えることはあり得ないので、デッドロックはモデラーの意図とは異なる振る舞いを記述してしまう設計ミスです。デフォルトシーケンスフローがない包含的判断など、結合以外でもデッドロックになるケースがあります。フローを待ち続けてしまう個所がないかをチェックするように心掛けてください。
今度は作業時間を考慮しながらゲートウェイ(1)と(2)が両方とも「No」となるケースを考えてみてください。そのようなケースでは、タスクAが完了した後にタスクCとタスクDが開始されます。そして3分後にタスクDが完了すると、再度タスクAが実行され、5分後にタスクCとタスクDを開始しようとします。しかしながら、10分かかるタスクCは実行中のままになっています。実行中のタスクを2重で開始しようとするときにどのように振る舞うのかがあいまいであるため、BPMN仕様書ではこのようなループを「不適切なループ」と呼び、許可されないフローとしています。不適切なループは、シーケンスフローを使用してループを表現する場合にのみ問題となるものです。そのようなループを記述する場合には気を付けてください。
BPEL4WSは、WebサービスをオーケストレーションするロジックをXMLベースで記述するプロセス実行言語です。BPMNで記述したビジネスプロセス図からBPEL4WSを生成するためには、ビジネスプロセス図にWebサービスを呼び出す方法などを補足してやる必要があります。Webサービスを呼び出す方法はXMLベースのインターフェイス記述言語であるWSDL(Web Service Description Language)に規定されています。WSDLの定義に従ってBPMNとWebサービスを結び付ける情報を定義していくといったイメージになります(図2)。
ではBPMNとWebサービスを結び付ける情報をどこに定義すればよいのでしょうか。 BPMNは単にモデルを描画する図形を標準化するだけではなく、各図形の詳細を定義する属性までを標準化しているので、そのBPMN属性に定義するのです。図形の特徴を表す情報はすべてBPMN属性に定義されます。例えば、メッセージ開始イベントはEventType属性が「start」でTrigger属性が「message」に設定されているイベントということになります。また、BPEL4WS生成に必要な項目以外にも、説明やレポートの目的で使用するAuthor属性(作成者)やDocumentation属性(補足テキスト情報)、バージョン管理に使用するVersion属性(バージョン)やModificationDate属性(更新日)などがあります。
BPMNからBPEL4WSを生成するために必要なBPMN属性をもう少し具体的に見ていきましょう。まずは図3のビジネスプロセス図を見てください。このプロセスはクライアントから旅行予約依頼を受けて、クレジットカード認証サービス、航空券予約サービス、ホテル予約サービスといった3つのWebサービスをオーケストレーションするプロセスです。クレジットカード認証サービスから認証失敗のメッセージを受け取ったときの振る舞いも、エラー中間イベントによる例外フローで表しています。
図3の例では、3つのメッセージイベント、3つのタスク、2つの制御フロー、1つのエラーイベントに対して、以下のようにBPMN属性を設定していきます。
Implementation属性を「WebService」に設定し、WebService属性とMessage属性に「どのWebサービスとどのようなメッセージをやりとりするか」を設定します。2つのメッセージ終了イベントでは Assignments属性に「送信するメッセージに実データを割り当てるための代入式」を設定します。
TaskType属性を「Service」に設定し、Implementation属性を「WebService」に設定します。そして、WebService属性、InMessage属性、OutMessage属性に「どのWebサービスとどのようなメッセージをやりとりするか」を設定し、Assignments属性に「送信するメッセージに実データを割り当てるための代入式」を設定します。
ConditionExpression属性に「制御フローを流れるかどうかを決める評価式」を設定します。具体的には、クライアントから受け取った予約依頼メッセージを確認して予約の必要性を判断する式を設定します。
ErrorCode属性に「クレジットカード認証サービスから受け取る認証失敗メッセージを指し示すエラー名」を設定します。WSDLで規定されている失敗時に送信するメッセージとエラーイベントを結び付けるのです。
以上のようなBPMN属性の設定が終わると、BPEL4WSを生成するために必要な情報がすべてそろったことになります。後はBPEL4WS生成機能を持ったビジネスプロセス・モデリングツールを使って自動生成するだけです(補遺参照)。
この連載ではBPMNの図形要素を紹介しながら「シンプルでありながら豊かな表現能力」といったBPMNの特徴を見てきました。そして、今回はもう1つの特徴である「プロセス実行言語の生成が可能」といった点についても見てきました。次回はいよいよ連載の最終回。特徴(良い面)だけではなくBPMNの課題にも触れながらBPMNの将来について占って(?)みたいと思います。
[補遺 ビジネスプロセス駆動型開発の実際]
ビジネスプロセス駆動型開発はまだまだ先の話かというと、そうではありません。すでに実現するためのツールがいくつかリリースされており、その環境は整っているのです。例えば、BPMNに準拠したビジネスプロセス・モデリングツール「ITpearls Process Modeler for Microsoft Visio」とビジネスプロセスの実行エンジンである「Oracle BPEL Process Manager」を組み合わせて、ビジネスプロセス駆動型開発を実現する手順は次のようになります。
■ Oracle JDeveloper BPEL Designer
■ Oracle BPEL Process Manager
以上のような手順に従って図3のビジネスプロセス図をOracle JDeveloper BPEL Designerにインポートした結果が図4です。BPEL4WSに関する設定はBPMNビジネスプロセス図ですべて済ませているので、後はOracle BPEL Process Managerにデプロイするだけでプロセスは動きます。
Copyright © ITmedia, Inc. All Rights Reserved.