SOA-サービス指向アーキテクチャが新しいリソースと従来のリソースを組み込むためには、配備されている場所に関わらずすべてのITリソースを接続できるインフラが必要です。また、柔軟性を提供するためには、システムを停止させずにサービスの容易な結合と再構成をサポートするインフラが、信頼性を提供するためには、堅牢で安全なインフラが不可欠です。

そのインフラがESB-エンタープライズ・サービス・バスなのです。

ESBは、SOA-サービス指向アーキテクチャを使用してビジネスコンポーネントの統合と柔軟な再利用を容易に実現するソフトウェアインフラです。ESBにより、サービスの動的な接続、サービスおよびサービス間のインタラクションの仲介、制御を容易に行うことが可能になります。

接続 :
エンタープライズ・サービス・バスは、新しいアプリケーション、Webサービス、多数のレガシーテクノロジの接続を簡略化します。J2EEや.NETアプリケーション、Webサービス、データベース、あるいは従来のメッセージブローカーなどESBに接続されたすべてのリソースは、幅広く利用可能になり、同様にESBに接続されている他のすべてのリソースと通信することができます。これを実現するために、エンタープライズ・サービス・バスは、配備されている場所を問わず他の接続リソースへのアクセスを提供します。ESBは、拡張されたエンタープライズ全体のサービスとプロセスをリンクして、部門や企業の内部、およびその境界を越えた通信を促進するのです。

ESBは、堅牢性、安全性、拡張性に優れた通信を提供するため、必要なQoSに基づいて、指定された宛先にデータが配信されることを保証します。したがってサービス生産者は、サービス消費者が一時的に対応できない場合でも、データを再送する必要はありません。ESBは、リソースの配備範囲を制限する、あるいは接続されたリソース間で配信されるデータのスループットを低下させるボトルネックや渋滞地点をインフラ内に発生させてはなりません。

仲介 :
仲介はエンタープライズ・サービス・バスに欠かせない機能で、以下のように主に3つのメリットを提供します。

まず仲介機能により、ESBは互換性のないプロトコル、データフォーマット、接続されたサービスのインタラクションパターンを調整することが可能になります。ESBに組み込まれた仲介機能を使ってこれらの違いを埋めれば、異なるサービス間の通信を迅速に非常に簡単に設定することができます。ESBは、メッセージフォーマットやプロトコルだけでなく、インタラクションパターンも仲介するため、サービスのコードに変更を加えることなく、同期サービスが非同期サービスと、そして非同期サービスが同期サービスと通信することが可能になります。

2つ目の大きなメリットは、サービスへの変更を必要とせずにサービスを仲介できる点です。仲介によって、柔軟性に欠けるハードコーディングされたサービス間の相互依存性が排除されます。サービスの相互依存性、中でも隠された依存性は、サービスの変更による影響の把握を困難にするため、SOAの柔軟性を妨げます。エンタープライズ・サービス・バスは、サービス間の仲介を分離し、明示的にすることによって、複雑な環境における変更管理を大幅に簡略化しています。

仲介の柔軟性は広い意味で3つ目のメリットと言えますが、特に重要なのはESBが新しい要件に合わせて既存のサービスを容易に統合、拡張することができる点です。仲介されたサービスは、エンドツーエンドのビジネスプロセスの自動化のために調整できる、汎用のビルディングブロックになります。

制御
SOA-サービス指向アーキテクチャは、拡張するにつれて、制御と管理が複雑化するため、アーキテクチャ全体の可視性が必要になります。
SOAのためのインフラであるエンタープライズ・サービス・バス（ESB）には、ESB自体とホストするサービスを管理するためのフレームワークが組み込まれています。

最初の管理タスクは、サービスの配備です。サービスは、ESBが実行されている任意の場所に配備することができます。サービスは広域に分散して配備されるため（たとえば小売業の場合、数百あるいは数千の店舗で構成されます)、ESBは、中央のロケーションからネットワークを介して簡単にサービスを配備できるように設計されています。またESBは、リモートサイトへのサービス（または一連のサービス群）の一斉配備とアップグレードもサポートしているので、非常に大規模な環境も容易に管理することができます。

これを動的に機能させるために、ESBでは設定を通じて操作を行います。サービスとその仲介関係が宣言されるので、再コンパイルや再配備を必要とせずに、動的に変更することができます。したがって、データやプロセスフローは、実行中のサービスをシャットダウンせずに簡単に変更できます。設定変更もリモートから配備できるので、中央のコンソールから分散環境のあらゆる要素の振る舞いを変更することが可能です。

