ビジネスプロセス実行言語

BPELには当初、10の設計目標がありました。

1. Webサービス記述言語（WSDL）1.1を使用して定義されたWebサービス操作を介して外部エンティティとやり取りするビジネスプロセスを定義し、それらのプロセス自体もWSDL 1.1を使用して定義されたWebサービスとして表現します。これらのやり取りは、ポート定義ではなくポートタイプ定義に依存するという意味で「抽象的」です。
2. XMLベースの言語を使用してビジネスプロセスを定義します。プロセスのグラフィカルな表現を定義したり、プロセスの特定の設計方法論を提供したりしないでください。^{[ 9 ]}
3. ビジネスプロセスの外部ビュー（抽象ビュー）と内部ビュー（実行可能ビュー）の両方で使用されることを想定した、一連のWebサービスオーケストレーションの概念を定義します。このようなビジネスプロセスは、通常、他の同様のピアエンティティと相互作用しながら動作する単一の自律エンティティの動作を定義します。各使用パターン（抽象ビューと実行可能ビュー）にはいくつかの特殊な拡張機能が必要になることが認識されていますが、これらの拡張機能は最小限に抑え、インポート/エクスポートや、2つの使用パターンを関連付ける適合性チェックなどの要件に対してテストする必要があります。
4. 階層型とグラフ型の両方の制御方式を提供し、それらを可能な限りシームレスに組み合わせて使用​​できるようにすることで、プロセスモデリング空間の断片化を軽減できるはずです。
5. プロセスデータと制御フローを定義するために必要なデータを単純に操作するためのデータ操作機能を提供する。
6. プロセスインスタンスを識別するためのメカニズムをサポートし、アプリケーションメッセージレベルでインスタンス識別子を定義できるようにする。インスタンス識別子はパートナーによって定義され、変更される可能性がある。
7. 基本的なライフサイクルメカニズムとして、プロセスインスタンスの暗黙的な作成と終了をサポートします。「一時停止」や「再開」などの高度なライフサイクル操作は、ライフサイクル管理を強化するために将来のリリースで追加される可能性があります。
8. 長期にわたるビジネスプロセスの一部における障害復旧をサポートするために、補償措置やスコープ設定といった実績のある手法に基づいた、長期実行トランザクションモデルを定義する。
9. プロセスの分解と組み立てのモデルとして、Webサービスを使用する。
10. 可能な限り、Webサービス標準（承認済みおよび提案済み）に基づいて、構成可能かつモジュール化された方法で構築する。

BPELはオーケストレーション言語であり、コレオグラフィー言語ではありません。オーケストレーションとコレオグラフィーの主な違いは、実行可能性と制御です。オーケストレーションは、他のシステムとのメッセージ交換を伴う実行可能なプロセスを指定し、メッセージ交換のシーケンスはオーケストレーション設計者によって制御されます。コレオグラフィーは、ピアツーピアの相互作用のためのプロトコルを指定し、相互運用性を保証するために交換されるメッセージの正当なシーケンスなどを定義します。このようなプロトコルは、多くの異なる実装（それに準拠するプロセス）を可能にするため、直接実行することはできません。コレオグラフィーは、関与する各ピアに対してオーケストレーション（BPELプロセスの形式など）を作成することによって実現できます。オーケストレーションとコレオグラフィーの区別は類推に基づいています。オーケストレーションは、分散システム（多くの演奏者で構成されるオーケストラ）の動作を（指揮者によって）中央で制御することを指し、コレオグラフィーは、中央制御なしでルール（コレオグラフィー）に従って動作する分散システム（ダンスチーム）を指します。

BPELは、最新のビジネスプロセスに重点を置いていることに加え、WSFLとXLANGの歴史を踏まえ、外部通信メカニズムとしてWebサービスを採用しました。そのため、BPELのメッセージング機能は、送受信メッセージの記述にWebサービス記述言語（WSDL）1.1を使用することに依存しています。

BPELプログラミング言語は、メッセージの送受信を可能にする機能を提供するだけでなく、以下の機能もサポートしています。

• プロパティベースのメッセージ相関メカニズム
• XMLおよびWSDL型変数
• 複数の言語で式やクエリを記述できる拡張可能な言語プラグインモデル：BPELはデフォルトでXPath 1.0をサポートしています
• if-then-elseif-else、while、シーケンス（コマンドを順番に実行できるようにするため）、フロー（コマンドを並列に実行できるようにするため）などの構造化プログラミングの構成要素
• ローカル変数、障害ハンドラ、補償ハンドラ、イベントハンドラを用いてロジックをカプセル化するためのスコープシステム
• 変数への同時アクセスを制御するためのシリアル化されたスコープ。

OASIS技術委員会がWS-BPELの範囲外と判断したため、WS-BPELには標準的なグラフィカル表記法はありません。一部のベンダーは独自の表記法を考案しています。これらの表記法は、BPELのほとんどの構成要素がブロック構造（シーケンス、while、pick、scopeなど）であるという事実を利用しています。この機能により、 Nassi–Shneiderman図を彷彿とさせるスタイルで、 BPELプロセス記述を構造図の形で直接視覚的に表現できます。

BPEL プロセス記述をキャプチャするためのグラフィカル フロントエンドとして、実質的に異なるビジネス プロセス モデリング言語、すなわちビジネス プロセス モデル表記法(BPMN) を使用することを提案する人もいます。このアプローチの実現可能性を示す例として、BPMN 仕様には BPMN から BPEL 1.1 への非公式かつ部分的なマッピングが含まれています^{[ 10 ]}。BPMN から BPEL へのより詳細なマッピングは、BPMN2BPEL として知られるオープンソース ツールを含む多くのツールで実装されています。^{[ 11 ]}しかし、これらのツールの開発により、BPMN と BPEL の間に根本的な違いがあることが明らかになり、BPMN モデルから人間が読めるBPEL コードを生成することが非常に困難、場合によっては不可能になっています。さらに難しいのは、BPMN から BPEL への往復エンジニアリングの問題です。これは、BPMN ダイアグラムから BPEL コードを生成し、元の BPMN モデルと生成された BPEL コードを同期させ、一方への変更が他方に伝播されるように維持することです。

BPEL の制御構造である「if-then-elseif-else」や「while」、および変数操作機能は、ロジックを提供するために「小さなプログラミング」言語を使用することに依存しています。すべての BPEL 実装は、デフォルト言語として XPath 1.0 をサポートする必要があります。しかし、BPEL の設計では拡張性を想定しているため、システム構築者は他の言語も使用できます。BPELJ ^{[ 12 ]は、Java が BPEL 内で「小さなプログラミング」言語として機能することを可能にする JSR 207 [ 13 ]}に関連する取り組みです。

分散型ビジネスアプリケーションにおいてWebサービスが広く受け入れられているにもかかわらず、人間とのやり取りが欠如していることは、多くの現実世界のビジネスプロセスにとって大きな課題であった。

このギャップを埋めるため、BPEL4PeopleはBPELをWebサービスのオーケストレーションだけでなく、役割に基づいた人間の活動のオーケストレーションにも拡張しました。

バージョン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ドキュメント/リテラシースタイルのサービスインタラクション用）
• ローカルで宣言されたメッセージ交換（受信および応答アクティビティの内部相関）
• 抽象プロセスの明確化（構文と意味論）
• 各アクティビティで式言語のオーバーライドを有効にする