今月Apache ODE (Orchestration Director Engine)チームは、多くの新機能や改善点およびバグ修正を含む1.2のリリース(リンク)を発表した。Apache ODEは、WS-BPEL準拠のWebサービスオーケストレーションエンジンで、BPEL XML文法で記述されたプロセス記述に従い、Webサービスの実行を調整する。
WS-BPELは、元来IBMやMicrosoftによって開発された仕様であり、現在はOASIS Web Services Business Process Execution Language(WSBPEL)TC(リンク)によって保守されている。ワーキンググループには、IBM、BEA、Adobe、JBoss、SAP、 Active.Endpoints、Tibco、WebMethods、Oracleなどが含まれる。
今回のリリースの目玉は以下のとおりである。
- ビジネスプロセス変数を可視化し、プロセスインスタンス外で直接操作可能にする、外部変数(リンク)。たとえば、このメカニズムはプロセスのデータベースやサービス起動アドレスを外部的に構成する場合に使用することができる。
- 拡張機能と共にWSDL HTTPバインディングのサポートで、RESTスタイルのWebサービスの起動を可能にする。
- 2つのコミュニケーションレイヤーのサポート：Axis2に基づいたもの(Webサービスhttpトランスポート)およびJBIスタンダードに基づいたもの(ServiceMixを使用)
- Apache Axis2コミュニケーションの場合、拡張エンドポイント構成はWS-SecurityおよびWS-RMの構成をサポートする。
- 最善｛さいぜん｝の組み合わせの安定性、性能および使用性を実現するための、ちょっとした修正や改善点の長いリスト。
このような新しい機能の他に、Apache ODEは以下の機能を提供している。
- WS-BPEL 2.0 OASISスタンダードおよびレガシーBPEL4WS 1.1ベンダー仕様の並列サポート。
- エンジンに対するハイレベルAPIが、事実上あらゆるコミュニケーションレイヤーとコアの統合を可能にする。
- プロセスのホットデプロイメント。
- コマンドラインやデプロイメント時、詳細な分析および検証を提供するBPELへのコンパイルされたアプローチ。
- プロセス、インスタンスおよびメッセージの管理インターフェイス。
InfoQは、Apache ODEプロジェクトの統括責任者であり 、Apache Software Foundationのメンバーで、IntalioアーキテクトであるMatthieu Riou氏(リンク)にインタビューをおこなった。氏は、 Apache Tuscanyプロジェクトにも寄与している。ODE 1.2における最重要機能について、Matthieu氏は以下のように説明した。
外部変数と呼ばれるものは、非常におもしろいと思います。これまでオーケストレーションエンジンは、ブラックボックスであり、残りのシステムと広範囲にわ たって対話をしますが、ボンネットの下にあるものへのアクセス方法を提供していません。プロセスが実行され、メッセージを受信し操作し、新しいメッセージ を送信しますが、プロセス定義が済むと、実行はかなり不透明です。処理が操作するデータで最も明確です。特にデータがXMLであるWS-BPELでは、従 来のデータストレージメカニズムへのマップがうまくいきません。
そこで、この機能によりユーザはプロセス変数を直接、自分で選択したデータベーステーブルに格納することができます。われわれは単純なマッピング機能を提 供しているので、テーブル構造に対して適度にコントロールすることができます。そこで、このマップ済みの変数に対するすべての読み出しや、書き込みは、そ のテーブルで支持されます。それはかなり単純な機能ですが、レポート作成、Business Activity Monitoring、さらにはプロセスデータのライブ修正に対する大きな可能性を切り開きます。
同様に、この機能を拡張して、RESTfulリソースへのプロセス変数のマッピングをサポートします。その結果、RESTful Webサービスは、プロセスから直接アクセスおよび操作が可能になります。
Matthieu氏がInfoQに語ったことは、ODEでRest Webサービスをサポートするという重要性についてであった。
問題の1つは、現在、WS-BPELが少なくともWSDL 1.1のみです(それをWSDL 2.0向けにアップデートするという取り組みははいようです)。そこで、WSDL 1.1およびそのHTTPバインディングがサポートするものでおこなわなければなりませんでした。正直のところ、それほどないです。
そこでそれを多少拡張し、WSDL 1.1 HTTPバインディングにエレメントを少し追加しました。たとえば、バインディングレベルだけではなくオペレーションレベルにおいてもverbを受け入れ ます。そこからWSDLポートタイプがリソースにマップされ、オペレーションがHTTPメソッドにマップされます。ユースケースがHTTPバインディング がサポートすることの下に今でも収まっている場合、拡張は不要です。
これはおそらくWS-*およびREST純粋主義者には異説に聞こえるかもしれません。しかし、それでもこれはRESTful Webサービスを起動するための比較的クリーンな方法を提供します。すでにWSDLでしている以上にHTTPを乱用しないように注意してきました。
そうは言っても、長期間に及ぶ計画は、RESTfulアーキテクチャーをもう少しネイティブにサポートするODEの機能を拡張することになります。プロセ スをRESTfulにし、一定のインターフェイスに従うことでそれらを公開しようと考えています。またWS-BPEL を大幅に拡張するという計画もあります。すでにこれについての独自の仕様があります。RESTful BPEL(リンク)というものです。また、それを見て、フィードバックをくれるように皆に言っています。
SCAおよびBPELの統合について：
事実、これはODEおよびApache Tuscanyチーム間の共同作業として、すでに進行中です。正常に稼動している単純なシナリオがあります。そこには、SCAコンポジションおよび BPELプロセス間の対話があります。近ごろのTuscany SCAリリース(1.2.1)には、ODEがあり、BPELプロセスの使用を実証しているサンプルがあります。
要求/応答の実装向けのWS-Addressingをサポートする計画については、以下のような回答を得た。
すでにWS-Addressingを一部サポートしています。われわれにとっての価値は、インクルードする能力、プロセスが送信するEPR、プロセスイン スタンスIDについての追加情報です。その結果、たとえば対話を処理するためにプロセスの相関は不要になります。プロセスインスタンスは、受信メッセージ のWS-AddressingヘッダーにあるEPRを使用して、互いに見つけ出します。
さらにサービスが実装されて、こうしたヘッダーを同様に使用し、それを起動する場合にプロセスエンジンにそれらを提供するとき、相関を完全に回避することができます。
Matthieu氏は、 BPEL4PeopleおよびWS-HumanTaskを実装する計画の有無について、以下のように答えた。
ODEのチャーターは、WS-BPELよりも大きく、またオーケストレーションおよびヒューマンワークフローの両方を含んでいます。これまで、われわれは よりBPELおよびオーケストレーションにフォーカスしてきましたが、コミッターの一人(かつて引き合いに出された、RESTful BPEL仕様を書いたAssaf Arkin氏)が、現在Singleshotと呼ばれるすばらしいタスクマネージャに取り組んでいます。Railsに実装され、人に優しい側面を付け加え ることで、われわれのBPELエンジンを補完するものとなるでしょう。
その一方で、Intalioも同様に、Tempoと呼ばれるオープンソースWorkflow製品を開発しました。それは、BPEL4Peopleホワイトペーパーを実装するものです。
最後になりますが、peopleActivityのようにBPEL4Peopleに含まれているWS-BPEL拡張機能をサポートする計画があります。ま だ多少時期尚早ではありますが、コミュニティの他の人が、それよりも早くこの実現に関心を持ったなら、われわれとしては確実にありがたいと思います。
ODEについて忘れてはならない最も重要なことの1つは、Apacheプロジェクトであるということです。そのようなものとして、ビジネスフレンドリーな ライセンスのもと開発しています。どんな種類の寄与も歓迎します。コードのみならず、フィードバックやドキュメンテーション、テスト、あるいは単に熱意で も構いません。
今回の新リリースで、Apache ODEはオープンソースBPELベースのオーケストレーション実装として、先駆的な地位を強化している。また、ODEを拡大して、完全なヒューマンワークフロー実装にする取り組みも進行中である。