ESBの成り立ち

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

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

• 従来のEAIツール・ベンダー
• APS（Application Platform Suit）ベンダー
• 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はガートナ社が定義した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・パルミサーノ氏がビジネス上の対応を迅速にするために提言した言葉ですが、インテグレーションにおいても同様にエンド同士が理解しあうことが重要です。

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

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

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

図2：アダプタとマルチプロトコル／ハブとエンドポイント
（画像をクリックすると別ウィンドウに拡大図を表示します）