 |
||||||||||||||||||
|
||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||
|
||||||||||||||||||
| バス形式によるESBの登場 | ||||||||||||||||||
|
「ハブ&スポーク」の一極集中の問題を解決するために2000年から2001年にかけて生まれてきたのが、バス形式をトポロジーとするESBです。日本では、2004年に入ってから国内外のベンダーが「ESB」と謳った製品の販売を開始したり、ESB製品の開発計画を発表しています。 バス形式では、図3で示すように、データやコントロールの流れが一箇所に集中するポイントがありません。  図3：バス形式によるインテグレーション メッセージやデータは、地理的／組織（企業内の部門や拠点、外部の取引業者など）的にも分散稼動しているアプリケーションすべてにまたがって「敷設」されている経路上を流れていきます。 この場合の「敷設」とはもちろん比喩的なものになります。ハードウェアバスのように「目に見える形で一本のバスが存在する」というわけではありません。ESBにおけるバスはあくまで論理的なものです。重要な点は、1本のバスが関係する拠点のすべてに（論理的ではありますが）またがっていることです。 |
||||||||||||||||||
| バストポロジーによらないESB製品 | ||||||||||||||||||
|
現在市場にでているESB製品は、その実装方法から次のように大別できます。
表5：市場に存在するESB製品 ここで、EAI製品やアプリケーションサーバ製品、MOM製品といったミドルウェアは「ハブ&スポーク」に基づくものであることを思い出してください。ESBをこれらの製品の上に実装するということは、ミドルウェアのサーバと同様にESBもまたハブとして機能することを意味します。 図4に示した例では、拠点Aに置かれたESB／サーバがハブとなっており、各拠点のアプリケーションからのデータがここに集中しています。このような形態のESBでは、バス形式とすることの意義の大半を失ってしまっています。  図4：既存ミドルウェア上に実装したESB |
||||||||||||||||||
| まとめ | ||||||||||||||||||
|
1990年代に、それまでのアプリケーションインテグレーションの方法を刷新する目的で登場してきたミドルウェア製品（アプリケーションサーバ、EAI、MOM、TPモニタなど）やERPに実装されたインテグレーション機能は、「インテグレーションのスパゲティ」状態を解消しました。 しかしその一方で、アプリケーション間のリンクを統一するために採用した「ハブ&スポーク」形態によって、一極集中の問題を抱えることとなってしまいました。この問題を解決するために、バス形態によるESBが提唱されました。 ところが、ESBを謳った製品のいくつかは、旧来のミドルウェア製品の上に実装されているため、ESBの誕生の理由となったバス形式の利点を最初から失ってしまっています。 今回のポイントは、次の点となります。
ESBのもっとも基本的で本来的な特徴は、そのバス形式にある
次回は、ESBが備えておくべき機能について考察します。 |
||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
