|
||||||||||||||||||||||
| 前のページ 1 2 3 | ||||||||||||||||||||||
| ESBの機能1(コネクティビティの提供) | ||||||||||||||||||||||
|
ESBでは、旧EAI製品が個々のアダプタとして提供していたプロトコル変換の機能をESB内部に包含するようにしました。この様子を図6に図式します。 ![]() 図6:ESBにおけるコネクティビティ 図を見てすぐに気づくことは「プロトコル変換」という言葉が使われていない点です。旧EAIのアダプタもしくは図5に示されているプロトコル変換機能に該当するのが「コネクティビティ」と記されている部分です。 これはESBにおいてはおおもとのサーバのプロトコルへ変換するという意味が薄れるためです。別の言い方をすれば、ESBではデータ転送のエンジンであるサーバがアプリケーションから隠蔽されているのです。 アプリケーション側から見ると、ESBには様々なプロトコルによってアプリケーションを接続する口(あるいはポート)が用意されており、この口に接続さえすれば、サーバのプロトコルも相手アプリケーションのプロトコルも透過なものとなります。つまり、ESBにおいては、サーバもしくは相手側アプリケーションのプロトコルを強く意識した「プロトコル変換」ではなく、自らのアプリケーションの「接続性」だけを意識すればよいのです。 ESBにおいてもっとも基本的な機能が、この「コネクティビティの提供」です。これによって、異なるプロトコルを持つアプリケーションとの間でデータの送受信が可能となります。また上述してきたようなアプリケーションの置き換えが発生しても、柔軟な対応が可能となります。 ESBがアプリケーション間のプロトコルの差異を吸収しますので、相手側のアプリケーションが別のものに変更されても、新たなプログラミングやモジュール追加を必要とせず、こちら側のアプリケーションに大きな影響がおよぶこともありません。 ESBにおけるコネクティビティ提供において大切な点は、1つのプロトコルに限定しないことです。「SOAのサービスはWebサービスとし、SOAPプロトコルによって呼び出す」としている説明をよく目にしますが、実はすべてのアプリケーションがWebサービスやSOAPに対応しているわけではありません。 アプリケーション統合の柔軟性を高めるためには、ESBが多種のプロトコルに対するコネクティビティを提供できるようになっていることが必要です。これにより相手側アプリケーションがどのようなものに変更されても即座に対応できるようになります。これがSOAが目指すアジャイルな情報システム実現の礎となります。 次の表は、ESBによって提供されることが望ましいプロトコルの代表的なものをまとめたものです。
表3:ESBによって提供されることが望ましいプロトコル |
||||||||||||||||||||||
| まとめ | ||||||||||||||||||||||
|
今回はESBの最初の機能として「コネクティビティ」をとりあげました。コネクティビティは、異なるプロトコルを持つアプリケーション同士を結びつけるために必要となる最も基本的なものだからです。ESBが多くのコネクティビティを提供すればするほど、アプリケーション統合の柔軟性が増します。 豊富なコネクティビティはアジャイルな情報システムを実現するための基礎となりますが、それだけでは不十分です。他にも考慮すべき観点と機能が多くあります。これについては、連載を進めながら徐々に解明していくつもりです。 異なるアプリケーションに間には、プロトコル以外にも解決しなければならない差異があります。次回はこれらの差異を吸収するためのESBの機能について説明します。また1対1の統合を例にしながら、別の観点からみた統合の課題についても取り上げる予定です。 |
||||||||||||||||||||||
|
前のページ 1 2 3 |
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||


