[ThinkIT] 第2回：ESBが目指すこと (1/4)

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

第２回：ESBが目指すこと
著者：日本アイオナテクノロジーズ江川潔 2006/2/17

1 2 3 4 次のページ

テクノロジーの考え方

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

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

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

表1：セマンティクスとテクノロジー

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

   テクノロジーは、プロトコルの相互運用性などの接続性についての要件を指しています。この中において、利用者にとって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の役目になります。既存のシステムをサービス化して拡張することを考えると、拡張のために超えなければならないギャップが存在します。

1 2 3 4 次のページ

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

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

この記事の評価をお聞かせください
ボタンをクリックしますとウインドウが開きます。
ご意見、ご要望にお応えします！インプレスIT INSIDE

INDEX
第2回：ESBが目指すこと
	テクノロジーの考え方
	ネーミング・サービスとレジストリ／リポジトリ
	ESBの事例
	SOAの目指すもの

安定したサービス指向を支えるESB
第1回	ESBの成り立ち
第2回	ESBができること

Think IT 過去人気記事

Think IT人気ライター BEST 5

IT製品/サービス資料ダウンロード

Think IT 過去人気記事

Think IT人気ライター BEST 5

テクノロジーメディア