BPEL

BPEL（英: business process execution language）とは、実行可能なビジネスプロセスモデリング言語である。

しかしBPELは特定のセマンティックやプロセス構造の要素を持っていないため、考えられるすべてのビジネスプロセスをモデル化し実行することは不可能である。このため、BPELはたとえばJavaのようなプログラミング言語とともに用いられたり、ワークフロー統合ブローカーエンジンなどの商用製品に備わっている独自のスクリプト言語によって拡張されることが多い。

概要

[編集]

BPELの起源はWSFLとXLANGにさかのぼることができる。BPEL は XML によってシリアライズ可能で、大規模プログラミングの概念を実現するものである。大規模プログラミングと小規模プログラミングの概念は、ビジネスプロセスで典型的に見ることができる長時間継続する非同期のプロセスを記述する際の二つの側面によって分類することができる。

BPELがIBMとマイクロソフトによって開発されたのは、BPMI.org が開発した初期の言語BPMLに対抗するためであった。この背景については幾つかの議論があるが、おそらく、さまざまなグループで詳細について合意できない性格によるものと思われる。ワークフロー理論が先祖であるBPELとは異なり、BPMLはPi calculusから着想された。このため、BPMLは完全で定式化された文法を持つことになり、市場には強力なBPMLの製品が登場することとなった。このため、アプリケーションサーバ開発を統一する標準に対して統制力を持ちたいと考えていたIBMとマイクロソフトは懸念を持った。

今日では、過去のBPELとBPMLとの違いはほぼ学術的なものになっている。BPELの文法が勝利を収め、BPMLの意味論が勝利を収めた。IBMとマイクロソフトの力により、今日BPELの名前が残っている。BPELは徐々にBPMLへと近づく方向に進化している。BPMLが形式上完全であるため、これは不可避である。


目的

[編集]

大規模プログラミングは、抽象度の高いプロセスのことであり、BPELではこのようなプロセスを抽象プロセスと呼んでいる。BPELの抽象プロセスは、規格化された方法で表現された振る舞いを表している。抽象プロセスは、メッセージを待つ、メッセージを送信する、失敗したトランザクションの補償をするなどの処理が記述されている。それとは対照的に、小規模プログラミングは、1つのトランザクションで終わるような、生存期間の短い振る舞いを扱う。小規模プログラミングと大規模プログラミングでは異なった言語が必要であるという発想からBPELは生まれた。

BPELの設計目標

[編集]

BPELにはもともと10の設計目標があった:

  1. 外部の実体に対してWSDL 1.1を用いて定義されたWebサービスの操作を介してやりとりし、自身を WSDL 1.1を用いて定義された Webサービスとして宣言するビジネスプロセスを定義すること。やりとりは、portType の定義に依存しポートの定義には依存しないという意味で "抽象的" であること。
  2. XMLに基づいた言語によりビジネスプロセスを定義すること。プロセスのグラフィカルな表現方法を定義したり、プロセスのための特定の設計手法を提供したするものでないこと。
  3. ビジネスプロセスの外部（抽象的）および内部（実行可能）ビューの両方で用いるための、Webサービスを組織化の概念を定義すること。そのようなビジネスプロセスは、ひとつの自律的な存在の振る舞いを定義し、技術的には似たような相手と総合作用を行う。それぞれの使い方のパターン（すなわち抽象ビューと実行可能ビュー）はいくつかの専門化された拡張を必要とするが、これらの拡張は最小限に保たれ、import/exportや、二つの使い方のパターンを結ぶリンクが仕様に準拠する、などの要求に対してテストされていなければならない。
  4. 階層的な、またグラフ的な制御の方式を提供し、両方の使い方を可能な限りシームレスに融合させること。これによりプロセスモデリング空間の分断を減少させる。
  5. プロセスのデータや制御フローを定義するために必要な、単純なデータ操作の機能をサポートする。
  6. インスタンス識別子の定義をアプリケーションレベルのメッセージレベルで許可するプロセスインスタンスの識別メカニズムをサポートする。インスタンスの識別子パートナーによって定義され、変更される可能性がある。
  7. 暗黙的なプロセスインスタンスの生成と消滅を基本的なライフサイクル機構としてサポートする。"suspend"や"resume"のような高度なライフサイクル操作はライフサイクル管理のための将来のリリースで追加される可能性がある。
  8. 弁済のアクションや、長期にわたって有効なビジネスプロセスの一部のためのエラー回復機能をサポートするため問題判定 (scoping) のような、証明された技術に基づいた、長期にわたって有効なトランザクションモデルを定義する。
  9. Webサービスをプロセスの分解と結合のモデルとして用いる。
  10. Webサービスの標準（認証され提案されたもの）の上に、可能な限り組み立て可能な方法で構築される。

