Business Process Execution Language（あるいは BPEL）とは、実行可能なビジネスプロセスモデリング言語である。しかし、BPELは特定のセマンティックやプロセス構造の要素を持っていないため、考えられるすべてのビジネスプロセスをモデル化し実行することは不可能である。このため、BPEL はたとえば Java のようなプログラミング言語とともに用いられたり、ワークフロー統合ブローカーエンジンなどの商用製品に備わっている独自のスクリプト言語によって拡張されることが多い。BPEL の起源は WSFL と XLANGにさかのぼることができる。BPEL は XML によってシリアライズ可能で、"大規模プログラミング"の概念を実現するものである。大規模プログラミングと"小規模プログラミング"の概念は、ビジネスプロセスで典型的に見ることができる長時間継続する非同期のプロセスを記述する際の二つの側面によって分類することができる。BPEL が IBM とマイクロソフトによって開発されたのは、BPMI.org (Business Process Management Initiative) が開発した初期の言語BPMLに対抗するためであった。この背景については幾つかの議論があるが、おそらく、さまざまなグループで詳細について合意できない性格によるものと思われる。ワークフロー理論が先祖である BPEL とは異なり、BPML はPi calculusから着想された。このため、BPML は完全で定式化された文法を持つことになり、市場には強力なBPMLの製品が登場することとなった。このため、アプリケーションサーバ開発を統一する標準に対して統制力を持ちたいと考えていた IBM とマイクロソフトは懸念を持った。今日では、過去の BPEL と BPML との違いはほぼ学術的なものになっている。BPEL の文法が勝利を収め、BPML の意味論が勝利を収めた。IBM とマイクロソフトの力により、今日 BPEL の名前が残っている。BPEL は徐々にBPML へと近づく方向に進化している。BPML が形式上完全であるため、これは不可避である。大規模プログラミングは、抽象度の高いプロセスのことであり、BPELではこのようなプロセスを抽象プロセスと呼んでいる。BPELの抽象プロセスは、規格化された方法で表現された振る舞いを表している。抽象プロセスは、メッセージを待つ、メッセージを送信する、失敗したトランザクションの補償をするなどの処理が記述されている。それとは対照的に、小規模プログラミングは、1つのトランザクションで終わるような、生存期間の短い振る舞いを扱う。小規模プログラミングと大規模プログラミングでは異なった言語が必要であるという発想からBPELは生まれた。BPELにはもともと10の設計目標があった:BPELはオーケストレーション (Orchestration) 言語であり、コレオグラフィ (choreography) 言語ではない（参照）。オーケストレーションとコレオグラフィの主な違いはその範囲である。コレオグラフィモデルがある参加者からのビュー（たとえばピアツーピアモデル）に焦点を置いているが、オーケストレーションモデルはすべての関係者と関連したやりとりを含み、システムの全体的なビューを与える。オーケストレーションとコレオグラフィの区別は次のようにたとえられる：オーケストレーションが、オーケストラの指揮者のような集中管理の振る舞いを記述し、コレオグラフィーは振り付けされた (choreographed) ダンスで、ダンサーが互いのペアの振る舞いに反応するように、それぞれの参加者が外部のイベントに基づいた処理を実行する、分散制御の振る舞いを記述する。BPELの現代的なビジネスプロセスに対する焦点、さらにWSFLおよびXLANGの歴史から、BPELはWebサービスを外部の通信メカニズムとして採用することになった。そのため、BPEL のメッセージング能力は、入出力されるメッセージを記述するためのWSDL1.1の使い方に依存する。メッセージの送信受信を行える能力を提供することに加えて、BPELプログラミング言語は下記の項目をサポートする：BPEL の'if-then-elseif-else' や 'while' などの制御構造や、変数操作の機能は、ロジックを提供するための'小規模プログラミング'言語を使うことに依存している。すべての 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 技術委員会 は 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だけでは、必ずしもひとつのビジネスプロセスすら実現できない。これが意味するところは、現場でのみ明らかになる。たとえて言うなら、演算子がないために完全なコードを書けないプログラム言語を持っているようなものである。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 コードを同期させることである。

出典:wikipedia