ESBは、ESB内でホスト、接続するサービスを管理する（中央のロギングとサービス、障害、プロセスのステータスの監査など）だけでなく、インフラ自体の詳細なパフォーマンス統計情報を提供します。これらの情報を利用して、複雑な分散環境の障害を監視して検出し、問題を診断することができます。

ESBの特徴

エンタープライズ・サービス・バスは、論理サービスとプロセスインタフェースを物理的なIT資産にマッピングし、動的にバインドすることによって、再利用のためにこれらのIT資産を幅広く使用可能にするソフトウェアインフラです。

なぜESBは「エンタープライズ・サービス・バス」と呼ばれているのでしょうか？

• ESBはエンタープライズクラスのQoSを提供します

  信頼性、フォールトトレランス、セキュリティは、サービスバインディングの重要な要素です。そしてこれらを提供するのがESBです。サービスは、ESBインフラを活用することで、信頼性の高い安全な通信を行うことが可能になります。サービス自体には低レベルの通信を実装する必要はありません。

  すべてのサービスが同一のQoSを必要とするわけではありません。したがってESBでは、任意のサービス関係に任意のQoSを設定することができます。新しいQoSが必要となった場合に、サービスに変更を加えたり実行中のサービスに影響を与えることなく、サービスを再利用できることも、ESBの柔軟性が提供する重要なメリットです。

• ESB上のサービスはすべて、ファーストクラスのサービスとして配備され、幅広く利用可能になり、他の任意のサービスと、仲介を通じてインタラクションができるように（コーディングでなく）設定されます。

  ESBは、当然Webサービスをサポートしていますが、幅広いテクノロジとの接続を容易にするための接続点も提供します。ESB上に配備されたJ2EE、.NETコンポーネント、カスタムアプリケーション、レガシーMOMシステムなどのリソースは、再利用可能なサービスとなります。

  この柔軟性を実現するために必要なのは、1つのサービスタイプを他の任意のサービスタイプにマッピングし、バインドする統一されたサービスモデルです。このサービスモデルには、さまざまなインタラクションパターンが含まれるため、ESBは、参加するサービスへの変更を必要とせずに、キューイング、パブリッシュ/サブスクライブ、ルーティングなどさまざまなインタラクションモデルを使ってイベント主導型サービスを結合することができます。

  統一されたサービスモデルと包括的なサービス仲介機能に欠けるインフラでは、サービスとミドルウェアを接続するために、次善の策としてハードコーディングを行わなければなりません。柔軟性に欠け、管理できない、しかもインフラの他の部分からは不透明なこの次善の策によって、隠された依存関係が生まれるため、分散システムの変更が困難になります。ESBにとって非常に重要なのは、サービス指向アーキテクチャのビジョンを実現するために、このようなハードコーディングを排除することです。

• ESBは、バストポロジーを実装してサービスを幅広く利用可能にし、再利用を促進します。

  バストポロジーは、大規模な環境で分散アプリケーションとインフラサービスを接続、ホストするように拡張できます。ハブアンドスポーク（スター）トポロジーは、中央のブローカーに依存するため、単一のLAN内部の少ないリソースの管理には適していますが、大規模なSOA環境には適していません。

エンタープライズ・サービス・バスのメリット

IT部門にとってのメリット :

• 既存のアプリケーションとデータを活用して新しいプロセスを構築する時間と労力を低減する。
• 分散環境内のアプリケーション、サービス、ミドルウェア間の隠された依存関係を最小限に抑え、複雑なシステムの柔軟な変更を可能にする。
• 業界標準のインタフェースとプロトコルの利用を通じて、TCOを削減するとともに、将来のニーズにも非常に柔軟に対応できる。
• ソフトウェア、ネットワーク、ハードウェアに障害が発生しても、サービスからサービスに確実にメッセージを配信できる。
• 広域に分散しながらも中央から管理できるサービスホスト/管理インフラを提供できる。
• エンタープライズ全体、および顧客、取引パートナーにも情報を配信できる。
• 段階的に導入できるため、顧客へのサービスの提供を高速化し、大規模で複雑なプロジェクトのリスクを緩和できる。

ビジネスにとってのメリット :

• Iビジネスの俊敏性が高まり、変化するビジネス要件に迅速に対応できる。
• 買収、合併を円滑に進められる。
• 再利用可能なビジネスコンポーネントの標準化によって、ソフトウェア開発およびメンテナンス費用を削減できる。
• システムのセキュリティ、拡張性、可用性、堅牢性が向上する。
• 顧客サービスの質が向上する。
• 特別なビジネス状況を迅速に発見し、これに対応できる。
• サイクル時間を短縮できる。
• 運用費を削減できる。
• 「確実な単一の」最新ビジネス情報をもとに、より正確かつ簡単に決定を下すことができる。

