はじめに

今日、『インテグレーションは SOA に基づいて実施し、そのベースとなる基盤に ESB (エンタープライズ サービス バス) を採用することが、現時点で考えうる最も効果的な方法である』、というのが製品ベンダー各社の一致した見解となっています。

ところが、各ベンダーで一致しているかのように見える SOA や ESB は、規格として定まったものではなく、アプリケーション インテグレーションの考え方を示しているにすぎません。

このため、SOA の基盤として位置づけられる ESB 製品は、各ソフトウェア ベンダーの解釈によって異なる仕様となっています。それに伴い、各ベンダーが唱える SOA 設計方法 (モデリング) や具体的な SOA 実装方法もまた異なっています。

選定ポイント 1 ---- メッセージ配信の信頼性と配信速度

現在市販されているほとんどの ESB 製品は、メッセージングのメカニズムによってメッセージ (リクエストやリプライなど) を配信します。

JMS 仕様に準拠したメッセージングを組み込んだ ESB 製品は、メッセージ配信の保証につい高い信頼性を期待できます。しかしながら、メッセージングの実装方式は製品ベンダーによって異なっており、このことがメッセージの配信速度などの性能について製品間の差となってあらわれています。

1. 配信の信頼性の高さ
クリティカルなビジネス データを送信する場合やメッセージの重複受信が許されないといったシビアなオペレーションを必要とする場合には、提供されているメッセージング メカニズムを詳細に検討する必要があります。 >/p>

2. 一時ストアに保存されたままとなっているメッセージの取扱い
エラー処理プロセスに転送できるか、未配送キューなどに移せるか、未配信メッセージの監視機能はあるかなどについて、自社のオペレーションに適合した機能を備えているかチェックする必要があります。

3. メッセージ配信の処理速度
メッセージング メカニズムは、通信上のオーバーヘッドとなりますので、処理速度が求められる場合には、ESB 製品の配信性能をチェックする必要があります。

• 秒あたり、何メッセージ配信できるか
• レイテンシーはどの程度か

選定ポイント 2 ---- マルチ プロトコルのサポート
コネクティビティの面から ESB 製品を区別すると

• Web サービスのみに対応
• マルチ プロトコルに対応

選定ポイント 3 ---- アダプター
製品ベンダーによっては、外付けのアダプターによって各種のプロトコルに対応している場合もあります。

このような場合には、アダプターを ESB にプラグインして ESB の一部として扱えるか否かが重要となります。ESB にプラグインできないと、後の章で説明するビジネス プロセスに組み込めなかったり、ESB とは別個ものとしてコンフィグ、管理をしなければならないなど、SOA の構築、システム監視、メンテナンスなどの手間が余計にかかります。

また、アダプターの購入価格 (ライセンス料金) もチェックする必要があります。旧 EAI 製品では、高額なアダプター価格が一因となって、広く普及しませんでした。

選定ポイント 4 ---- データ変換機能
現在市販されている ESB 製品に備わっているデータ変換機能をみると、概ね次の ５ 段階に分けられます。

1. XML データ間の変換 (XSLT を利用したマッピング) が可能なもの
2. 1 に加え、非 XML 形式から XML への変換 (およびその逆) が可能なもの
3. 1、2 に加え、XML データの分割や合成などが可能なもの
4. 1、2、3 に加え、外部のマスターデータベースやコード変換アプリにアクセスできるもの
5. 1、2、3、4 に加え、ユーザー独自の変換ロジックを組み込めるもの

選定ポイント 5 ---- メディエーション プロセスの構築
メディエーション プロセスを構築する機能を有している ESB 製品は、多くありません。
これは、 メディエーション プロセスを構築できるほどの多様なメディエーション機能を有していないことが主な原因です。このような ESB 製品では、XSLT によるマッピング機能をメインに、概ね以下に挙げる機能しか提供できていません。

• マッピング機能
• CBR (コンテンツ ベース ルーティング) 機能
• パブリッシュ機能

選定ポイント 6 ---- ファイル転送
ESB 製品の中には、ファイル転送をサポートしていないものがあります。

ファイル転送を必要とする場合には、次の機能についてチェックする必要があります。

1. 大容量 (数百 MB や数 GB) のファイルを転送できるか
   大容量のファイルを扱えない ESB 製品は多くあります。


2. リクエスト-リプライ方式におけるファイル転送
   リクエスト-リプライ方式しかサポートしていない ESB 製品の中には、アプリケーション同士で直接データ転送が行え ず、サービス コンシューマを別途作成しなければならないものがあります (下図参照)。この場合、余分なオーバーヘッド が大きく、従来のファイル転送よりもパフォーマンスが低下してしまいます。

選定ポイント 7 ---- リクエスト-リプライとイベント ドリブン
リクエスト-リプライ方式からスタートした SOA ですが、現在ではイベント ドリブン方式の重要性が認識され、こちらが主流となりつつあります。

これは、イベント ドリブンのほうが、現実の業務処理の方法に近いからであり、また、よりリアル タイムな業務処理が可能となるからです。
ビジネス要件の変化に瞬時に対応するためには、イベント ドリブンが不可欠です。

さらに、リクエスト-リプライをベースとした方式ではイベントのパイプライン処理を実現できませんが、イベント ドリブン方式に基づく ESB の場合にはビジネス プロセスをリクエスト-リプライとして構築することも可能であるということも、重要なポイントです。 イベントのパイプライン処理が可能な ESB 製品では、中央にハブやブローカーといったものを必要とせず、分散されたアプリケーション間で peer-to-peer にコミュニケーションでき、分散環境にうまく適合できます。

選定ポイント 8 ---- ESB 製品の生い立ち
AP サーバーをベースとする ESB は、次のような SOA に向いています。
ERP などの大規模アプリケーションを業務処理の中心に据えて、リクエスト ? リプライ形式のビジネス プロセスで足りる場合

一方、ピア サーバーを分散配置できる ESB は、次のような SOA に向いています。
既存サービス (アプリケーション) がヘテロジーニアスな環境で稼動している場合 統合の規模が拡大する傾向にある場合 リアル タイム処理が必要となる場合 (現状では、ピア サーバーにまたがるイベントのパイプライン処理が最適)

まとめ
SOA の考え方は、一対のアプリケーション同士がリクエスト-リプライで連携する方法から、イベント ドリブンの連鎖 (イベントのパイプライン処理) にシフトしてきています。
これは、ビジネス環境の変化を即座に捉えて、その変化に対する業務上の処理をいち早く実行するという要求が、ますます高くなってきているからです。

イベントのパイプライン処理に最も適している ESB 製品は、大規模な AP サーバーを中心としたものではなく、ライトウェイトなピア サーバーを複数、分散配置したものです。
複数のサーバーが分散配置され、それらのサーバー同士を直接結んだ Peer-to-Peer なイベント通知が行えることが、リアルタイムな業務処理システムの理想的な実行環境となります。このような分散環境では、負荷や障害の一極集中を避けられ、メッセージングのスループットが向上し、規模の拡大に柔軟に対処できるスケーラビリティを得ることができます。

いずれにしろ、ESB は標準規格として定められたものではないため、各製品の機能や実現可能な SOA アプリケーションは異なっています。このため、自社の環境や目標にどれだけ合致した製品であるか、入念にチェックする必要があります。

ホワイトペーパー
各選択ポイントの背景、詳細を説明したホワイト ペーパーを用意しております。
  ホワイトペーパー『ESB 製品選定のポイント』 -- SOA バックボーンとしての ESB に必要な機能 -- (資料ダウンロード ページへ)