組織は、市場の変化に適応できるように、柔軟性と応答性に注目する傾向があります。ITの課題は、通常、このビジネス・ビジョンを適切なアーキテクチャーとテクノロジーでサポートすることでした。初期のイニシアチブは、モノリシックなアプリケーションを呼び出し可能なサブルーチンに分割することでしたが、リモート・オブジェクト呼び出しとメッセージング処理の出現によりそれが変わりました。
最近では、組織内の既存資産の再利用を促進し(投資回収率の向上)、ヘテロジニアス(異種混在)なアプリケーションを集めてコヒーレントなビジネス・ソリューションを形成することが不可欠となっています。これがSOAとEDAの採用を促しています。この2種類の設計パラダイムは、アプリケーション中立サービスの再利用を最大化して、ITの適応性と効率性を高めることを目指しています。しかし、大規模な統合ソリューションの構築と導入は、今までは容易に達成できませんでした。ここでESBの登場です。ESBは、ミッション・クリティカルなアプリケーションのための柔軟で信頼性の高いアーキテクチャー(SOAとEDA)の実現を容易にします。
SOAは、すべての関数(サービス)が記述言語を使用して定義され、ネットワーク経由でインターフェースを発見可能なアーキテクチャー概念です。インターフェースは、サービスが実装されるハードウェア・プラットフォーム、オペレーティング・システム、およびプログラミング言語に依存しない中立な形式で定義されます。
SOAの最も重要な利点の1つは、組織内の各部署が専用のシステムを構築し、他の部署が何を構築しているかを知らないという、ソフトウェア開発における孤立主義的な実践から逃れられることです。この「サイロ」方式は、同じ機能が何度も開発、導入、保守されるという非効率で高コストな状況をもたらします。SOAは、図1に示すように、組織全体で共有されるサービス・ポートフォリオに基づき、既存の資産を効率的に再利用および統合する手段となります。
図1: 「サイロ」アプローチ対SOAアプローチ
SOAは、図2に示すように、従来型の要求/応答メカニズムに基づいています。サービス・コンシューマーは、ネットワークを通じてサービス・プロバイダーを呼び出し、プロバイダー側での操作の完了まで待たなければなりません。
図2: SOAの要求/応答メカニズム
表1に、SOAソリューションの基本的な特性を示します。
表1:SOAの基本特性
| 機能 | 説明 |
|---|---|
| Loosely coupled interactions | 疎結合型相互作用 サービスはテクノロジーや位置に関係なく呼び出される。 |
| One-to-one communications | 1対1通信 1つの特定のサービスが1回に1人のコンシューマーによって呼び出される。通信は双方向。 |
| Consumer-based trigger | コンシューマーベースのトリガー 制御の流れは、クライアント(サービス・コンシューマー)によって開始される。 |
| Synchronous | 同期 応答は同期してコンシューマーに送り返される。 |
2003年、ガートナー(「参考文献」参照)は、イベントに基づく設計パラダイムを記述する新しい用語を導入しました。それがイベント・ドリブン・アーキテクチャー(EDA)です。EDAは、切り離されたソフトウェア・コンポーネントおよびサービス間にイベントが送信されるアプリケーションおよびシステムを設計・実装するための方法論を定義しています。EDAは、SOAに置き換わるものではなく、それを補完するものです。一般に、要求/応答の交換にはSOAの方が適していますが、EDAは長時間にわたる非同期プロセス機能を備えています。さらに、EDAノードはイベントをポストするのであって、公開されたサービスの可用性に依存しません。実際には、他のノードから切り離されています。EDAは、「イベント・ドリブンSOA」と呼ばれることもあります。
EDAは、メッセージを使用して、2つ以上のアプリケーション・プロセス間で通信を行います。通信は、「イベント」によって開始されます。このトリガーは、一般に、何らかのビジネスの発生に対応します。図3に示すように、そのイベントの購読者への通知が行われて、活性化されます。
図3.イベント・ドリブン・アーキテクチャーの発行/購読メカニズム
表2に、EDAの基本的な特性を示します。
表2:EDAの基本特性
| 機能 | 説明 |
|---|---|
| Decoupled interactions | 切り離された相互作用 イベント発行者はイベント購読者の存在を意識しない。 |
| Many-to-many communications | 多対多通信 1つの特定のイベントが多数の購読者に影響を与える発行/購読メッセージング |
| Event-based trigger | イベント・ベースのトリガー 制御の流れは、受信者によって決められ、ポストされたイベントに基づく。 |
| Asynchronous | 非同期 イベント・メッセージングによって非同期操作をサポートする。 |
エンタープライズ・サービス・バス(ESB)は、イベント・ドリブンとサービス指向の両方のアプローチを結び付けて、ビジネス単位の統合を単純化し、ヘテロジニアスなプラットフォームおよび環境の仲介者となります。ESBは、異なるアプリケーション・プロセス間の通信を可能にする中間層の役目を果たします。エンタープライズ・サービス・バスに導入されたサービスは、コンシューマーまたはイベントによってトリガーされます。同期と非同期の両方をサポートして、1つまたは多数の関係者間の相互作用を容易にします(1対1または多対多通信)。このように、ESBは、SOAとEDAの両方のパラダイムが持つすべての機能を備えています(表1と表2を参照)。
エンタープライズ・サービス・バスは、アーキテクチャー・パターンであり、組織内の多種多様な製品で実装することができ、それらを組み合わせて連合バスとして機能します。エンタープライズ統合ニーズに応える製品を提供するベンダーがますます増えています。たとえば、IBM WebSphere® Enterprise Service Bus(「参考文献」参照)は、WebサービスやJ2EEなどの標準を利用して、アプリケーションを効率的に接続する統合バスを実現します。
ESB実装はどうあるべきかを定義する正式な仕様はありませんが、一般には、大規模なヘテロジニアス・アプリケーションの統合を容易にするために、少なくともトランスポート、イベント、および仲介サービスを提供しなければならないと考えられています。
トランスポート・サービスは、エンタープライズ・バスを介して相互接続されたビジネス・プロセス間のメッセージ配信を可能にしなければなりません。トランスポートには、コンテンツ・ベースのルーティングも含まれます。これは、メッセージを別の宛先に送信できることを意味します。ミッション・クリティカル環境の一環として、これらのサービスは、トランザクション可能であり、セキュリティーで保護され、監視対象となります。
イベント・サービスは、イベントの検出、トリガー、および配信機能を提供します。イベント・サービスは、イベント処理の概念に関連します。すなわち、イベント・ドリブン・アーキテクチャー(EDA)での複雑な相互に関連した一連のイベントの分析と制御のための技法です。イベント・ドリブン・パラダイムは、新しいものではありません。しかし、業界の注目を集め、複合イベント処理(Complex Event Processing)などの最新テクノロジーのコア・コンセプトとなっています(「参考文献」参照)。
仲介サービスは、2つの目的を果たします。まず、仲介サービスは、ヘテロジニアスなシステムの統合に必要なプロトコルの照合を行います。2つの異なるサービスが同じトランスポート・プロトコルを使用しているとは限らないので、仲介サービスがプロトコルの変換を処理して、通信を可能にします。プロトコルの切り替えは、ビジネス・トランザクションに参加しているすべてのサービスにとってトランスペアレントです。
図4: プロトコル仲介 ? ESBによるプロトコルの変換
第2に、仲介サービスは、メッセージの内容を変換する機能を提供します。これは、ビジネス統合にとって重要なサービスです。バスを通過するデータが、どのプロセスでも理解できるようにします。さらに、仲介サービスは、内容の付加を可能にして、追加情報によってメッセージの表現力を高めます。内容変換は、バスによって管理されます。参加サービスにとってトランスペアレントです。
図5: 内容の仲介 ? ESBによるメッセージ内容の変換と付加
例を挙げて、内容仲介のメリットを説明しましょう。Yummy Inc.という架空の会社があり、オンライン・ケータリング・サービスを提供しているとします。顧客に提供するメニューをプランニングするためには、納入業者からの食材の可用性と価格を確認する必要があります。この情報を入手するために同社が送信するメッセージの一般的な構造には、製品ID、数量、および予定納期が含まれます。
図6: 可用性メッセージの構造
もちろん、Yummy社と納入業者が情報を表現する方法は同じではありません。たとえば、両社のシステムでは日付形式が違います。さらに、納入業者の取引先はYummy社だけではないため、納入業者は配送先住所を必要とします。図7に示すように、ESB仲介サービスは、通過するメッセージの情報を変換および付加して、必要な情報のすべてがターゲット・サービスに届けられるようにします。
図7: ESB仲介サービスでの内容の変換と付加
ESBは、すでに定義されている主要なテクニカル・サービスを利用して、疎結合アプリケーションを統合する柔軟な接続基盤を提供します。SOAとEDAの両方のパラダイムをサポートします。
図8: エンタープライズ・サービス・バスによるサービスの仲介
ESBソリューションは、内部サービスを利用して多様な利点を提供します。簡単に言うと、異なるアプリケーションを接続するタスクを単純化して、ビジネスの俊敏性を高め、次のような機能を提供します。
-
標準準拠の接続性
多数のヘテロジニアスなシステム間の統合バックボーンとして、ESBは多種多様な統合技法を提供し、幅広い標準テクノロジーを利用しなければなりません。
メッセージング統合は、通常、JavaTM Message Service(JMS)APIをサポートしますが、エンタープライズ情報システムとの接続性は、J2EEコネクター・アーキテクチャー(JCA)によって提供されます。Webサービスの相互運用性を確保するために、ESBはJAX-RPCプログラミング・モデルをサポートします。異なるESBコンポーネント間の統合は、Javaビジネス統合仕様(JBI)によって標準化できます(「参考文献」参照)。 -
拡散的統合
ESBは、異なる部署、ビジネス単位、あるいはビジネス・パートナーにまたがってアプリケーションを統合できるため、本質的に拡散的です。さらに、そのアーキテクチャーの中核原理は、ヘテロジニアスな開発環境で構築されたアプリケーション間の通信を容易にすることです。たとえば、ESBソリューションは、J2EE、C++、.Netなど、異なるプログラミング言語を仲介することができます。 -
信頼性の高い統合
ESBアーキテクチャー・パターンは、システムのセキュリティー、スケーラビリティー、およびアベイラビリティーを高めます。SOAとEDAを利用するので、エンタープライズ・サービス・バスは、同期と非同期の両方の機能を提供します。トランスポート・サービスは、確実な配信とトランザクション可能な整合性を実現します。このように、ESBのすべての特性が、その堅牢性を強化し、統合・連合ソリューションの失敗の可能性を最小限に抑えます。
エンタープライズ・サービス・バスは、トランスポート、イベント、および仲介サービスによってビジネス統合を容易にするアーキテクチャー・パターンです。サービス指向アーキテクチャー(同期の1対1アプローチ)とイベント・ドリブン・アーキテクチャー(非同期の多対多アプローチ)の両方のヘテロジニアスなノード間で行われるすべての通信を接続し、すべての相互作用を仲介します。ESBは、複雑な統合課題を解決する現在最も効果的な手段であり、最高のビジネスの柔軟性と異種アプリケーション間の効率的な接続性を提供する技術ソリューションです。
学ぶために
-
developerWorksの記事でSOAの最新情報を得てください。
-
複合イベント処理に関する記事を読んでください。
-
イベント・ドリブン・アーキテクチャーが新しい概念としてガートナーによってどのように紹介されたかを調べてください。
- Javaプラットフォームの仕様を確認してください。
- Java Message Service (JSR-914)
- Java Connector Architecture (JSR-112)
- Java APIs for XML based RPC (JSR-101)
- Java Business Integration (JSR-208)
製品や技術を入手するために
- オープン標準とSOAに基づき、IT環境向けのエンタープライズ・サービス・バスを提供する新製品、 IBM WebSphere Enterprise Service BUSの最新版を入手してください。
-
IBM WebSphere Application Serverの無料試用版をダウンロードしてください。デフォルトのメッセージング・システムにより、トランスポート、イベント、および仲介サービスが使用可能です。
議論するために
-
developerWorks blogsに参加して、developerWorksコミュニティーに加わることができます。

Jean-Louis Marechauxは、カナダのIBM Business Consulting ServicesグループでITアーキテクトとして働いています。関心を持っている分野と専門分野は、J2EEアーキテクチャー、Webサービス・テクノロジー、SOA、およびエンジニアリング・プロセス(IBM Rational ® Unified Process)などです。連絡先は、jlmarech@ca.ibm.comです。