第1回：ESBの成り立ち (2/4)

TOP＞システムトレンド＞インテグレーション・バックボーン

安定したサービス指向を支えるESB

第１回：ESBの成り立ち
著者：日本アイオナテクノロジーズ江川潔 2006/2/10

前のページ 1 2 3 4 次のページ

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

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

前のページ 1 2 3 4 次のページ

日本アイオナテクノロジーズ株式会社
15年間 CORBAによる分散オブジェクト・ミドルウェアのトップ・ベンダの日本法人。ESB製品であるArtixを加え、さらに、SOA適用の敷居を下げるためにオープンソースESBのCeltixをリリースする。標準技術によりベンダとテクノロジーに依存しない顧客主体の中立なソリューションの提供を目指す。
http://www.iona.co.jp/

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

INDEX
第1回：ESBの成り立ち
	ESBと共通バスの考え方の違い
	インテグレーション・バックボーン
	ESBとマルチトランスポート
	ESBがサポートするメッセージング