BPEL言語

[編集]

BPELはオーケストレーション言語であり、コレオグラフィ[1]言語ではない（en:Web Service Choreography参照）。オーケストレーションとコレオグラフィの主な違いはその範囲である。コレオグラフィモデルがある参加者からのビュー（たとえばピアツーピアモデル）に焦点を置いているが、オーケストレーションモデルはすべての関係者と関連したやりとりを含み、システムの全体的なビューを与える。オーケストレーションとコレオグラフィの区別は次のようにたとえられる：オーケストレーションが、オーケストラの指揮者のような集中管理の振る舞いを記述し、コレオグラフィーは振り付けされた (choreographed) ダンスで、ダンサーが互いのペアの振る舞いに反応するように、それぞれの参加者が外部のイベントに基づいた処理を実行する、分散制御の振る舞いを記述する。

BPELの現代的なビジネスプロセスに対する焦点、さらにWSFLおよびXLANGの歴史から、BPELはWebサービスを外部の通信メカニズムとして採用することになった。

そのため、BPEL のメッセージング能力は、入出力されるメッセージを記述するためのWSDL1.1の使い方に依存する。

メッセージの送信受信を行える能力を提供することに加えて、BPELプログラミング言語は下記の項目をサポートする：

  • プロパティに基づくメッセージ間関連機構
  • XML および WSDL の型に基づく変数
  • 表現や問い合わせを複数の言語で書くことができるようにするための、拡張可能な言語プラグインモデル：BPELはXPath1.0をデフォルトでサポートしている
  • 連接[2]、分岐[3]、反復[4]、並列[5]を含む構造化プログラミング要素
  • ローカル変数、障害ハンドラー、補償ハンドラー、イベントハンドラーを用いたロジックのカプセル化を可能とするスコープシステム
  • 変数への並行的なアクセスを制限するためのシリアライズされたスコープ

WS-BPEL 2.0 での変更点

[編集]
  • 新しいアクティビティの型: repeatUntil, validate, forEach（並列、直列）, rethrow, extensionActivity, compensateScope
  • 名称の変更されたアクティビティ: switch/case は if/else に、terminate は exitに改名された
  • ターミネーションハンドラーが、明示的な終了のアクティビティに適用するために追加された
  • 変数の初期化
  • 変数変換のための XSLT（新しい XPath 拡張関数 bpws:doXslTransform）
  • 変数のデータへの XPath アクセス（XPath 変数の文法 $variable[.part]/location）
  • Webサービスアクティビティにおける XML スキーマ変数 (WS-I doc/lit スタイルサービス用)
  • ローカルに定義された messageExchange (受信アクティビティと返信アクティビティの内部的な対応)
  • 抽象プロセスの明文化(文法および意味)
  • それぞれのアクティビティにおいて記述言語の変更を可能にした

BPELへの '小規模プログラミング' のサポートの追加

[編集]

BPEL の分岐や反復などの制御構造や、変数操作の機能は、ロジックを提供するための'小規模プログラミング'言語を使うことに依存している。すべての BPEL 実装はXPath 1.0 をデフォルトの言語としてサポートしなければならないが、BPEL の設計はシステム構築者が異なる言語も使用できるよう考える必要がある。

BPELJ は、Java が BPEL 内の'小規模プログラミング'として機能できるようにするためのJSR 207 に関連した試みである。

歴史

[編集]

