要約
SOA を採用するとき、Enterprise Service Bus（ESB）のような基盤を使用することは現在では一般的です。企業の中に基盤についての考え方として、少なくとも、2つの異なる考え方があります。それは、特定部門の特定の統合の問題を解決して、会社で複数のESBサーバーを使用するか、情報システムの全ての部分をつないで、会社に広がるESBを使用するかです。本稿では、いくつかのアーキテクチャと2つの異なるアプローチに対する管理の話題について説明します。
異なる基盤
5 年にわたり、ESBはSOA基盤にとってのキャッチフレーズでした。この概念は、David Chappell氏によって紹介されましたが、今日、実質的な定義がまだありません。実際には、各々のESBベンダーはそのビジョンを推進したので、異なるアプローチが基盤レベルに存在しています。各々のアプローチには、良い点と悪い点があります。
第一のアプローチは、各部門がESBの推進によりSOAを管理することです。それは、アプリケーションの統合とビジネスプロセスの発展をうまく処理します。分離され、独立したESBを使用することによって、各部門は、各自が望んでいるソリューションを自由に採用することができます。しかし、他のパートナーとの通信が必要なとき、Webサービスのような「ブリッジ」となる標準技術によって、明確にいくつかのビジネスサービスにアクセスするか、提供する必要があります。この場合、通信はHTTPといったプロトコルに依存します。そして、信頼性やセキュリティといったサービスの質は、自前でおこなわなければなりません。
SOA 基盤を見るための第二の方法は、全体的な視点で、ESBが企業の至るところで統合されます。ESBが部門の様々なサービスに普及し、それらの間の通信を可能とします。コンシューマは、ローカルのサービスに接続するのと同じようにしてESBと接続することができるので、他の部門からのサービスを呼び出すことは簡単におこなわれます。
これらの考えから、ESBは、現実にはイーサネットネットワークのような基幹の基盤であると考えられています。より現実的に言えば、ESBは、初めから相互接続されたノードのセットなのです。あるノードは、サービスのコンシューマやプロバイダに対する接続点となります。
注：ESBノードは、要するに、他のインスタンスで内部のネットワーク機能を持つESBサーバーです。
企業ネットワーク中に広がるESBは独裁者ではない
一見したところ、CIO(最高情報責任者)は、「ああ、私は、企業内の全てを参照し、アクセスすることができる『どこでも』ツールの類が欲しいのではない。」と言うかもしれません。管理者たちは、「私は何を管理、監督することができるのか?」とか、「他の管理者が、自分が管理しているサーバーの状態を変更することができるなんて考えられない。」と主張するかもしれません。あるいは、よく言われるのが、「セキュリティはどうなのか?」などです。
明らかに、統合されたESBが全てを許しているわけではありません。それは、単に、ネットワーク上の通信を単純化し、単純化した方法によってネットワークを通じたサービスの質のセットを提供します。
統合されたESBの中のドメイン
ドメインとサブドメインは、エンティティ間の境界を定義します。したがって、管理上の点から見ると、ESBのそれぞれの「ノード」はサブドメインの管理者によってのみ管理可能です。その人だけが、開始、終了、コネクタの設定、サービスのデプロイなどが可能です。その管理者は、自身のドメインのESBノードによって使用されているポートを管理し、これらのポートを守るためのファイヤーウォールやプロキシを設定することができます。
ドメインのノードにデプロイされたビジネスサービスは、パブリックなものかプライベートなものです。つまり、プライベートなサービスは、レジストリ内にあるもので、同一ドメインのコンシューマによってのみ参照可能です。さらに、プライベートサービスは、同一ドメインのコンシューマに対してのみアクセス可能です。
注:特別の定めのない限り、これらのプライベートサービスについては、以降のセクションで話題にする予定はありません。
サービスとプロセス監視は、自身のドメイン情報、あるいは他のドメインのパブリックな情報のみを表示することができます。他のプライベートドメインのプロセスやサービスの統計を参照することはできません。
さて、統合されたESBがどのようなものであるかについての潜在的な誤解を整理し、そのメリットについて、いくつか見ていくことにしましょう。
レジストリ
分断されたESB環境では、別のドメインからのサービスは、あるブリッジが2つのドメインのESB間のサービスに対して明確に作成されている場合にのみ存在します。例えば、あるドメインからのサービスは標準的なWebサービスとしてエクスポートされ、別のESBはそれを呼び出すためのURLを知る必要があります。企業レベルのレジストリは、それら全てのWebサービスを参照するために必要とされます。この場合、それぞれのドメインの管理者は、自身のドメインのWebサービスを企業のレジストリにパブリッシュする必要があります。これらのWebサービスは、企業の「パブリックな」サービスとして、全て参照可能であるものとして考えられます。
統合されたESBでは、ビジネスサービスのレジストリは、それ自身が統合されています。つまり、それぞれのESBインスタンスのレジストリは、他のそれと共に同期化されます。ドメイン内のESBに接続しているコンシューマやサービスブラウザは、バス上の全てのサービスを参照することができます。新しいサービスがESB上に公開されたら、物理的な配置によらず、それぞれのESBインスタンス上の全てのコンシューマに対して、すぐに参照したりアクセスすることができます。全てのサービスは同じような方法でアクセスすることができます。つまり、それらは「ESBサービス」なのです。それらの実装やプロトコルは問いません。
オーケストレーション
複数の分離されたESBに広がるサービスのオーケストレーションのために、オーケストレーションの概念化の方法が2つあります。第一に、BPELエンジンが ESB環境の外にあるものです。例えば、それはWebサービスのBPELエンジンとなります。この方法では、プロセスデザイナは、ドメインにわたる全てのサービスを知る必要があります。さらには、それらにアクセスするためのWebサービスとして、これらのサービスを統合する必要もあるでしょう。実行時に、 BPELエンジンは、サービスにアクセスするためにグローバルネットワークを超えたHTTPコネクションをいくつか作る必要があります。
一方、BPELエンジンがESB内に統合されていると、サービスの呼び出しはローカル環境内で利用可能です。別のESBにあるサービスにアクセスする必要があるときは、他のESBとそのサービスにアクセスするために、(Webサービス呼び出しのような)ブリッジが利用されます。
統合されたESBでは、「内部の」レジストリにはバスのサービスとそれらの記述全てが含まれます。BPELデザイナにESBレジストリを接続することによって、プロセスの設計が容易になります。プロセスの設計は、ESBサービスを扱うだけです。利用可能なサービス全てが、統合されたレジストリから取り出すことができ、プロセスへ直接統合することができます。実行時は、BPELエンジンとサービスの間にブリッジがないということから、トランザクションやコンペンセーションの問題への考慮がより簡単になります。
信頼性
SOA のような統合環境では、基本的に、アプリケーション間で多くの通信が存在します。それらは多くのサーバーに広がり、情報はネットワークを通じて大部分が運ばれます。基盤のトランスポート層は、情報損失を防ぐために可能な限り強固なものとする必要があります。ESBのトランスポート層は、その多くがメッセージの信頼性を提供しますが、ESBとアプリケーション間のブリッジは、(Webサービス、FTP、JMS、RMI・・・といった)そのプロトコルの機能に依存します。
分離されたESBのインスタンスでは、信頼性はインスタンス間でも確立する必要があります。別のESBインスタンス上に配置されたそれぞれのサービスに対して、信頼性のある通信が構成される必要があります。サービス毎のJMSキューは、そのために利用することができます。加えて、送り手のESBであるJMS キューと受け手のESBの間の通信は、トランザクショナルである必要があります。アクセスする他のドメインのサービスが多くある場合は、その作業は困難なものとなります。
統合されたESBを利用することで、アプリケーションをホストするそれぞれの物理的なサーバー上へのESBインスタンスのインストールを統合することができます。この場合、Webサービス呼び出しやFTP接続は、サーバー上に残ったままです。ネットワークの断絶による、アプリケーションとESBノード間への通信の影響はありません。ネットワーク通信はESBノードによって実現されます。その信頼性は、(通常、JMSのMOMをベースとした)ノードのトランスポート層によって保証されます。
もちろん、ESBノードをアプリケーションをホストしている各々のサーバーにインストールするのが理想的な考えです。完全な信頼性を必要としないアプリケーションは、分断されたサーバーにホストされた、離れたESBノードと接続可能です。ネットワークセーフな環境においては、ESBサーバーも複数のアプリケーションによって共有されるかもしれません。それは、管理者のリソース、コスト、・・・といったものに依存します。
サービスのガバナンス
サービスのライフサイクルやバージョンを管理することは、分断された環境では容易なことではありません。新しいサービスがESBインスタンス内に公開されたときは、コンシューマが他のインスタンスからそれをアクセスできるようにするために、コネクタが他のインスタンスに対して公開するように構成する必要があります。サービスの新しいバージョンが利用可能になったときは、新しいバージョンと一致させるためにそれぞれのコネクタを更新する必要があります。さらには、ESBインスタンスのサービス全てを参照する企業レベルのレジストリが無い場合、他のESBインスタンスからのコンシューマは、インスタンス上に存在するサービスを知ることはないでしょう。
統合されたESBでは、それぞれのインスタンスが初めから相互接続しているので、インスタンスにデプロイされたサービスは、他のインスタンス上でもすぐに利用可能となります。そのサービスは、それぞれのインスタンスのレジストリ内で参照可能です。サービスが変わるときには、それぞれのコンシューマは新しいバージョンによるメリットを享受するでしょう。
管理
大抵の場合、分断されたESB環境の管理者(コネクタのインストール、サービスのデプロイ、その他ライフサイクルの管理をおこなう人)は、ドメインのそれぞれの管理コンソールに接続する必要があります。管理者は、ESBインスタンスの動作を別々に構成します。
統合されたESBを利用することで、ドメインの管理者が、全ての接続形態を監視するための単一の管理コンソールで(ドメインの)全てのノードを管理することができます。主なメリットとして、管理者が全てのインスタンスのアクティビティ(リソース消費、サービス呼び出しの統計など)を監視し、ドメイン内の ESBの動作を管理することができるということがあげられます。たとえば、XSL変換のような非常に良く利用されるサービスの場合、管理者はその変換サービスのコピーをインスタンス化し、それを別のインスタンスにデプロイし、リクエストをディスパッチするためのロードバランスのルールを定義することができます。そのようなことは、分断されたESB環境でおこなうことはできません(あるいは、かろうじて可能です)。
ビジネス監視
ビジネスアクティビティの監視は、SOA基盤がオペレーションの管理者に与えた最も関心のある機能の一つです。サービスの統計がリアルタイムで入手できます。つまり、ビジネスプロセスが監視され、最適化が可能で、異常が発生したときにはEメールで警告をあげることができます。
分断されたESBインスタンスでは、主要なパフォーマンスの指標(KPI)を収集することは容易ではありません。それぞれのESBインスタンスからのKPI が別々に収集され、2つのインスタンス(Webサービスが呼び出すインスタンス)間の通信の監視は、容易ではありません。全てのデータは、監視ツールによって読めるようにする以前に、関連性を持っているからです。
再度繰り返しますが、統合されたESBは、ドメインにわたるKPIの収集を容易にします。インスタンス間のプロトコル分断がないので、同一のインスタンスによってホストされたものでなかったとしても、(メッセージ)交換のライフサイクルは、コンシューマからサービスプロバイダまで監視することができます。監視コンソールは、ドメインのインスタンス全てにつながり、ドメインの統計を表示することができます。
結論
それぞれのESBは、アプリケーションを統合するための機能のセットとツールのセットを提供します。トランスフォーメーションやオーケストレーションのようなコネクタとサービスのセットで、アプリケーションの統合が容易になりました。
所与の統合問題に対して、ある人は「中心的な」ESBといくつかのコネクタを利用することができ、それを2、3のアプリケーション間でのグルー(糊)を構築するために利用することができます。この「ポイント・ツー・ポイント」なアプローチは、セットアップが容易ですぐにできます。そして、多くの場合は、(WSDLやその他の)ビジネスサービス定義を必要としません。私たちが本稿で見てきたように、この「統合」の考え方は、そういったシンプルなケースに対して十分なものかもしれません。しかし、実在する「サービスプラットフォーム」のアプローチでは十分ではありません。そこでは、ESBが企業のSOA バックボーンとなる必要があります。
本当のネットワーク通信を可能とするESB実装を選択することは、企業における「サービスプラットフォーム」の基盤の採用において重要な鍵となります。ビジネスアプローチの手法では、企業全体の全てのサービスを簡単に利用することができるにつれ、情報システムのアクティビティとビジネス全てにおいてグローバルな視点を可能とし、その機敏さを高めます。
著者について
Adrien Louis氏は、EBM WebSourcing(サイト・英語)でチーフアーキテクトとして働いており、Java EEの技術での仕事を8年間経験しています。現在では、彼は企業統合ソリューションに関する仕事をしています。Adrien氏は、SOAコンサルタントであり、PEtALS(サイト・英語)オープンソースプロジェクトのアーキテクトでもあります。PEtALSでは、SOAをサポートするための優れたオープンソースESBを提供しています。それは、A2AとB2Bの両方に対して、軽量で、高度に分散され、スケーラブルなプラットフォームとなることを目的としています。その特定の分散型アーキテクチャとツールが提供されたおかげで、PEtALSでは、多数のプロトコル、フォーマット、統合機能をサポートした、非常に優位性のある統合ソリューションを提供しています。
原文はこちらです：http://www.infoq.com/articles/louis-esb-topologies
（このArticleは2008年5月23日に原文が掲載されました）