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