IBM とマイクロソフトは、それぞれが定義したかなりよく似た'大規模プログラミング'言語WSFLとXLANGを持っていた。BPMLの評判と、登場、BPMI.org の成功、Intalio Inc. にリードされたオープンな BMPS への推進活動 により、IBM とマイクロソフトは互いの言語をひとつの新しい言語 BPEL4WS に統合することを決定した。

2003年4月、BEAシステムズ、IBM、マイクロソフト、SAP、Siebel Systemsは、Web Services BPEL Technical Committeeを介して OASIS に BPEL4WS 1.1 を提出した。

BPEL4WSは 1.0 と 1.1 の両方のバージョンで登場したが、OASIS WS-BPEL 技術委員会[1] は 2004年9月14日 に、その仕様をWS-BPEL 2.0 と呼ぶことを投票により決定した。この名称の変更は、BPEL を、WS-で始まる他の Webサービス標準の命名規則にあわせ、BPEL4WS 1.1 と WS-BPEL 2.0 との間の大幅な仕様の強化を表すために行われた。ただし特定のバージョンについて議論していなければ、BPELだけで十分である。

2007年6月、Active Endpoints、アドビ、BEAシステムズ、IBM、オラクル、SAPはBPEL4People および WS-HumanTask 仕様をリリースした。これは、BPELプロセスにおいて人間の活動をどのように取り込むか記述するものである。

BPEL の開発の方向については徐々に論争が巻き起こってきている。WS-HumanTask の形態で BPEL にセマンティックを追加するなどの要求は、BPEL が完全な言語でないという事実を強調するのみである。逆に、実用的なアプリケーションでは、ほぼ常に、ほかのプログラミングツールで言語を拡張する必要がある。完全な言語である BPML では、BPEL を拡張する際必要なように XML に新しいタグを追加するのではなく、新しいセマンティクスをプロセスとして実現することができる。そのため、いわゆる BPEL準拠の製品を使う際には、ベンダーが主張するのがどのバージョンの BPEL であるのかに非常な注意が必要である。BPEL準拠の製品は、BPELだけでは、必ずしもひとつのビジネスプロセスすら実現できない。これが意味するところは、現場でのみ明らかになる。たとえて言うなら、演算子がないために完全なコードを書けないプログラム言語を持っているようなものである。

BPELのBPMNとの関係

[編集]

OASIS技術委員会がスコープ外としたため、WS-BPELのためのグラフィカルな記法に標準はない。いくつかのベンダーはそれぞれのグラフィカルな記法を生み出している。これらの記法はほとんどの BPEL 要素がブロック構造である（たとえば sequence, while, pick, scopeなど）であることを利用している。この機能により、BPEL記述を 昔のNassi-Shneiderman diagramにおける structograms を思い起こすような形態で直接ビジュアルに表現することができる。

まったく異なるビジネスプロセスモデリング言語、Business Process Modeling Notation (BPMN) を、BPELプロセス記述を表現するグラフィカルなフロントエンドとして用いることを提案している者もいる。この方法の実現性を示すものとして、BPMN仕様には非公式で部分的ではあるがBPMN から BPEL 1.1 への マッピングが含まれている。

BPMNからBPELへのより詳細なマッピングは、BPMN2BPELなどオープンソースのものを含む複数のツールにより実現されている。しかし、これらのツールの開発により BPMN と BPEL の間の根本的な違いが明らかになり、BPMNモデルから人間が理解できる BPEL コードを生成するのは非常に困難、場合によってはまったく不可能であることがわかった[要出典]。さらに困難なのは、BPMN と BPEL の間のラウンドトリップ技術、つまり片方に加えた変更がもう片方に反映されるように、BPMNの図からBPELコードを生成し、オリジナルのBPMNモデルを維持しつつ、生成された BPEL コードを同期させることである。

脚注

[編集]
  1. ^ 英: choreography
  2. ^ 英: sequence
  3. ^ if-then-elseif-else
  4. ^ while
  5. ^ 英: flow、コマンドを並列に実行する。

関連項目

[編集]

外部リンク

[編集]

標準規格

[編集]

BPEL およびビジネスプロセスのサイト

[編集]

BPEL 関連の記事

[編集]
スタブアイコン

この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。