始めに
Tony Bear氏(source)は、次のように言っています。
BPMな人は金星から、WSな人は火星からこれは、はっきりとしていないBPMの分野における大きな区分けを正確にまとめたものと言えます。「BPMな人」という言葉は、プロセスモデリングにフォーカスする人のことを言っています。彼らの出発点は、組織の中で人とシステムが如何にして協調するかについてを表現するための手続きの分析です。モデラーの観点では、初期にフォーカスするのは技術に関してではなく、人とシステムが如何にして協調するかをドキュメント化した、技術ではないビジネス分析です。この分野でのBPMプロジェクトの多くにとって、プロセスの自動化は検討事項ではありません。実際には、その最終目的はビジネスプロセスのコアとなるものをドキュメント化することで、組織がどのように機能するのかについてのより多くの見識を作ることです。こういった背景からもたらされるBPMに特化した製品は、前述のビジネスプロセス記述に対するソフトウェアサポートの自動化を容易にすることを目標としています。私は、この仲間をBPMモデラーとして見ています。
一方、「WSな人」は、実行可能なプロセスを作成することにフォーカスする人のことを言っています。実行可能なプロセスは、ビジネスプロセスマネジメントシステム(BPMS)に対する入力の機能を果たすソフトウェアアーティファクトです。実行可能なプロセスは、しばしばグラフィカルなダイアグラム表現を持っています。現在、大手ベンダーに採用されている唯一の実行可能なプロセス言語は、BPEL(source)です。BPELは、WS-*標準をベースとし自動化にフォーカスしているということから、上述した「WSな人」と呼ばれています。最近のサービスオーケストレーションは、BPEL周辺の合意の高まりと共に後押しを得ている状況です。私は、この仲間をオーケストレーションデベロッパーとして見ています。
両方の動きが共通して持っているものは、グラフィカルなダイアグラムと待ち状態を含んでいることにフォーカスしているということです。ダイアグラムは、 BPMモデラーとオーケストレーションデベロッパーの両方にとって重要な道具なのです。ダイアグラムは、とても素早くあるプロセスの概観を与える力を持っています。これは強力な道具であるので、簡単であると受け取るのは注意して下さい。同じように見えるかもしれないダイアグラムでも、表記法や内在する実行可能なプロセス言語に依存している意味が、大きく異なる可能性があります。ダイアグラムの目的も、非常に重要な検討材料です。ビジネス分析のケースでは、プロセスダイアグラムの目的は他の人の説明を支援するためのものです。それらは全体の概要を得る助けとなり、一定レベルの曖昧さが許容されます。実行可能なプロセス言語の場合は、ダイアグラムはコンピュータがどのように振る舞うかを特定するプロセスの一部です。したがって、これらのプロセスタイプは的確であり、正確な説明となっています。
待ち状態を含むことは、実際はより技術的なのですが、それを両方の動きの中で見ることもできます。もしビジネス分析者がビジネスプロセスを書いたならば、異なるアクティビティが異なるリソースに関連しているかもしれません。いくつかのアクティビティは人間のタスクに変わり、その他のアクティビティはコンピュータシステム上で実行されるソフトウェアの一部に変わるかもしれません。そのようなプロセスが自動化されると、プロセスエンジンがその実行を操作します。これは、エンジンが内部でアクティビティのいくつかを自動的に実行しているかもしれないということを意味しています。そうでなければ、万が一アクティビティがプロセスエンジンのスコープ外で実行された場合は、プロセスエンジンは現在の状態の軌跡を保持し、シグナルが外部のエンティティから受信されるまで待つ必要があるでしょう。例えば、あるタスクが完了したということを指示するために、Webアプリケーションのボタンをクリックするといった外部トリガーは、ユーザーであるかもしれません。同様にして、ERPシステムがある請求処理が完了したということをプロセスエンジンに通知するかもしれません。待ち状態のコンセプトは少しだけ抽象的なので、何故ワークフローやプロセス言語に関する議論に関係があるのか不思議に思うかもしれません。しかし、Java のような従来のプログラミング言語は永続化可能な待ち状態をサポートしていないので、それは重要な側面を持っています。
本稿では、ビジネスプロセスの分析と実装の間のギャップがはるかに大きいことによって、今日のワークフローツール市場が提供すると思われることに関して議論します。さらに、この状況を扱う際のより現実的な方法についても提案しようと思います。それらが動向がどのように関連しているのかとその理由について見ていくので、現在の標準とイニシアチブについては、十分に明らかなものとなるでしょう。その議論については、それぞれの議論の対象となる技術の長所と短所を確認し、それらの適切な利用法と不適切な利用法について述べたいと思います。
最終的には、プロセスコンポーネントモデルと呼ばれる新しいタイプのワークフロー技術を紹介します。このタイプのフレームワークは、複数のプロセス言語をハンドルすることが可能で、分析プロセスのダイアグラムから実行可能なプロセスへの変換をより良く支援するプロセス言語をサポートすることができます。
WS-BPEL
BPELとは何か
WS-BPEL(サイト・英語)は、サービスオーケストレーション(source)におけるOASIS(サイト・英語) 標準です。サービスオーケストレーションとは、他のサービスの機能としての新しいサービスのスクリプトを記述することを意味しています。
下記は、ごく簡単なBPELプロセスの図です。: BPELプロセスの配置で、対象のプロセスにサービスがパブリッシュされます。BPELプロセスは、何のサービスをパブリッシュすべきかと、それらのサービスのオペレーションを指定します。
次に、私たちは図１で示されたプロセスの関係の中でBPELのエッセンスの良いイメージを与えるために、最も一般的なBPELアクティビティを説明します。BPELプロセスの中のそれぞれの receive は、プロセスがデプロイされたときにパブリッシュされたサービスオペレーションにあたります。一番上のreceiveアクティビティ receiveOrder は、新規のプロセス実行に対する開始点として振る舞います。そして、左にはコンシューマの注文オペレーションの呼び出しがあります。それにより、初めのreceiveアクティビティから開始される新しいプロセスの実行がもたらされます。
次のステップは invoke です。invokeは別のWSDLサービスを呼び出し、プロセス変数のレスポンスメッセージを受け取ります。このケースでは、getQuote サービスがサプライヤのサービスを呼び出します。
受け取ったメッセージの情報はプロセス変数内に格納されます。メッセージ全体が格納され、それはXMLや簡単なXSDです。extractProductName の assign アクティビティが一つの値から要素を取得し(通常、それはXMLベースです)、別の変数に格納します。そして、その値から別の呼び出し、あるいは現在の受信リクエストのレスポンスメッセージに対するメッセージを作成します。
receive アクティビティの receiveQuote は、サプライヤが submitQuote サービスオペレーションを呼び出すまでプロセスの実行を待ちます。submitQuote オペレーションのサービスはBPELプロセスのデプロイの間もパブリッシュされます。サプライヤがこの注文に関する見積もりを送信したとき、プロセスの実行が継続され、receiveQuote アクティビティに委ねられます。
reply アクティビティは、現在発行しているサービスリクエストに対するレスポンスメッセージを生成します。IN-OUTのメッセージ交換があるサービスオペレーションでa receive が先にメッセージを受信した場合は、応答だけが意味を持つことになります。
注意点として、サプライヤが submitQuote オペレーションを呼び出したときは、受け取るメッセージがreceive アクティビティからの開始によって継続しているプロセス実行をトリガーとしなければならないということです。これは、コリレーションと呼ばれるBPELのもう一つの特徴を示しています。BPELプロセスでは、コリレーションはそのような受信メッセージを待っている既存のプロセス実行と共に、受け取るサービスリクエストメッセージが適合することを意味します。もし受信ノードが始めてであるとマークされると、そのオペレーションで受け取るメッセージは、新しいプロセス実行を生成します。一般に、受け取るドキュメント内のいくつかのデータは、オーダーIDのようなユニークなコリレーターIDとして識別されます。受信ノードに対するメッセージは、プロセスの後で受信メッセージのどこかにあるオーダーIDをベースとした適切なプロセス実行と関連付けられます。実際、コリレーションのセットは、多くの独立したプロパティセットからなっていますが、それには別の複雑さが残されています。
パートナーリンクは、BPELプロセスが通信可能な外部の相手を特定します。BPELプロセスから相手へのサービス呼び出しと、相手からBPELプロセスによる呼び出しの両方が、パートナーリンクに関連づけられます。これらは、ロールと呼ばれています。それぞれのロールは、パートナーリンク上での方向の中で通信するためのインターフェースとして識別されるポートタイプに相当します。したがって、パートナーリンクは2つのロールを宣言することができ、それは2つのロールのうちどちらがBPELプロセス側を表すかという方向を必要とします。BPELプロセスのパートナーリンクのロールに相当するサービスは、プロセスのデプロイの間にパブリッシュされるものです。その他のロールは、サービスの呼び出しで使用されるでしょう。
これは、BPELにおける最も本質的なことです。コンペンセーションハンドリング、イベントハンドリング、実行やタイマーの並列部分といった他の部分は、BPELの優位な特徴ではあるものの、以降の議論で関連の薄い部分であるので取り上げないことにします。
BPELに関する考えと注釈
上述したプロセスの制御フローに関して詳細に見てみましょう。それら3つのサービス呼び出しの組み合わせは、BPEL言語に対する重要な動機付けとなるものの一つを表しています。つまり、非同期サービスのインタラクションにおける簡単な操作ということです。コンシューマサイドのクライアントソフトウェアは、リクエストメッセージを送信し、サービス呼び出しに対するレスポンスメッセージが受信されるまでブロックされます。これは、IN-OUTメッセージ交換パターンと呼ばれています。サービスバインディングとしてHTTP上のSOAPを利用する場合、HTTPリクエストが同じTPC/IP接続でレスポンスが送られるまでブロックしなければならないということを意味しています。さらに一方では、プロセス自身はサプライヤが submitQuote コールバックを実行するまで待つ必要があります。
これら全てのことが、エンタープライズサービスバス(ESB)環境では重要な意味を持ちます。ESBの考え方は、多くのコンポーネントが標準化された方法で接続可能で、他のコンポーネントと共にバス上を通信するということです。標準化された(通常は、WSDL/XMLベースの)メッセージが、バス上でやりとりされます。そして、一方ではHTTP上のSOAP、Eメール、FTP、RMIといったプロトコル、もう一方ではメッセージバスの間で、アダプタのセットがゲートウェイとして機能します。
WS-BPELは、WSDL(source)がベースにもなっています。そして、それは当然のようにWebサービスのようなXMLベースの技術と結びつきます。
同様にして、エンタープライズアプリケーションもサービスバスへの接続が可能です。全てがサービスとしてバス上で利用可能であるならば、ESBのインタラクションがWSDLをベースとしているように、BPELもまたWSDLをベースとしています。したがって、ESBはBPELエンジンにとって理想の場所と言えます。
ESB のそれは、主にXMLベースのサービス間のXMLベースのメッセージ交換にフォーカスしています。BPELがXMLのドキュメントレベルを捨てることは決して無いでしょう。通常、XPathは受け取ったドキュメントの一部をカット＆ペーストしたり、プロセス変数の中にそれを格納するために利用します。呼び出されたサービス、公開されたサービス、プロセス変数といったものは全てXMLをベースとしています。実行ロジックはXMLの世界で直接表現されます。 XMLとしての情報構造化されたものとプログラミング言語のオブジェクトのようなものとの間での変換を行う必要がないということを意味しているという点で、このことは強みであると言えます。複雑なドキュメントやオブジェクト構造に対して、そのような変換は決して透過的でなく自動化もされないので、開発の努力が必要となり、実行時のパフォーマンスにも影響します。
BPEL の洗練されたコリレーションの機能は、既存のメッセージ交換を修正の手間なく活用することが容易です。それは、メッセージやコンテキストヘッダーで伝播するためのプロセス実行IDが不要です。代わりに、BPELエンジンが変換したドキュメントの内容の中の情報の断片全てをベースとしたコリレーションを行います。実際のデータ項目がそれぞれのドキュメント交換の中で特定される方法や、他のドキュメント交換とマッチする方法は、非常に柔軟です。これは良い事です。何故なら、例えばコミュニケーションプロトコルのような多くの統合シナリオにおいて、交換されたドキュメントの制御を行わないからです。
しかし、Business Process Management(BPM)との関連はどこから来るのでしょうか？BPMモデラーの視点からすると、その関連は問題を含んでいます。私が見つけることができた唯一の本当のリンクは、機能よりもよいマーケティングをベースとしていました。BPMモデラーにとって、BPELはいくつかの基本的な機能が大きく欠如しています。しかし、ドキュメントを交換するパートナーの制御を行わないESB環境の中で新しいサービスを記述するために利用するとき、BPELは (拡張のないものでさえ)、とても完成度の高いものとなっています。したがって、マセラティ対ハマーのように、正しく評価するためには、そのユースケースに大きく依存すると言えます。
私が見つけることができた最良の関係は、BPELプロセスがダイアグラムとして示すことができるということと、言語として待ち状態をサポートしているということです。これは、ビジネスアナリストによって作られたいくつかのプロセスモデルが、BPELプロセスに変換できるということを意味しています。しかし、このアプローチには2つの制約事項があります。第一に、ビジネスアナリストは技術には疎いということです。したがって、分析モデルのアクティビティが有効なWebサービスとなることはほとんどありません(無いと言っても過言ではありません)。次の問題として、BPELがブロック構造化されているということです。分析モデルは、一般的にグラフベースとなっています。故に、大抵の場合は、BPELの実行プロセスに変換する際に、アナリストの分析ダイアグラムをうまく保持することができません。これが、BPMNからBPELへのマッピングが困難で、多くの制約事項を抱えている確かな理由です。
BPM のためにBPELを使うための最も顕著な矛盾は、アナリストが技術に疎いということと、BPELプロセスのアクティビティが詰まるところWebサービスの呼び出しとなってしまうことです。また、BPELプロセスのブロック構造化された性質も、モデリングの目的に対して大きな制約となります。アナリストは、ボックスと矢印を自由に書くことを必要とし、それらはグラフ構造やarbitrary cycles (source) パターンとなります。BPELプロセスはトランジッションの考えを持っていません。代わりに、BPELプロセスはコンポジット構造であり、トップレベルのアクティビティは、例えばあるシーケンスです。シーケンスは、ネストしたアクティビティリストを含んでいます。これらのいくつかは基本的な(あるいはアトミックな) アクティビティとなり、いくつかはネストしたアクティビティリストを含んだ複雑なアクティビティとなります。良いツールによって、トップダウンのアクティビティはBPELプロセスを作るのにとても役に立つものとなります。しかし、分析モデルをBPELプロセスにマップすることは非常に異なることであるので、控えめに見ても通常は簡単なことではありません。
BPM のためにBPELを使うもう一つの問題として、制限されたデータ操作の機能があります。XMLドキュメントから内容の断片を抽出することが、サービスオーケストレーションで必要なことの多く大部分です。しかし、BPMに対して、多くのデータ処理は、しばしばプロセスの過程の中で行われたことを必要とします。XPathやその他のXMLベースの変換技術は、単純に十分な機能を持っていません。
あなたがアーキテクトとしてBPMのためにBPELを利用することを考えるならば、あなた自身に求められる質問は、ESBのコアビジネスなプロセスデータを必要としているかどうかということです。IT産業は、ストアドプロシージャからJEEといった、データが「cloud(雲、即ちインターネット)」上にある新しいアプリケーション構築の管理が容易になるようなエンタープライズ技術へと移行してきました。BPELエンジンが維持を必要としているデータは顧客、クライアント、サプライヤー、製品といった領域モデルに関係しています。この領域でのデータは、通常、IT基盤のリレーショナルデータベースの中に格納されます。コアビジネスプロセスの情報は、リレーショナルデータベースの中のドメイン情報と容易に関連付けられなければなりません。もし、あなたのアプリケーションがドキュメントのクライアント参照を知る必要があるならばどうしますか？BPELエンジンへのプロセス変数としてドキュメントを問い合わせ、XMLドキュメントからXPathによって参照を抽出したいですか？その指標として、そのような情報がデータベースの中のドメインモデルに含まれる必要があります。それは、BPELエンジンの中ではありません。BPELは、ドメインモデルデータベースの中に格納されたその種の情報を妨げませんが、それをより難しいものとします。ドメインモデルに格納された顧客の参照を得るために、特別なWebサービスの実装を必要とするかもしれません。それ故、BPELは分割されたドメインモデルの情報を得ることを容易にします。その点には注意が必要です。
David氏のCase against BPEL(source)、David Chappell氏のブログ(source)にあるJoe McKendrick氏(source)の話、Jeff Davisの"What's wrong with BPEL(source)は、BPMに適切ではないという点で同様の指摘をしています。
誤解しないでください。これは、BPELのバッシングではありません。BPELに関しては、他のサービスの機能として新しいサービスを記述するためのすばらしい技術であると思っています。しかし、BPMに対しての保証をしているわけではなく、それは現在知られていることです。
BPEL拡張
BPEL4People(source)は、ヒューマンタスクがどのようにしてBPELプロセスの中に含めることができるかについて述べています。BPEL4Peopleは、BPELプロセスのアクティビティとしてヒューマンタスクを加えるために、BPEL拡張メカニズムを利用しています。その仕様は、BPELエンジンとタスクコンポーネントの間でのメッセージ交換プロトコルを定義しています。BPEL4Peopleでは、人のリンクという概念を導入しています。タスク割り当ては、そのタスクに責任を持っている人やグループの選択となります。BPEL4Peopleでは、人やグループがどのように記述されることができるかについて定めています。しかし、その選択における実行時の評価は、個々の情報の構造と同様に仕様の範囲外となっています。最近になって、BPEL4Peopleをサポートする団体が、標準化のためにその仕様をOASISへ提出することを決定しました(source)。よって、近い将来には、BPEL4PeopleがBPEL実装の多くで見られるようになることが期待されます。
BPEL4People は、しばしばワークフローの機能をBPELとそれによって作られるBPMにとってよりフィットしたものを加えるためのものとして見られます。しかし、これは真実ではありません。アナリストがアクティビティをモデル化するとき、それらが結果としてヒューマンタスクやシステムの処理となってしまうことがあります。BPELは、それらのアクティビティ間のコミュニケーションが、XMLベースのプロセス変数を通して行われることを、今なお強要しています。開発者が XSLTでの変換を追加したければ、ビジネスアナリストが技術的な詳細に興味が無い場合くとも、それはダイアグラムの中に現れる新しいアクティビティとなります。BPELプロセスのダイアグラム中のグラフィカルなアクティビティの配置は、プロセスをうまく実行可能にしている間、分析ダイアグラムを保持するためのWebサービスやXML技術と密に結合している状態です。
BPELJは昔のホワイトペーパー(source) であり、JavaをBPELプロセスに結びつけるための標準化の提案です。これは、Javaの断片や変数としてのJavaオブジェクトを含んだり、BPELプロセスからJava beansを呼び出したりといった複数の面をカバーしています。JCPでのJavaにおけるJSR 207のプロセス定義(source)では、ここからJava標準を形成しようと試みています。しかし、2003年以降、この活動に関連する明確な動きは無い状況です。
これらの拡張でさえ、BPELに関する主要な問題は残ります。それがビジネスプロセス管理のために使われるとき、それはモデリングの側面をきちんとサポートしていません。ビジネスアナリストは、それらのモデリングを自由に行うことができません。何故なら、ダイアグラムがWSDLのサービスと直接で固定的な関係になっているからです。PBMに必要なのは、そのダイアグラムとその下にある技術的なことが疎であることです。アナリストは、ダイアグラム全てを自由に書けなければなりません。そして、開発者はそのダイアグラムをいじることなくアプリケーションアーキテクチャのプロセス実行を組み込むことができなければなりません。それは、BPELでは単純に不可能なのです。であれば、BPELはよくないのでしょうか？いいえ、そうではありません。もし、BPELが細かなサービスから粗いサービスを構築するための統合技術として利用されるのであれば、それは必要な機能全てを持っていると言えます。
BPMN
BPMNとは何か
BPMN(サイト・英語)は、現在、モデル表記法として採用されています。それは、プロセスモデリングを行うために用いることのできるボックスと矢印の形(source)を定義しています。これらは、BPMNが実行のセマンティクスを定義すべきなのか、あるいはグラフィカルな表現のみにすべきなのかということに関するとても(source) 大きな(source) 議論(source)があります。
その仕様は、グラフィカルな形、その意味の説明、それぞれの構造のプロパティセットを含んでいます。BPMNは、その構成とプロパティが特定の実行可能なプロセス言語に対応付けるための方法を説明するためのマッピングを思い描きます。仕様そのものは、BPMNとBPELの間のそういったマッピングを含んでいます。BPMNはXMLやその他のファイルフォーマットを定義していません。可能性の一つとして、BPDM(下記参照(source))は将来的にはそういったファイルフォーマットを定義するかもしれません。BPMNに関する見解や意見を示す前に、まず、分析プロセスと実行可能プロセスの間の違いについてより多くのバックグラウンドを提示したいと思います。
分析対実行
誰かがボックスと矢印でダイアグラムを書くとき、このダイアグラムは多くの異なるものを表現することができます。:
- ドキュメント。他の人に対して、ある目的を達成するために人とシステムがどのように協調するのかについて説明しています。
- 実行可能なプロセス。コンピュータシステムに対し、どのように振舞うのかを説明しています。ちょうど、ソフトウェアの一部のようなものです。
- ソフトウェアの技術的なアーティファクトに関連のある状態マシン。例えばJavaのクラスといったビジネスプロセスとは関連のないものです。
- 通信プロトコル。複数の相手の間のメッセージ交換を記述します。
- Webアプリケーションのページセット。矢印は、ナビゲーションオプションを表現しています。
ダイアグラムに対するこれらの目的の2つについて、少し詳しく見てみましょう。それは、分析のためのダイアグラムと実行可能なプロセスに対するダイアグラムについてです。第一に、ビジネスレベルの人々は、システム境界を考慮しません。分析プロセスの自動化されたブロックによって、一般的に、アナリストはそれがどこでどのようにしてシステム上で実行されるのかについて知りません。第二に、アナリストがビジネスプロセスをドキュメント化したとき、その目的は、人やシステムが他の人に対してどのように協調するのかを説明することにあります。そのとき、ダイアグラムはその瞬間の概観を与えるための説明の一部としての手助けとなります。そのプロセスの記述は、プロセスが説明されているという状況の中で、読み手がその内容を知っているということを仮定することがあります。したがって、プロセス記述の詳細レベルは変化することがあります。
これは実行プロセスとは大きく異なる点で、それはビジネスプロセスマネジメントシステム(BPMS)に対するインプットとなります。実行可能なプロセスは、 BPMSがどのように振る舞うのかについて正確に定めます。その点において、それは分かりやすいソフトウェアであり、プログラミング言語との唯一の違いは実際の言語です。故に、実行可能なプロセス言語は、システムが何をすべきなのかを説明します。
ビジネスプロセスを自動化するとき、分析と実行可能プロセスの関連は、コンピュータシステムがビジネスプロセスの全てのアクティビティの進展の経過を追い続けなければならないという共通の要求から来ます。そのことから、情報を管理しているシステムはアクティビティの完了を知っている必要があります。システムは、それ自身でいくつかのアクティビティを実行することがあるかもしれません。これは、自動アクティビティと呼ばれています。
現在でも、多くのBMPシステム市場は次のようになっています。「ビジネスアナリストは、ビジネスプロセスが機能し、BPMS上でその記述が実行する方法を書いてください。」どこのマネージャーが、技術に疎いビジネスアナリストの記述を生産物に組み込みたいと思うのでしょうか？BPMシステムは、ビジネスプロセスの分析ダイアグラムが実行可能なビジネスプロセスのダイアグラムととてもよく似ているように思えてしまうという状況下に置かれています。ダイアグラムによって、アナリストと開発者の間のコミュニケーションが改善されますが、開発者は、実行可能なプロセスの一部である全ての技術的な詳細に対し、今もなお責任を持ったままです。
アナリストのダイアグラムが実行可能なプロセスのベースとして利用されるとき、実行可能なプロセス言語が技術的な側面からダイアグラムを分離するのに十分に柔軟なものでなければ、そのダイアグラムは変わってしまうでしょう。例えば、インプットが人から集める必要があり、Javaコードが入力としてその情報で実行される必要があるのなら、ビジネスアナリストは、これを2つの連続したアクティビティとしてモデル化するでしょう。しかし、もしこのプロセスがBPELで実行可能なものとなるのなら、ユーザーが提供したデータをJavaコードによって期待される適切なフォーマットに変換するために、2つの間にアサインを追加しなければならないかもしれません。一般に、これは実行可能プロセスのベースとして分析プロセスを使用するときには、変更が必要になることを示しています。
私が強調したいもう一つの点は、プロセス言語はその複雑さと領域の中で大きく変わることがあるということです。いくつかのプロセス言語は、特定の目的のために制限事項があります。この場合でも、ドキュメント管理システムの承認の言語は、良い例です。そのような言語は非常に単純で、多くの技術的詳細を必要としません。そのダイアグラムはプロセスの大きな一部であり、技術に疎い人たちでもしっかりとした実行可能プロセスを実際に作ることができます。しかし、 BPELやjPDLのような汎用プロセス言語では、話が異なります。これらは対象領域が非常に広いので、言語はより複雑なものとなり、より技術的な詳細を考慮する必要があります。こういった場合は、開発者が技術的詳細を常に管理する必要があります。
プロセス開発のプロセス
これを考慮して、分析のより現実的な考え方とビジネスプロセスを自動化するための開発プロセスを考えてみたいと思います。まず初めに、アナリストはダイアグラムを含むビジネスプロセスの記述を作成します。そして、その変換には実行可能なプロセス言語が必要となります。その変換が与える影響は、アナリストの技術スキルと実行可能なプロセス言語の機能に依存します。いずれにせよ、その目的は、ダイアグラムに関する影響を最小化することなので、ビジネスアナリストは実行可能なプロセスのダイアグラムを認識し理解するようにします。アナリストの関心事ではない多くの技術的詳細が実行可能プロセスに含まれるかもしれないので、そのダイアグラムが氷山の一角であることに注意してください。変換の後は、実行可能なプロセスはソフトウェアであるので、技術に疎いビジネスアナリストはそれを読み取り専用モードで参照すればよいです。
BPM がもたらす大きな利点は、アナリストと開発者が共通の言語を与えられているということにあります。ダイアグラムは、ビジネスアナリストと開発者の間のコミュニケーションを促進することを助けます。これは本当にBPMによる「アジリティ」を作っています。しかし、ビジネスアナリストが簡単にダイアグラムを編集し、「生成物をパブリッシュ」のボタンを押すことが可能になるという期待は、楽観的で非現実的なものと言えます。
モデリング詳細
この節では、直接的なリンクが分析ダイアグラムと実行可能プロセスの間で追求されるとき、グラフィカルなダイアグラムの表記法ではあまり多くの詳細を使用しないということに対する議論を行います。異なる背景の人々が、BPMNを共有しています。人々がBPMの分析モデリングか実行可能なプロセスの側だけを見るとき、OMG会議でのFrank McCabe氏のレポート(source)にあるように思いもかけないところに行くものです。:
BPMNとBPDMの関係についてちょっとした騒ぎが起こっています。それは、BPMNは表記法"だけ"か、あるいは、それには若干のセマンティクスがあるのかということです。彼ら（私を含む）は、私たちが言語を定めようとしていると安易に仮定していたので、全てがBPMNチームへのニュースでした。私たちのために、大きな問題がBPMNダイアグラムの実行セマンティクスの周辺で解決するように思いました。他のことに関してはダイアグラムの表記法だけなので、私たちが実行に関して頭を悩ます必要はありません。ある人は、それがどこへ行ったかについて想像するかもしれません！
これは、モデラーのエキスパートたちがダイアグラム中の多くの情報を表現するための的確な表記法を求めているということを示しています。ビジネスプロセスのドキュメンテーションを支援する分析言語として、私はBPMNが非常に良い選択であると思います。David Chappell氏は、次のように主張します(source)。 モデリングレベルでのポータビリティは、少なくとも実装(実行可能なプロセス)レベルのポータビリティと同じくらいに重要なものです。:
私たちが達成しようとしている目的について考えてください。プロセスロジックのポータビリティ（あるプラットホームから別のプラットフォームへ実装を移行するための機能）は、確かにその一つであるといえます。しかし、人々のポータビリティ、つまり、私たちがあるプロセス設計ツールから別のものへと私たちの技術を移すことができるということもまた重要なことです。BPELは、潜在的に最初の目的をサポートすることができますが、第二の目的に対しては適していません。プロセスを作る多くの人々は、この複雑なXMLベースで直接作業することは決してないでしょう。… 視覚的にプロセスを記述するための新たな標準は、Business Process Modelling Notation(BPMN)です。BPMNが広くサポートされれば(それは可能なことだと思いますが)、人々のプロセス設計スキルがポータブルなものとなるでしょう。
これは、プロセスモデリングが実行可能なプロセスに密接に結びつくならば、プロセスのグラフ表現があまりたくさんの情報を含んではならないという結論に至ります。組織でプロセスモデリングのためにBPMNを使うとき、より基本的な構成のサブセットを持ち出して、それだけを利用するということはよいことだと思います。グラフィカルなダイアグラムの中にあまりに多くの詳細を表現しようとすることで、それらを全ての人が理解する必要が生じます。より細かな詳細がグラフィカルな表記の中で使用されれば、そこでのより少ない可能性として、それらが実行可能な言語とマッチすることが考えれます。BPMN表記法のより細かい詳細の複雑さは、実行可能なプロセスと直接の関係がないビジネスアナリストの大きなチームの中で、過小評価され、用法として蓄えられるだけであってはならないのです。
したがって、私はプロセス言語(実行可能なものと実行可能でないもの)は、一人のグラフィカルプロセス設計者の中でそれらを統一するのは、あまりに多く異なっていると思います。私は、プロセス言語ごとに、BPMNのサブセットが言語と十分にマッチするように定義することができると思います。設計者のツールは、その言語の特定の構造と適切でより細かい詳細をサポートしなければなりません。私は、ある設計者が異なるプロセス言語間で個性を切り替えることができるツールを構想します。しかし、各々のケースにおいて、プロセスがどの言語でモデル化されていて開発されているかが、ユーザーには明らかになっているのです。さらに、シンプルなBPMN(それは実行可能でない分析言語として使われます)は、それらの別々の言語のうちの1つです。その言語の間で、ツールによる変換を支援しますが、これは毎回損失を伴う一方向の変換(source)となるでしょう。
マッピングとミスマッチ
BPMN のマッピングアプローチは、ラウンドトリップのミスを引き起こします。ラウンドトリップの考えは、BPMNの分析モデルと実行可能なプロセスの間の継続的な変換です。ビジネスアナリストは、グラフィカルな表記法やBPMNのプロパティを使用して、BPMNのようなモデリング言語で作業します。開発者は、 BPELのような実行可能な言語で作業します。このアプローチの問題点は、実際には、2つのセットのプロパティを保守するのがあまりにも困難であるということが分かるということです。いくつかのプロパティについて両方の考え方が共用されたとしても、単一のプロパティが異なるBPMNプロパティ名を持ち、 BPELに対応するものとなるかもしれないので、ビジネスアナリストと開発者のコミュニケーションがより困難なものとなります。その他の問題点として、ツールベンダーにとって損失の無いラウンドトリップを作ることが困難になります。
BPMN とBPELが最も名前が挙げられるBPM技術になっているので、それらの間のマッピングについてクローズアップしてみましょう。最初で最大の問題点は、両方の言語の間の構造のミスマッチがあります。BPMNはグラフベースで、BPELはトランジッションのない複合構造で木構造に相当します。次に、並列モデルが大きく異なります。Bruce Silver氏は、それを次のようにうまく要約しています(source) 。:
プロセスモデル(例えばBPMN)とBPMS実装(例えばBPEL)の同期を保つ方法(私たちがラウンドトリップと呼んでいる問題)...あなたがBPMS の監視の中でこのスレッドに従うのなら、BPMNがそう簡単にはBPELにマップできないということを思い出すでしょう。少なくともあなたが編集し保守したいと思っている類のBPELに関して言えばそうです。しかし、自動的にマップすることが可能なBPMNダイアグラムのサブセットがあります。BPMN ツールをコントロールするなら、簡単にBPELにマップすることができないものをユーザーに書かせないことで、その問題を解決することができます。
その他のBPM技術
XPDL
XPDL(サイト・英語)は、1993年以降の1つの標準の陰で、BPMモデラーを統合するためのWorkflow Management Coalition(WfMC)(サイト・英語)の試みです。この標準は、プロセスモデルを保存・交換するために、XMLフォーマットにフォーカスしています。XPDLプロセスはグラフベースなので、ビジネス分析により適していることを意味し、BPELのツリー構造となっています。XPDLプロセスもプロセスダイアグラムの中のアクティビティの協調のようなグラフィカルな情報を含んでいます。プロセスモデラーと例えばシミュレーションツールの間のプロセスモデルを交換するときに、これは便利です。XPDLはスイムレーンを含むタスク管理機能があります。そのプロセス言語は、BPELのような異なるアクティビティに対する実行セマンティクスを正確に定義していません。
John Pyke氏(source)とKeith(source) Swenson氏(source)は、XPDLがBPELと競合するものではないと強調し続けています。それよりは、それらはXPDLがファイル交換フォーマットであると指摘しています。その目的で、それが日の目を見るならば、それらは次のBPDM(source)に先を越されるかもしれません。
BPEL と対照的に、(WSDLをベースとしている)XPDLはテクノロジーニュートラルです。これは、XPDLが、所謂「アプリケーション」を解決するために導入された方向の無いレベルを分離することを意味しています。XPDL 2.0は、BPMNに適合するようにきちんと設計されています。もともと、XPDLはグラフベースなのでBPMNにはより良い状態で適合します。そして、 XPDL 2.0では、すべてのBPMNプロパティがXPDLに適合されます。XPDLは、確かにBPMN、さらにはBPELによりよくマッチしています。しかし、 XPDL/BPMNの連携とBPELの間の大きな違いは、正確な実行セマンティクスです。
BPDM
BPDM(source) は新しくないですが、それは公式リリースなしで内部的に今なお議論されています。主に、BPDMはビジネスプロセスとファイル形式を表現するためのモデルを含めなければなりません。BPMNとBPDMの両方がOMGであるので、将来、ファイルフォーマットの変換としてXPDLの代わりになるかもしれません。このイニシアティブに関しては、まだ公開されませんでした。Fred Cummins氏は、ハイレベルなBPDMのゴール(source)について次のように述べています。
その仕様は、BPMNの図に対する基礎的なモデルを提供します。これは、BPMNプロセスモデルが、XMI（モデルのインターチェンジのためのXML）をベースとしたモデリングツールの間での交換に対する標準的な表現を持っていることを意味しています。その仕様は、オーケストレーションプロセス(定められたものとして実行されたもの)とコレオグラフィー(Webサービスの交換などのような独立したプロセス間での交換の仕様)の両方における形式的な表現を提供します。
BPDMがこの10年半の間でXPDLに置き換わるというハードワークになるかもしれないので、Keith Swenson氏(source)は、防御の姿勢になっています。そして、Sandy Kemsley氏(source)は、Fred氏のプレゼンテーションについて報告しています。
jPDL
jPDL(source)は実際のところ標準でありませんが、私たちがJBoss jBPMプロジェクトの一部として作成した実行可能な言葉です。予め注意しておきますが、jBPMはjPDLだけが有名です。現在では、jBPMはプロセス言語のためのプラットホームで、jPDLはサポートしている言語の一つです。この言語の目的は、ダイアグラムと技術的詳細の間をきれいに分離することができる実行可能な言語となることです。技術的詳細はJavaプラットフォームに集中しています。
先に見たように、BPMNはアナリストにとって良いものです。しかし、それは実行可能でありません。BPELは実行可能ですが、それはBPMをサポートするのに適していません。私の考えでは、直列型のBPMN/BPELはBPMにとってはとても出来の悪いアプローチであり、それらはうまく適合しません。
一方で、jPDLは、自由なモデリングにフォーカスを置いた実行可能なプロセス言語です。まず第一に、それはグラフベースです。次に、プロセスダイアグラムと技術的詳細の間で、より分離を可能にするための機能をいくつか持っています。例えば、jPDLではダイアグラムには無いJavaコードの断片を含めることができます。これは、アクションと呼ばれています。この種の他の機能として、ノードの実行時のビヘイビアに対してカスタムJavaコードを参照することが可能です。そのような方法で、開発者は、ビジネスアナリストがプロセスの特定のグラフィックノードに欲しいと思っている特別なビヘイビアを、自由にコード化することができます。
さらに、この言語は、分析モデルと実行可能なプロセスモデルを統一しようとしません。しかし、先に議論した機能は、分析対実行(source)の節で概説されたソフトウェア開発プロセスをサポートしているので、とても簡単に作ることができます。jPDLはJavaコミュニティにおいて広く導入されました。
コレオグラフィー
ebXML(source)とWS-CDL(source)は、コレオグラフィーの標準化の活動です。John Reynolds氏(source)は、オーケストレーションとコレオグラフィーの違いを次のように説明しています。
オーケストレーション == 実行可能なプロセス
Webサービスオーケストレーションは、特定のビジネスプロセスの実行に関するものです。WS-BPELは、オーケストレーションエンジンで実行されることが可能なプロセスを定めるための言語です。
コレオグラフィー == 複数の相手とのコラボレーション
Webサービスコレオグラフィーは、Webサービスの間の外部的に観察可能な相互作用を記述することに関するものです。WS-CDLは、複数相手の契約を記述するための言語で、若干WSDLの拡張のようなものです。つまり、WSDLはWebサービスインターフェースを記述し、WS-CDLはWebサービス間のコラボレーションを記述します。
オーケストレーションは実行可能なプロセスで、コレオグラフィーは、複数の相手とのコラボレーションのプロトコルを特定するために利用されます。故に、 BPELはオーケストレーション言語です。BPELプロセスは、システム上で実行されることが可能です。コレオグラフィープロセスは、複数の相手が一緒にコラボレートするための方法を定めているため、コレオグラフィープロセス自身が直接デプロイされることはありません。代わりに、プロジェクションは参加しているもののうちの一つでなければなりません。そして、プロジェクションは実行可能なプロセスとなります。
本稿の残りで、実行可能なプロセス言語の市場の状況について説明します。オーケストレーション言語には、多くのしっかりとした基盤がありません。私の考えでは、それがこの種の言語が未だ十分でない最も主要な理由であると考えます。
プロセスコンポーネントモデル
プロセスコンポーネントモデルであること
プロセスコンポーネントモデルを持っている2つの技術は、マイクロソフトのWorkflow Foundation(WF)(サイト・英語) とJBoss jBPM(サイト・英語)です。jBPMの基盤は、The Process Virtual Machine(source)の中でドキュメント化されています。そして、マイクロソフトのworkflow foundationの採用するアプローチと多くの類似点があります。
その考えは、プロセスグラフの中のアクティビティが、一般的な目的のプログラミング言語の中でアクティビティの実行時のビヘイビアを実装しているコンポーネントと関連があるということです。プロセス言語の各々のアクティビティタイプは、一つの実装コンポーネントに対応します。例えば、Webサービス呼び出しのアクティビティ、ヒューマンタスクのアクティビティ、Eメールアクティビティ、これら全てが実装コンポーネントに対応しています。
このアプローチの目新しさは、共通基盤のレイヤーがBPMやワークフローの技術で抽出されることです。ワークフローの基盤やプロセス仮想マシンの両方が、 BPM技術で考えられているのではありません。代わりに、それら両方が共通基盤のフレームワークを提供していて、十分に成熟したBPMやワークフロー製品の形に拡張することができます。また、David Chappell氏(source)がMSDNの記事(source)の中で次のように説明しています。
マイクロソフトの.NET Framework 3.0の一部としてワークフローを実装することで、ソフトウェアを作成するためのこのアプローチは、それを必要とする全てのWindowsアプリケーションで利用できます。これには、サーバー上、あるいはクライアント上で動作しているアプリケーションだけでなく、エンドユーザーが作ったアプリケーション、独立ソフトウェアベンダーによるもの、マイクロソフト自身によるものも含まれます。しかし、それにはいくらかの時間がかかりますが、Windows Workflow Foundationは、マイクロソフトの製品と技術のワークフローにおける共通基盤となるでしょう。
アクティビティコンポーネントは、コンフィギュレーションプロパティのセットを定義することができます。例えば、Eメールアクティビティは、受取人の表現、件名、本文といったコンフィギュレーションプロパティを持つことが出来ます。このように、それが使われるたびに、同じアクティビティの実装で異なる設定をすることができます。
この新しいアプローチから引き起こされること
初めに気づくことは、複数のプロセス言語が、同じアクティビティのコンポーネントフレームワーク上で実装されることができるという点です。各々のプロセス言語は、いくつかのアクティビティタイプから成ります。それらのアクティビティタイプの各々に対して、JavaまたはC#のような汎用プログラミング言語で、実行時のビヘイビアを実装することができます。そして、実行可能なプロセス言語は、単純にアクティビティタイプの実装セットとなります。そのようなアクティビティコンポーネントにおいて最も重要なものは、プロセス構成に関する実行時のビヘイビアを実装するコードです。XMLのシリアライゼーション、プロセス構成を設定するための設計フォーム、永続化やその他の多くのものも、プロセスを構成するコンポーネントに潜在的に含めることが可能です。
複数のプロセス言語をサポートすることができるので、プロセスコンポーネントモデルは特定のプロセス言語の重要性を低減します。その代わりに、それぞれのプロセスに対して最適な実行可能プロセスを開発者に選択させます。このことは、BPMエンジンが1つのプロセス言語をサポートするだけであるという状況を超えて、アナリストと開発者の間の関心事の分離を強化します。
プロセス言語は、拡張可能になっています。もし、BPEL、jPDL、あるいはその他の言語を使用するのであれば、単に自分のアクティビティを実装し、その言語を追加することができます。プロセス言語のサブセットを公開するだけでも可能です。例えば、ドキュメント管理システムで承認を加えるために、非常に単純なドメインに特化したプロセス言語を作成することもできます。
この視点で、私たちは4つの詳細レベルを確認することができます。それは、それは分析モデルから実行可能なプロセスモデルへのスムーズな移行で完全に適合します。
- プロセスのグラフ構造
- アクティビティタイプの選択(実行時の実装に対応する)
- ランタイム実装の設定
- プランB:アクティビティのカスタムコーディング
ツールによって、次のレベルのためのプロセスアナリストとプロセス開発者の間の協調を思い描くことができます。アナリストは、ダイアグラムの中でノードのアクティビティタイプを選ぶことなく、グラフ構造を特定するためのデザイナーツールを利用することができます。それは、完全に自由なモデルを許容しています。次のレベルの詳細は、アクティビティタイプを選択することです。例えば、プロセスの中のある段階を指定することで、ヒューマンタスクやWebサービスの呼び出しとなるでしょう。これは、ダイアグラムのグラフィカルなノードである実行時のビヘイビアを関連付けます。次のレベルの詳細は、コンフィギュレーションプロパティです。アナリストは、おそらくWebサービスのエンドポイントのURLを知らないでしょう。それは、Webサービスの呼び出しノードのコンフィギュレーションプロパティであるかもしれません。そして、最終レベルの詳細として、特別なカスタムの実行時ビヘイビアが、利用されたプロセス言語からアクティビティタイプを選ぶための代替として、開発者によってコード化されることができます。このスキームは、分析対実行(source)の節で述べたように、実行可能な開発プロセスがずっと良い状態でアナリストをサポートします。
プロセスコンポーネントモデルは、それらがベースとしているプログラミング言語ととてもよく適合します。例として、jPDLはJavaプロジェクトと非常によく適合し、プロセスにJavaコードを含めることが非常に容易です。例えば、プロセスにドメインモデルオブジェクトを含めるようなことです。同様にして、ウィンドウズのワークフローの状態マシンはC#コードとの統合が容易です。
プロセスエンジンのオペレーション管理は、より簡単なものとなります。ソフトウェア開発の多くの側面は、ある種の実行可能なプロセス言語でモデル化することができます。サービスオーケストレーションとして、BPELを使用しているプロジェクトを想像してください。jPDLは、人々のタスクを管理するためのであり、Webアプリケーションのページの間でナビゲーションを指定するページフローのためのものであるのです。したがって、ある単一のフレームワーク上で、これら全ての言語の実行が可能であるということは、明らかにプラスであると言えます。
まとめ
BPEL は実行可能なプロセス言葉であり、統合の目的に対しては良いものです。しかし、技術的なサービス呼び出しと密に結合しているビジネスプロセスマネジメントに対しては適していません。BPMNは、分析ダイアグラムを書いてアナリストに貢献します。しかし、それは実行可能なものではありません。XPDLは、より採用されることのなかったファイルフォーマットであるため、BPMNにその座を奪われてしまうかもしれません。分析言語と実行可能な言語の間のギャップは、現実的には今もなお大きく残されています。
広範囲にわたる採用を求めてBPMへのより現実的なアプローチを作るために、私たちは、分析プロセスモデルと実行可能なプロセスモデルの間のより良い対比を作ることから始める必要があります。一度、私たちが技術に疎いビジネスアナリストがダイアグラムの中に、製品が準備された状態のソフトウェアを書くことができるという考えを断念するなら、私たちはより現実的で実用的なアプローチになるでしょう。
分析プロセスモデルと実行可能なプロセスの実装を関連づけるとき、そのきっかけとなるものは、ダイアグラムの中の分析プロセス表記で洗練された詳細をあまり多く含めないことです。分析言語と実行可能なプロセス言語が提供するものの共通部分のみを利用することによって、一つのダイアグラムをベースとした、アナリストと開発者のための共通言語が作られるのです。
異なる環境や異なる機能要求では、実行可能なプロセス言語も異なるものが要求されます。一つのプロセス言語でBPM、即ちワークフローやオーケストレーションの全ての形をカバーすることができるだろうという現在の考えは、あまりにも大きな望みを持ちすぎです。もしそのような努力が成功するのであれば、結果として生じるプロセス言語は実用的な利用という点ではあまりに複雑なものとなるでしょう。
ワークフローの技術への新しいアプローチがあります。マイクロソフトのワークフローの基盤とJBoss jBPMのプロセス仮想マシンは、実行時プロセス環境の共通の基盤を抽出します。アクティビティタイプがその共通基盤の上で構築することができるように、これらの技術はコンポーネントモデルを作ります。その基盤は、アクティビティコンポーネントの実行に対する実行時環境を定めます。各々のプロセス言語は、アクティビティタイプのセットから成ります。アクティビティタイプの実行時の振る舞いは、汎用プログラミング言語で実装することができます。つまり、アクティビティは、コンポーネントになります。基本的にあらゆるプロセス言語は、アクティビティタイプのセットを定義します。そして、プロセス言語は、アクティビティコンポーネントの実装セットとして、プロセスコンポーネントフレームワークの上で構築することができるのです。
著者について
Tom Baeyens氏は、JBoss jBPM(サイト・英語)の創設者兼リーダーです。彼は、JSR207のJavaにおけるプロセス定義と、JSR208のJava Business Integrationのエキスパートグループに参加しています。Process Developments(source), と呼ばれているブログで、Tomは、BPMのゴールと今日のソフトウェアアーキテクチャの間でマッチするものを見つけるために、彼の情熱を共有しています。全ての開発者が自身の能力の範囲内でBPM、ワークフロー、オーケストレーションといった知識を持つようになるまで、彼が休むことは無いでしょう。
原文はこちらです：http://www.infoq.com/articles/process-component-models