ESBが目指すこと

テクノロジーの考え方

前回では、ITインフラを整備する上でESBが重要であることを解説しました。今回は、ESBがどのように活用されるのかについて解説していきます。

後述する事例のドイツポスト（DHL）のCIOが、あるセミナーで講演をされたときのスライドの中に表1のような内容がありました。残念ながらスライドをそのままはお見せできませんが、テクノロジーとセマンティクスの関係とSOAに期待されていることが説明されており、それぞれがスパゲッティ状態と整合が取れている状態を示しています。

内容	レガシー・システム	EAI	SOA
セマンティクス
テクノロジー			Don't Care

セマンティクスとは、例えばエンドポイントであるアプリケーションがリクエストしたパラメータの値の範囲や想定値（場合によってはアプリケーションごとに必要なデータの検証を行えるようなパラメータの内容）を保証するといったことを意味します。

テクノロジーは、プロトコルの相互運用性などの接続性についての要件を指しています。この中において、利用者にとってSOAのテクノロジーが「Don't Care（心配ない）」であることが求められています。

現在までの企業のシステムの連携がスパゲッティ状態になってしまったのは、様々なミドルウェアが様々な方法で利用されてきたので、スキルやノウハウが分散してしまい、継承されずに処置できない状態になってしまったからです。

ESBはメッセージを扱うミドルウェアであることは間違いありませんが、ESBが出現することでミドルウェアが1つ増えるだけでは、まったく意味をなしません。

また、Webサービス（SOAP／HTTP）で連携するミドルェアであれば、すべてのシステム間のインターフェースはWebサービスに統一する必要があります。しかしこれは現実的ではありません。

例えば、既存のシステムはすでに様々なミドルウェアを利用しており、Tuxedoのサーバとして機能を提供しているものがあるとします。Webサービスに変更するのであれば、従来のTuxedoのtpcall()をSOAPのメッセージで呼び出せるようにサーバ側を変更する必要があります。

この変更をESB側でカバーすれば、既存のサービスが新しいテクノロジーのインターフェースへシームレスに乗り換えることできるのです。

しかし、ここまでの機能では、従来のEAIツールのアダプタの機能（表1のEAIのテクノロジーの部分）と同じです。では、EAIとESBの違いは何かというと、アプリケーションのセマンティクスをサポートの有無にあります。

セマンティクスとは、少々言い過ぎのような気もしますが、認証について考えてみると、既存のテクノロジーの認証方式と新しいテクノロジーの認証インターフェースを連携しなければサービスへのアクセス権のチェックもできません。

CORBAとWebサービスの間では、CORBAのCSI v2（Common Security Interoperability Specification Version 2.0）で扱われるユーザ／パスワードをWebサービスのWS−Securityで規定されたトークンに変換してSOAPのメッセージヘッダー中に設定します。逆方向はCSIの設定機能を使ってCORBAのメッセージにトークンを設定します。

また、.NETのクライアントが既存のレガシーアプリケーションにアクセスする際にも、認証を行う必要があります。そのためには、アクティブディレクトリ中で管理されている認証情報とレガシーアプリケーションの認証情報を連携する必要があります。

さらに、異なるテクノロジーをまたいでトランザクションを保証したいというアプリケーションの要求もあります。アプリケーションが従来のOLTPのシステムへアクセスしたい場合、サービス指向では、この従来のトランザクションがサービスとして公開されます。

分散トランザクションのアプリケーションである場合、サービス利用者側にもリソースマネージャを抱えていて、ESBをまたいでサービス提供側のリソースマネージャとの間で2PC（ツー・フェーズ・コミット）を実現することになり、このとき、XAインターフェースを分配するトランザクション・コーディネータもESBの機能の1つとなります。

Webアプリケーションは、「Fire and Forget（失敗したらやり直す）」であり、ACID（Atomicity、Consistency、Isolation、Durability）を保証するトランザクションを扱った方は多くないかもしれませんが、ESBは基幹系システムをカバーしなければならないため、アプリケーションの要求としてトランザクション管理をサポートする必要があります。

テクノロジー間の接続機能だけであれば従来のアダプタで済みますが、前述のようにシステムインテグレーションのセマンティクスとでも呼べる要素を様々なテクノロジーの方式で吸収しながら実現することは簡単なことではありません。

ましてや、サービス提供者の既存のアプリケーションが独自の方式を持っている場合はあきらかにカスタマイズが必要となります。

このカスタマイズするためには、ESBは必要な段階で必要な機能のプラグインを追加するような拡張の可能な構造になっていることが重要です。
 

図1：テクノロジーのギャップ
（画像をクリックすると別ウィンドウに拡大図を表示します）

SOAによる新規のアプリケーションは、Javaや.NETによる開発となるといわれています。もちろん、既存のシステムの拡張もあるので、Javaや.NETの環境ばかりではありませんが、新しい技術を利用する方向であることは間違いないでしょう。その時に、既存のCOBOLやCで開発されているシステムをESBが連携しなければならなくなります。

これらの新旧の違いは言語だけでなく、プラットフォーム／トランスポート／ペイロード／セキュリティ／システム管理／トランザクション管理の違いにまでおよびます。このギャップをシームレスにカバーするのがESBの役目になります。既存のシステムをサービス化して拡張することを考えると、拡張のために超えなければならないギャップが存在します。