PR

ESBの成り立ち

2006年2月10日(金)
江川 潔

インテグレーション・バックボーン

ESBはガートナ社が定義した言葉ですが、ESBを提供する各ベンダーは次の3種類に分けられます。


  • 従来のEAIツール・ベンダー
  • APS(Application Platform Suit)ベンダー
  • ESBをミドルウェアとして提供するベンダー

表1:ESBを提供するベンダーの種類

ESBの実装方法は、J2EEアプリケーション・サーバをプラットフォームとして前提としているもの、CORBAのようなエンドポイント同士を連携するもの、非同期のメッセージング基盤を前提としているもの、基本的にはEAIツールの形態を踏襲したものなどと様々です。さらにオープンソースでのESBの構築もいくつか行われており、Java系のESBとそうでないESBという分け方もあります。

現在のESBは比較的軽量なイメージがあります。しかし、際限なくESBに機能を追加することも可能です。そうなると、従来のEAIと同じになってしまうかもしれません。では、EAIとESBはどのように違うのでしょか。あるいは、メッセージ・ブローカとESBはどう違うのでしょうか。

2005年11月に開催されたIBM社のService Oriented Development Conferenceでは、ESBを次のように定義していました。
 

  • ESBはデータサービスとネットワーク・コネクティビティを担う
  • データサービスは宛て先を振り分け、メッセージディクショナリ、メッセージ変換を担う
  • プロセスフロー制御はプロセス制御のカテゴリであり、ESBのカテゴリではない

表2:IBM社によるESBの定義

表2はガートナ社が定義したESBの中でのプロセス管理のサーポートの要不要を課題としていたのに対応するものです。

しかし、ESBがサービスを統合管理するという役割を持つ以上、新たなサービスを生成するコンポジット・サービスはESBの範疇になるべきです。また、コンポジット・サービスのオーケストレーションはBPEL(Business Process Execution Language)で定義するようになってきていますが、BPEL自体は、より上位のビジネス・プロセスの定義にも使われ、BPELの利用形態で対応する機能範囲が分かれることになるでしょう。

つまり、BPM(Business Process Management)は、人間がおこなう業務もプロセスの中に統合していますが、現在のBPELでは人間が行う業務を記述できないといわれています。ビジネス・プロセスから呼び出される業務のすべてがサービス化されているとは限らないことを考えると、BPMはコンポジット・サービスをBPELで定義して作成する場合とは区別しておく必要があります。

いずれにしても、ESBが従来のEAIツールやMOM(Message Oriented Middleware)と異なることを説明する必要はあるでしょう。では次項から、ESBが何を実現するのかを解説していきます。

 

EAIツールとESB

EAIはエンタープライズ・アプリケーション・インテグレーションの意味ですから、特定のツールやソリューションを示す言葉ではありません。しかし、これまでの経緯からEAI製品といわれる製品のカテゴリがあります。EAI製品は歴史的にも古く、その特徴はERPやB2Bのゲートウェイであったり、金融系のメッセージングの基盤であったりします。

EAIツールが機能拡張してきた経緯の中で、データ変換やメッセージ転送を行うブローカとしてのハブ上にワークフロー機能を構築したりしています。機能が追加されハブは次第に大きくなると、単に、スポークを介してエンド側のアプリケーションが接続すれば連携が実現できるというようになります。

ある大手の電気メーカでは独自のミドルウェアを構築し、ハブ構造になっていたそうです。それが成長するにつれて、ハブの中でデータベースをもち、伝票を切るアプリケーションまで動いているということを伺ったことがあります。

上記の例では、本来エンド側のアプリケーションが担うべき機能が追いやられたのではないでしょうか。これでは、実際のアプリケーション間の連携ではなくなり、エンド側にはノウハウが残らなくなってしまいます。

ハブを中心にアプリケーションの連携を考えた場合は、様々な形態がありますが、例えば、ハブを中心に両方のエンドとアダプタを串刺しにして、メッセージが通過することを考えます。このとき、メッセージの扱いに関するノウハウもスキルもエンド側のアプリケーション/アダプタ/ハブに分散されて、トラブルシューティングも難しさを増し、複雑な構造となってしまいます。

次の言葉はIBMのCEOサミュエル・J・パルミサーノ氏がビジネス上の対応を迅速にするために提言した言葉ですが、インテグレーションにおいても同様にエンド同士が理解しあうことが重要です。

——オンデマンド・ビジネスとは、ビジネス・プロセスが全社および主要なパートナ、サプライヤー、さらにはお客様までがエンド・ツー・エンドで統合されており、お客様の要求や新たな市場機会、外部の脅威に対して柔軟かつ迅速に対応できる企業である。

つまり、エンドとエンドが迅速かつ正確にインタラクションが可能であり、その内容や手段を柔軟に変更することができなければなりません。問題はエンドとエンドであって、仲介者ではないのです。
 

ここでいう仲介者はハブ上のアプリケーション相当の機能を指しています。Intermediaryと表現されるものには個別のサービスがあります。例えば、コンポジット・サービスを構築するような機能はサービスとして位置付けます。

ESBではよりエンド同士がアプリケーションのインテグレーションのセマンティクスを共有する必要があります。
 

アダプタとマルチプロトコル/ハブとエンドポイント
図2:アダプタとマルチプロトコル/ハブとエンドポイント
(画像をクリックすると別ウィンドウに拡大図を表示します)
日本アイオナテクノロジーズ株式会社 テクニカルセールスマネージャ

株式会社富士通SSLでNTT仕様のオペレーティング・システムの開発に従事したのち、日本ディジタルイク イップメント株式会社でNTT向けシステムの開発、その後、ソフトウェアとハードウェアのプリセールス活動を展開した。DECの合併を経て、現職のミドル ウェア製品のマーケティング、アライアンス、プリセールスなどに従事。

blog「Essence is Real」
http://blogs.iona.com/essence/

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

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