SOAインフラ : ESBとWebサービスの比較

Webサービスは、オープンな標準を使用して抽象レイヤを追加し、機能的に理解しやすく技術的に容易な方法でアプリケーションへのアクセスを表現、提供します。

ただし、Webサービスだけでは一般的な統合プロジェクトの実現には不十分です。現在のWebサービス標準には、エンタープライズに必要とされるQoS（信頼性、セキュリティ）を管理する仕様がありません。またWebサービスは、Webサービス消費者のニーズとWebサービス生産者の能力の違いを埋めるために必要な汎用の仲介機能およびプロセス管理機能を提供していません。

SOAインフラ : ESBとアプリケーションプラットフォームスイート（APS）の比較

アプリケーションプラットフォームスイートは、緊密に結合されたコンポーネントで構築されたアプリケーションと必要なリソース（データベースドライバなど）の配備をサポートするために最適化されたホスティング環境です。スタンドアロンアプリケーションでは、コンポーネントとリソース間の関係は頻繁にも動的に変化しません。

通常アプリケーションは、1台のサーバまたは同種サーバのクラスタに展開されます。アプリケーションを分散ネットワーク内の異なるサーバに配備したり、再設定したりすることは容易ではありません。APSは、1台のサーバまたは同種サーバのクラスタで実行されているビジネスプロセスの可視性と管理機能は提供しますが、異種サーバや分散環境のサーバにまたがって実行されるプロセスの統一されたビューや管理機能は提供しません。したがって、.NETやJ2EEのEJBコンテナのような環境は、エンタープライズSOAの動的に設定される多数のサービスの管理には適していません。

ESBは、J2EEアプリケーションサーバの機能を補完することができます。J2EEアプリケーションサーバは、JMS、MDB、JCA、またはWebサービスのような標準インタフェースを使用してESBにプラグインすることにより、他のアプリケーションサーバやJ2EE以外の環境と統合することが可能になります。APSと違い、ESBのサービスコンテナは、必要とされるときに、必要とされる場所に、必要とされる仲介サービスのみを選択して配備することができます。対照的に、APSでは1つの統合機能のみが必要な場所にもアプリケーションサーバスタック全体をインストールしなければなりません。結果として、ライセンス費、インストール費、長期的なTCOなど、本来は不必要な高額なコストが発生します。

SOAインフラ ： ESBとメッセージ指向ミドルウェア（MOM）の比較

仲介機能を通じてサービスを分離できるMOM製品は、ESBと同様にRPCよりも柔軟性に優れています。ただし、MOM製品にはサービスインタフェースがありません。このため、メッセージングミドルウェアを直接呼出し、メッセージの配信先と配信方法を明確に表すようにサービスを記述しなければなりません。また、サービス間の暗黙的な関係が変更される（ビジネスプロセスの一部としてメッセージのルーティングを変更するなど）たびに、アプリケーションコードを修正してアプリケーションを配備しなおす必要があります。

この種のハードコーディングされた依存関係の変更、管理、追跡は困難です。MOMを通じてリンクされているサービスは、メッセージプロトコル、フォーマット、データのエンコーディング、タイプおよび構造、コンポーネントモデル、セキュリティ、エラー処理にも暗黙的に依存しています。またMOM製品には、サービスのコントラクト、登録、検出を定義するメカニズムを含め、大半のサービスプラットフォームが欠如しています。

エンタープライズ・サービス・バスは、MOMテクノロジを高度に補完することができます。Sonic ESBでは、レガシーメッセージングシステムのキューを容易にサービス化し、ファーストクラスサービスとして公開し、ESB上の他のサービスとインタラクションさせることが可能になります。

SOAインフラ ： ESBと統合ブローカーの比較

従来のEAI製品は、アプリケーション統合のために特別に設計されています。これらの製品は、ハブアンドスポークモデルでアプリケーション間のマッピングとバインディングを実行するため、少ないアプリケーションを統合する場合以外には、単一のポイントが集中的に複雑化してしまいます。

開発面では、EAI製品、そして統合するすべてのアプリケーションの意味的な詳細を熟知しているITプロフェッショナルを1つのプロジェクトに配置することは多額の費用がかかるうえ、現実的ではありません。配備の面では、EAI製品の中央管理されたハブアンドスポークアーキテクチャを拡張して役割を追加するには、1台のサーバ、または単一のLANセグメント内で稼動する同種サーバのクラスタに、非常に多くのコンピューティングリソースを追加する必要があります。

For More Information

日本プログレス株式会社
マーケティング部
Tel : 03-3556-7613
Email : e-ex@
sonicsoftware.co.jp