ESBを必要とするシーン

2006年7月24日(月)
高安 厚思

はじめに

   前回は、疎結合を実現するための技術要素について説明した。今回は、その技術要素を実現するESB(Enterprise Service Bus)について説明する。


ESBとは

   ESBを最初に提唱したガートナ社は、「ESBとはWebサービスおよび他の標準仕様に基づいて書かれた標準コンポーネントをお互いにリンクするこ とができる標準技術に基づいたバス」と定義している。つまりは標準仕様に基づく、概念/アーキテクチャ/パターンということである。

   しかし、この定義に基づいてシステムを構成するためには、複数の高度な技術を統合させる必要があり、実現は難しかった。そこで、ESBベンダは「標準仕様に基づいたバス」をミドルウェアとして実装し、プロダクトとして提供している。

   このようにESBには2つの側面があるため、混乱を招いていると考えられる。そこで、次項からは、プロダクトとしてのESBについて取り上げ、具体的なプロダクトを想定せず、共通と思われる部分を説明していく。

ESBの必要性

   まずは、なぜESBが必要かということを説明する。読者の中にはApache AxisのようなWebサービスコンテナがあればESBなんて必要ないと思っている人もいるだろう。それはそれで一理あるが、状況によっては異なるのではないかと筆者は考えている。

   そこで実際にWebサービスとESBを比較してみた。それをまとめたのが次の表1になる。



性質 Webサービス ESB
トランスポート SOAPのみ 複数のトランスポートをサポート
ルーティング SOAPによるルーティング メッセージレベルルーティング
メッセージの
粒度
関数を呼び出すの必要な粒度 複数の関数を呼び出せる粒度
位置透過性 WSDLのエンドポイントだけが有効 あり
表1:WebサービスとESBの違い

   表1の違いと一般的性質から、次のような状況ではESBを利用する必要があるといえる。


  • サービス数の増加に対応する場合
  • サービスのトランスポートと違うトランスポートで呼び出したい場合
  • サービスの組み合わせをメディエーション(注1)する場合
  • サービスに関する位置透過性を必要としている場合
表2:ESBを利用する必要がある場合

※注1: 複数のサービスを集中管理し、1つにとりまとめること

   では、表2の状況を個別に詳しく解説していく。WebサービスとESBの違いを理解することによって、ESBを利用すべきシーンが理解できるかと思う。

サービス数の増加に対応する場合

   図1の左の状況をみれば、サービスが増加するとその組み合わせが指数的に増えていくことは想像に難くないだろう。このような煩雑さを解消するために は、中間に一層もうけて、組み合わせの数を減少させる必要がある(図1の右側)。このような中間の層は接続の確立や情報の変換を行っており、これこそが ESBである。



サービスが多くなる場合の比較
図1:サービスが多くなる場合の比較

   このように、ESBはエンドポイント(注2)とWSDLの管理をして、中間層の役割を果たしている。



※注2: サービスの呼び出し先をあらわしており、SOAP/HTTPではURI、JMSではデステネーション(キュー名/トピック名)であらわされる。
株式会社オープンストリーム テクニカルコンピテンシーユニット 主管システムズアーキテクト

横浜国立大学経営学部卒。銀行系シンクタンクでオブジェクト指向技術の研究に携わった後、大手SIerにて アーキテクチャ構築、プロセス研究に携わった。現在株式会社オープンストリームにてSOAを中心とする研究開発およびアーキテクチャ構築に従事。最近は XMLのダイナミックさに魅了されている。

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています