ESBを必要とするシーン
はじめに
前回は、疎結合を実現するための技術要素について説明した。今回は、その技術要素を実現する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の違いと一般的性質から、次のような状況ではESBを利用する必要があるといえる。
- サービス数の増加に対応する場合
- サービスのトランスポートと違うトランスポートで呼び出したい場合
- サービスの組み合わせをメディエーション(注1)する場合
- サービスに関する位置透過性を必要としている場合
では、表2の状況を個別に詳しく解説していく。WebサービスとESBの違いを理解することによって、ESBを利用すべきシーンが理解できるかと思う。
サービス数の増加に対応する場合
図1の左の状況をみれば、サービスが増加するとその組み合わせが指数的に増えていくことは想像に難くないだろう。このような煩雑さを解消するために は、中間に一層もうけて、組み合わせの数を減少させる必要がある(図1の右側)。このような中間の層は接続の確立や情報の変換を行っており、これこそが ESBである。
このように、ESBはエンドポイント(注2)とWSDLの管理をして、中間層の役割を果たしている。