コンポジットサービスを作る主要なメンバーらは、"サービス指向のアーキテクチャとインテグレーションのためのパターン化された言語に向けて”（英語） の中で、次のように定義しています。
- 利用方法の簡素化 いくつかのビジネスサービスが、一緒に多くのコンシューマーによって使われるとき、参加しているすべてのサービスとそれらの協調ルールについての知識を明らかにすることにより、コンシューマ実装がより複雑になります。コンポジションサービスの作成において、参加しているサービスをカプセル化することと、それらの呼び出しルールを強制することは共に、それらの使用をかなり単純化することができます。
- 再利用性の改善 計画されたものではない新たなソリューションは、しばしば、利用可能なサービスから組み立てることができます。たとえそれらが、解決するための特定のセットの構築のために設計されたとしても、既存のビジネスサービスは、予想しなかったソリューションを実装するために、他の方法に組み込まれることができます。そのうえ、サービスの可用性は、ともすれば考慮されないかもしれない新しいソリューションを提案します。これらの新しいソリューションは、比較的少ないサービスの開発または機能強化によって、多くの場合、安価で高速なものを作ることができます。
- ソリューションの分割、視覚化、制御と変更の管理 コンポジットサービスは、総合的なソリューションに対して分割しているメカニズムとして用いられることができます。EJBでのローカルやリモートインターフェースの場合と同様で、コンポジットサービスを導入し、それらのインターフェースのいくつかだけを外部のユーザーに公開することで、コンシューマが参照できるものを制御することができます。これにより、コンシューマにとって、最小若しくはインパクトの無いサービス間の相互接続だけでなく、配下にあるサービスの実装の変化による要件の変化に対し、素早く反応するためのソフトウェアアーキテクチャ(コンポジットサービス実装)に内在している能力をサポートします。
一つは、クライアント要請を満たすために構成要素サービスと協調する方法の仕様を統合することを考慮したコンポジット設計、もう一つは、コンポジション設計によって作られた仕様を実行することにより、サービス間の協調を実際に成し遂げるための方法を考慮したコンポジット実装という側面です。
この記事では、設計と実装の観点から見た、サービスコンポジションの主なアプローチに関して記述しています。
コンポジションの設計
コンポジションの設計は、既存サービスのセットをベースとしたソリューションの設計と関係します。その役割は、コンポジションに含まれるサービスのリストや相互作用の方法、そしてコンポジションの接続形態を明確にすることです。サービスインタラクション
"Service–Oriented Composition in BPEL4WS"（英語・PDFファイル）によれば、コンポジションのインタラクションには、以下の二つの主要な設計アプローチがあります。- 階層的なコンポジション
- 対話的なコンポジション
図1 階層的なサービスコンポジション
このコンポジションのアプローチは、階層的に分解されるシステムの実装に自然とフィットするものです。階層の全てのレベルが、低レベルでの(コンポジット)サービスの実行を協調する、個々のコンポジットサービスとして実装されます。それは、一連のアクティビティを作成することによるワークフローシステムのハイレベルなソリューションをモデリングするための共通の方法でもあります。そのアクティビティのそれぞれが、低レベルのビジネスプロセスや、人やプログラムによって実行される何らかのタスクに対応しています。すべてのコンポジットサービスが、それを利用する外部のシステムから監視、もしくは割り込みが発生している間は、元々の呼び出しを除いた全てのサービスコンシューマとの機能的なインタラクション1をサポートしません。
ブラックボックスのコンポジションアプローチ(即ち、階層的なコンポジション)は、複雑なものを扱う方法として非常に強力なものである一方、コンシューマが、サービスの実行結果を中間結果として、コンポジットサービスの実行の制御を必要とする状況もあります。そのような実装には、対話的なコンポジションがサポートされています。この場合も、コンポジットサービスの実装がサービスコンシューマから完全に見えないようになっていますが、所定の中間結果を見ることができます。(即ち、グレーボックスです)
これは、コンポジットサービスとサービスコンシューマのための公開されている複数のインターフェースにより、明確な対話状態(対話状態と実行状態の特徴に関しては[4]を参照して下さい)をサポートすることによって実現可能となります。つまり、初めに、あるサービスの呼び出しを行って中間結果を受け取り、それをベースに処理を制御します。(図2)
図2 対話的なサービスコンポジション
このタイプのコンポジションは、コンシューマとプロバイダのインタラクションを、データと制御のシグナルをやり取りするピアとして見ることができます。
両方のインタラクションのスタイルは、コンポジション設計の実現可能な方法です。厳密な階層的なサービスコンポジションの利用方法は、ワークフロー技術の成功によって立証されているように、複雑なビジネスプロセスのモデリングアプローチとして有用です。一方、対話的なサービスコンポジションは、ネゴシエーションや結果のモニタリングなどといった、コンシューマとサービス間のメッセージのインタラクションを明確にモデリングすることを通じて、汎用的なビジネスインタラクションを容易にする表現力を持っています。
コンポジションの接続形態
コンポジットサービスの設計は、サービスインタラクションの定義を必要とするだけでなく、コンポーネントのセットやそれらの実装に対する接続形態も必要となります。コンポジットサービスの接続形態には、以下の二つの主要な設計アプローチがあります。"Service–Oriented Composition in BPEL4WS"(英語・PDFファイル）
- メディエータベース
- Peer-to-Peer
メディエータベースの接続形態(図3)は、サービスコンシューマとコンポジションに加わっているその他のサービス(コンポーネントサービス)の実行の制御の相互作業を行う、特別な役割をもったメディエータと呼ばれる単体のサービスを担っています。
図3 Mediatorベースのコンポジションの接続形態
メディエータベースの階層的なサービスの場合、 メディエータが、特定の制約内で特定の目的を達成するための、コンポーネントサービスの呼び出し順を定義したオーケストレーションスキーマを実行します。異なるアプローチとして、オーケストレーション言語/エンジンを含む、OWL-Sコンポジションや Petri nets等は、メディエータの実装として利用することが可能です。
メディエータベースの対話的なサービスの場合、 メディエータは、コンシューマの入力ベースとしたサービスの状態と状態遷移を実装します。典型的なメディエータの実装は、遷移システムや有限状態マシンをベースとしています。
peer-to-peerの接続形態の場合、メディエータサービスという概念はありません。参加している全てのサービス(コンポーネントサービス)が、(一部の)コンポジットサービスを実行します。(図4)
図4 Peer-to-peerコンポジションの接続形態
この場合、あるコンポジションは、メッセージングテンプレートとそれにプラグインできるコンポーネントサービスとして定義されています。ターゲットの振舞いは、システムによって実現されるべき許可されたメッセージ交換のシーケンスの集まりとして定められています。一般的に、この接続形態は対話的な状態(対話的なインタラクションの実装に必要なもの)をサポートするのに必要なメカニズムが欠けているので、階層的なサービスの実装のためだけに利用されます。
コンポジション実装の選択
サービスメディエータの最も簡単な実装方法は、一般的なプログラミング言語を使用することだと思われます。(図5)
図5 コンポジットサービスのプログラム実装
不運なことに、このソリューションにはいくつかの欠点があります。
- コンポジットサービスのオーケストレーションの部分が、ハードコーディングにより、非常に柔軟性の無いものとなります。コンポジットサービスの全ての変更があると、サービスメディエータの再実装が確実に必要となります。
- このアプローチは、その場その場のやり方でサービスが他のサービスを呼び出すという、所謂"サービスのスパゲティ"実装によく陥ります。サービスの呼び出しの網目状の性質、別々のチーム、異なるサービスの開発、といったものによって、たいていの場合は、保守できない"サービスのスパゲティ"に陥ります。
- 対話的なコンポジットサービスの実装や非同期に呼び出されたサービスの同期化のための必要条件が、全体的な実装を非常に複雑なものにし、コンポジットアプリケーションにスレッドのサポートを必要とします。サービスコンテキストのサポートのための必要条件として、通常、サービスコンテキストをサポートするための全てのコンポジットサービスに対する、特別なデータベースを作成する必要があります。
- コンポジットサービスの実装は、関係したサービスが失敗した際に正しい振舞いを保証するための、ある種のトランザクションのサポートが必要となります。
コンポジットサービスの実装のためのフレームワークがいくつか存在する(例えば WS-CAF（英語）)という事実をよそに、コンポジットサービスのプログラム実装は正しいアプローチではないように思われます。
コンポジットサービスの実装の代わりとなりうるアプローチとして、イベントベースのコンポジションがあります。 このコンポジション実装は、イベントベースのサービスインタラクションを基本としています。
サービスコンシューマは、パブリッシュ/サブスクライブを仲介としてイベントをパブリッシュし、それらを実際のサービスコンシューマに渡します。(図6)
図6 パブリッシュ/サブスクライブを通じたサービスインタラクション
このケースの場合、パブ/サブエンジンは全ての仲介役としてサービスコンシューマとプロバイダの間の分離したレイヤーを提供し、それらは、コンポジットサービスの非常にフレキシブルな実装を可能とします。コンポジットサービスは以下のように実装されます。(図7)
図7 イベントを利用したコンポジットサービスの実装
そのサービスコンシューマは、イベントに許可されたサービスのセットに対し(パブ/サブエンジンを通じて)渡された起動イベントを送信します。それぞれのサービスは、次々に代わりとなるメッセージを送信し、さらに別のサービスのセットを(パブ/サブエンジンを通じて)呼び出します。このイベントのシーケンスは、効果的にコンポジットサービスを作成します。パブ/サブを通じたコンポジットサービスの実装には、以下の特徴があります。
- プログラムでの実装と比較して、非常に柔軟です。サービスのセットの変更により、特定のトピックに認められたサービスを変えることによって、コンポジットサービスの実装を完全に変えることができます。あるいは、同じことはコンシューマが本来のイベントを送るトピックを変えることによって実現することができます。
- イベントベースの実装は、コンポジットサービスコンテキストに対し、はっきりした場所を提供しません。これは、コンポジットサービスの実装をより複雑にします。その解決法の一つとして、コンテキストデータをイベントコンテキストを付加します。通常、そのメッセージは大きくなり、さらなるネットワーク使用量の増加とパフォーマンス低下をひき起こします。
- イベントベースの実装は、コンポジットサービスのインスタンスの概念を備えていません。そして、それはコンポジットサービスのインスタンスを実装しているイベントの協調を非常に難しいものにします。
- サービスの参加に失敗した場合に、正しい振舞いを保証するためのトランザクションのサポートに関して、これもまた、どんな方式での実装も非常に難しいものとなります。
図8 オーケストレーションエンジンを利用したコンポジットサービスの実装
この実装は、コンポジット実装のための一般的な言語の代わりにオーケストレーション言語を使用することで、プログラム実装を改善しています。 これは、ビジュアルエディタを利用することでコンポジションロジックのプログラミングや保守が可能となります。そして、特にこの種のプログラミングを単純化するように作られています。それは、非同期呼び出し、状態管理、等に対するビルトイン機能を提供しているオーケストレーションエンジンのパワーを利用することもできます。コンポジットサービスの実装に対するオーケストレーションエンジンの利用により、以下の利点があります。
- オーケストレーション言語は、オーケストレーションの実装に適しており、大抵の場合コンポジットサービスの実装を容易にします。
- プログラム追加は、ビジュアルエディタの利用を通じて簡単に実現できます。
- オーケストレーションエンジンは、コンポジットサービスの実装に必要なオーケストレーションのインスタンスやコンテキストをネィティブサポートしています。
- オーケストレーション言語で実装した保証に関するサポートとして、トランザクション実装のサポートがとても簡単になります。
上記を踏まえ、議論した三つのアプローチから、オーケストレーションベースの実装は、コンポジットサービスの作成の最も現実的な方法であるように思います。
まとめ
サービスコンポジションは、以下の利点によりSOA実装の重要な役割を果たしています。
- 再利用性の改善。コンポジットサービスは、既存サービスの再利用のための自然な方法を提供します。それにより、サービスプロバイダがサービスコンポジションを通じて、付加価値をつけることができます。
- 開発期間の短縮。新たなソリューションをより早く構築することができます。多様なレベルのサービス(それらが作成可能であるとして)があることで、結合や管理のメカニズムと共に、新しいサービスやソリューションを時間と労力を削減して構築することができます。特に、プロトタイプを操作することで、既存製品のサービスの品質で素早く組み立てることができます。
- 強化されたセキュリティと監査能力。コンポジットサービスは、配下にあるサービスのセットへのアクセスの単一ポイントを意味します。この単一ポイントのアクセスは、サービス呼び出しの規約の簡単な方法を提供し、コンポーネントサービスへのアクセスの制御と測定を可能とします。
- 重複の低下。冗長性が低下あるいは取り除かれます。同じビジネスの機能をいくつも複製する代わりに、必須の機能をインプリメントする単一のビジネスサービスを、複数の作品で再利用されることができます。
- 変更可能性の強化。同一配下にあるサービスが多くのコンポジットサービスの一部でありえるので、企業全体に渡り、単一の場所に機能の修正をおこないます。よって、コンポーネントサービスの実装の変更は、このサービスを利用しているすべてのコンシューマが利用することができます。
最終的に、私たちは、サービスコンポジションの実装のためにオーケストレーションエンジンの利用を推奨します。
著者について
Boris Lublinsky氏は、ソフトウェアエンジニアリングとテクニカルアーキテクチャーの経験を25年以上持っています。この数年間、彼はエンタープライズアーキテクチャー、SOA、プロセスマネジメントに力を入れています。彼は、これまでに数多くの講演を行い、書籍を書いています。様々な雑誌に40を超える技術記事を書き、 (Avtomatika i telemechanica、IEEE Transactions on Automatic Control、Distributed Computing、Nuclear Instruments and Methods、Java Developer's Journal、XML Journal、Web Services Journal、JavaPro Journal、Enterprise Architect Journal、EAI Journal など) で発表しています。現在勤務している大規模な保険会社では、SOA ストラテジーおよびフレームワークの開発、保守などを職務としています。彼の連絡先は、blublinsky@hotmail.comです。
参考文献
1. Ali Arsanjani. Toward a pattern language for Service-Oriented Architecture and Integration, Part 2: Service composition. Developworks, December 2005.
2. Richard Hull, Jianwen Su. Tools for Composite Web Services: A Short Overview.
3. Rania Khalaf, Nirmal Mukhi, Sanjiva Weerawarana. Service–Oriented Composition in BPEL4WS.
4. B. Lublinsky. Defining SOA as an architectural style. IBM Developworks, January 2007
5. Web Services Composite Application Framework (WS-CAF)