BPEL入門書
（１）BPELとは
BPELはＸＭＬベースのワークフロー記述言語です。
２００３年５月５日にMicrosoft、IBM、Siebel Systems、BEA、SAPから
Business Process Execution Language for Web Services Version 1.1 が
共同提案されました。
BPELはこのBusiness Process Execution Languageの頭文字を取っています。
このバージョンはBPEL4WSと略す事が多いです。
BPELはこれをベースにOASISにて Web Services Business Process Execution Languageと
名前を変え、BPELの標準化作業が行われています。
こちらは前バージョンとの違いを強調し、WSBPELと略す事が多いです。
BPELは直訳するとビジネスプロセス実行言語です。
ビジネスプロセスの実行を定義・記述するために存在します。
ビジネスプロセスとはなんでしょうか。
「ビジネスが完結するまでの一連の流れ」と理解すればよいと思います。
機会的な処理だけでなく、人の処理も含まれます。
英語ですが、BPELの役割はOrchestrationやChoreographyと表現されることが多いです。
独立性の高い業務・機能をサービス（後述）と呼びますが、
これを指揮し、サービスの集合全体（≒ビジネス）の振る舞いを定義するための言語になります。
（２）SOAとの関連
BPELはSOAの主要技術として紹介されることが多いです。なぜでしょうか。
この問に答える前にまず、SOA自体何者か考えて見ましょう。
SOAとは
「ビジネスを構成する全ての物はサービスであり、システムをサービスの集まりとして考え、分析や設計を行う」
という思想に過ぎません。
では、この思想の子細について学んだ方はいらっしゃるでしょうか。
おそらくほとんどの方の答えがNoだと思います。
なぜならばこの思想が記述されている日本語の文献がほとんど無いからです。
もし興味がある方がいればこちらをご覧ください。
OASIS SOA Reference Model 技術委員会
紫色の枠内にあるDocumentsを選択すると出てくるwd-soa-rm-pr1というファイルをご覧ください
英文の論文などまでは、さすがに手が広がりませんので
私が知っているのはここの文献ぐらいですが、サービスとはどういうものかなど
概念レベル、意味論が語られています。
これを踏まえBPELがなぜSOAの主要技術となりうるのか考えて見ましょう。
ざっと抜き出すとサービスには以下� 銑い里茲Δ覆發里�求められますが、
SOAを実現する為に、サービスが備えるべき特性をBPELが与えられるか否か。
相性が良い部分と、まかなえきれない部分がある事が分かります。
−−−
�‥�達可能性（Reachability）
サービス間をつなぐか否か。ビジネスプロセス内に取り込むかどうかで定義する事が出来ます。
しかしBPELだけではビジネスプロセス間の到達可能性については定義できません。
ビジネスプロセス間のルーティングを担当するESB※が必要です。
※ESBにはビジネスプロセス間を取り持つ為の仕様、
WS-CDLが実装されるべきですが各社どう実現しているのかまで存じません。
��可視性（Visibility）
スコープという概念がBPELには存在します。トランザクションのような物なのですが、
補正のようなリカバリ処理の単位としてスコープを定義していくことができます。
子細は勉強中なので良く分かりませんが、
JAVAパッケージにおいてクラス定義で可視性を定義できるように、
スコープに内包するサービス側で公開／ビジネスプロセス内／スコープ内など
可視性を定義できれば可視性の定義は十分と言えます。
（誰か教えてください・・・）
��自覚（Awareness）
・サービス使用者をサービス提供側が認識していること
・サービス自体を未知なるサービス使用者に対して知らせようとすること
これが自覚をもったサービスです。
ビジネスプロセス内に存在している自分以外のサービスおよびビジネスプロセス
を利用している人がサービス使用者ですよね。
ビジネスプロセスの構成を知る術がサービス側にあるかというと無いような気がします・・・
�ぜ�発性（Willingness）
自発性のないサービスとは、自覚が足りず、他のサービス利用者とのやりとりに
関して消極的なサービスです。
BPELには自発性を促すような仕組みは・・・ないかな。
−−−
こんな感じですが、どうでしょう。
以外にSOAと関係なかったりするかな・・・なーんて。
BPEL自体は振る舞いの順序性の定義が
得意なんですが、
SCAの
解説通り
SOA的にはビジネス（サービス郡）を構成（Composition）することがBPELの役割であっているような気がします。
−−−
なんか新しい話が出てくると先をあらそって同じような話が繰り返されていて
嫌なんですが先ごろ各社が発表したSOA成熟度なんてものを、自分なりに書いてみました。
�．機璽咼垢旅獣曄別榲�：サービスの定義づけ／インタフェースの整理）
�▲咼献優好疋瓮ぅ麁發寮鞍�（目的：ビジネスプロセスの構築／ビジネスプロセスの構成の可視化）
��BAMの導入（目的：ビジネスプロセスの動作状態の可視化）
��BPRがかけられる体制作り
��ESBの導入（目的：ビジネスドメイン間の結合）
�Ε轡潺絅譟璽轡腑鵑砲茲觧�前BPR
どうでしょう。こう書いて見るとBPELは
�↓��きΔ亡悗錣辰討�ますね。結構重要かも。
（３）オブジェクト指向とサービス指向の違い
＜オブジェクト指向＞
オブジェクト指向アーキテクチャでは、全ての物はオブジェクトであり、ソフトウェアをオブジェクトの集まりとして考え、分析や設計を行う
＜サービス指向＞
ビジネスを構成する全ての物はサービスであり、システムをサービスの集まりとして考え、分析や設計を行う
考え方の違いは若干オブジェクト指向の方が守備範囲が広い程度のような気がします。実際、思想としては、まとまりの単位の独立性がより高いのがサービス指向という以外特徴的なところを見出せません。
まあ、独立性が高いという前提でいろいろ思考が発展していけたりもするわけで一概にどちらがいいのかは・・・難しいところです。
ただしこれを用いて開発を行うとなると、決定的な違いがあります。
オブジェクト指向の方が歴史も長く優位です。
・標準モデリング言語が決まっている
・適用例が豊富にある
・設計（具体化・詳細化）に用いる際の指針について良書が多くある
実際に開発に使うのに際してここらへんてとても大事ですよね。
あれ、、BPMNは？
確かにビジネスを対象としたモデリング方法としてBPMNがありますね。
しかも、BPMNはUMLに取り込まれる予定のようです。
でも、基本的なサービス指向とは？という根源が固まる前から
どんどん仕様が、拡張されているように見受けられます。
BPEL仕様に併せる※など、いろいろ考えられているようですが、
そもそもBPEL＝SOAではないのでよく考えて欲しいものです。
独立性の高い物を扱っており、それを生かした分析・設計ができるように
しなければならないということを
十分に踏まえて仕様を決めて欲しいものです。
※BPMN⇒BPEL変換てアクティビティ⇒サービスなのかな？
BPELで可能な振る舞いの順序性定義がBPMNでも出来るので、
ツールベンダさんBPMN⇒BPELをがんばっているような気がするのですが、
アクティビティ自体がBPELで構成されるというのが正しいような気がします。。
ESB的なところの記述をBPMNには期待し、BPMNからの展開先はBPELだけではなく、ESB定義へも出来ないと意味が無いのではないでしょうか。。
（BPMN詳しくないのでどなたかフォローを）
（４）サービスとは
The performance of work (a function) by one for another.
・The capability to perform work for another
・The specification of the work offered for another
・The offer to perform work for another
（５）ESBとは
（６）WS-CDLとの関係
（７）BPELの位置づけ
（８）BPELの課題
（９）BPELエンジンを導入しよう
（10）BPEL導入のデメリット
（11）BPMNとの関係
（12）おまけ