Keith Swenson氏は、新しい記事(リンク)を始めるにあたり、こんにちのBPM製品におけるBPELの使用を評価している。
さしあたり「Business Process Execution Language」または「WS-BPEL4WS」が、BPM空間における実行のスタンダードであるというのが世間一般の見解のようである。同時に、こん にち市場に出回っているBPMやワークフローのほとんどは、BPELを使うことなく、良く動作する。BPELを実装しない製品は、単に沼地で足を引きずっているにすぎないと言うものもいる。そうした製品がBPELですることをできないと言うものもいる。誰を信じるべきなのか?近ごろ、 InfoQにある記事(参考記事・英語)が掲載された。それはBusiness Process Modeling Notation (BPMN)で描かれた特定のプロセスシナリオを取り、BPEL.を使用して実装できない理由を詳細に調査したものである。しかしながら、そのプロセス は、BPMNを直接実行するシステムで実行可能である... BPMNを直接実行することができるので、質問が持ち上がる。 そもそもなぜBPELに変換するのか?
Keith氏によると、「BPMをサポートする真の唯一の方法として」BPELを促進する多くのベンダーや出版物(参考記事)があるそうだ。実際には他のテクノロジー(参考記事) をベースにした、多くのBPM製品がある。結果として、潜在ユーザは「自分のやりたいことにBPELは適切なのか?」という質問をするかもしれない。
Keith氏は、BPELの人気を以下のような(たいていその支持者による)想定によるものとしている。
- プロセスを作成している人は、プログラマである
- プロセスにおける活動は、XMLデータの送受信または変換のみである
- どんな標準でも、非標準より優れている
以上のことを分析し、Keith氏は最初の2つは、
...状況によっては有効である。EAIと呼ばれる製品カテゴリは実際、主にプログラマによって構成され、データの送受信および操作のみを必要とする。そ こでEAIに関しては、BPELは妥当な選択かもしれない。しかし、多くのBPM製品が、プログラマ以外の人(ビジネスピープル)によって構成されるよう に意図されている(そして、それがそれらをビジネスプロセスと呼ぶ理由である)。BPEL以外のアプローチは、プログラマ以外の人に安全に、そして信頼できる形で、プロセスを練ることを可能にする。これらのプロセスは、プログラマが立案するプロセスとは質的に異なり、EAI型の「BPM」に精通している多 くの人は懐疑的である。しかしそれは基本的に、プロセスの設計者はプログラマであるという仮定に基づいた、回りくどい推論である。とは言うものの、ビジネ スピープルが初めのプロセス図を描き、それからプログラマが修正すると考えているものもいる。しかし、プログラマがまったく関係ない他の状況もあり、そう した場合、BPELはお粗末な選択である。
最後の想定に関して、Keith氏はもっと「市場商品」を検討し、それから現実を検討している。
BPELが正しい標準であるという抗し難い「雑誌」による証拠があるので、BPELをサポートしない人は単に怠けているか、市場を破壊しようとしていると 思っている。こうした人にとっては残念なことであるが、プロセスの世界は想像している以上に、本来もっと複雑である。アプローチのバリエーションは単にベ ンダーの思いつきではなく、実際プロセスのサポートを必要としたバリエーションに対する適切な反応である。人びとは本当の要求を忘れてはいけない。 BPELが要求に応えるとき、 1つのサイズですべてに適合するとむやみに想定してはいけない。
Keith氏は、BPELをBPMNベースのプロセス定義の直接的な実行に置換することを提案し、Fujitsu BPM Studioがこれをおこなう様子を示している。以下のように述べ、記事を締めくくっている。
なぜまたアナリストはBPELを推奨するのか?わたしにとっては、制限にすぎないと感じる。
BPELやBPMに関するとまどいが、業界全体(参考記事)に広がり続けているようである。未だに、もっとも基本的なBPM問題について、合意にいたっていない。
- BPMはビジネス上の規律か、それともソフトウェアエンジニアリングか?
- ビジネスプロセスを実装(自動化)するのは、誰の責任か?
- プログラミングをせずに、設計から配置に移行するよう目指すべきか?
- ビジネスプロセスを維持するのは誰の責任か?
こうした問題で合意を得ることのみで、BPELやBPMN/BPELの関係の議論を適切に構成することができる。