Webサービスを標準採用，専門のアダプタ不要に
「従来のEAIツールにおける大きな問題の一つは，ベンダーごとの独自仕様に基づいてメッセージングをしていたことにある」。SOAやオブジェクト指向開発に詳しい日本総合研究所の細川努氏（次世代カードシステム事業本部 開発第二グループマネジャー）は，こう指摘する。
独自仕様では，どのような問題が生じるのか（図1）。一つは，接続するシステムごとに，ツール・ベンダーが提供する比較的高価な「アダプタ」が必要になることだ。アダプタとは，プロトコル形式を変換するコンポーネントで，システムと接続する部分に利用する。手組みのシステムではアダプタを利用して連携部分を開発する必要があるが，独自仕様であるだけに，その仕様に精通したITエンジニアの絶対数が少ない。
 |
| 図1●従来のEAIツールが独自仕様だったことによる弊害 従来のEAIツールでは，独自のメッセージ形式や特定のプロトコルを用いていたので，EAIツール独自のアダプタを利用する必要があった。そのため，異なるベンダーのEAIツールを使っているシステム同士では相互接続できないなどの問題が生じていた |
ベンダー間で互換性ないEAI
もう一つは，ベンダー間でEAIツールの互換性がないこと。自社内のシステムを連携させるなら，この点は問題ないように思えるかもしれない。しかし近年，関連会社との連結経営を強化するため互いのシステムを連携させる企業が増えている。そのときに関連会社が異なるベンダーのEAIツールを使っていると，巨額の費用を投じて刷新する羽目になる。しかも，例えばソニーがコニカミノルタのカメラ事業を，ソフトバンクがボーダフォンの日本法人を買収したように，今や大がかりなM＆A（合併と買収）は日常茶飯事である。同じベンダーのEAIツール同士でなければ接続できないことは，大きな足かせになる。
また独自仕様であることによって，利用しているEAIツールのベンダーが市場から撤退したり，倒産したりした場合，サポートを受けられなくなり，別ベンダーのEAIツールに全面的に乗り換えなければならない，というリスクも生じる。いわば「EAIツールを選ぶ際にはベンダーと心中するくらいの覚悟が必要だった」（細川氏）。
ESBではアダプタが不要に
一方ESBでは，「Webサービス」という標準仕様を導入し，連携させるシステムのインタフェースの互換性を保っている。「システムにWebサービスのインタフェースを備えれば，高価なアダプタを用意したり，新たに開発したりする必要はない。Webサービスを取り入れたことのメリットは大きい」（設計・開発方法論に詳しいITコンサルタントの鈴村幸太郎氏）。連携させるシステムがWebサービスのインタフェースを備えていれば，どのベンダーのESBにも接続できる（図2）。
 |
| 図2●ESBにおいて「Webサービス」という標準仕様が採用されたことの利点 ESBでは，SOAPやWSDL（Web Services Description Language）といったWebサービスの標準仕様を取り入れている。これにより，異なるベンダーのESBツールを利用している関連会社などのシステムとも連携させやすいといった利点がある |
Webサービスのプロトコル
ここで，ESBがインタフェースの標準仕様として採用しているWebサービスとは何かについて，簡単に解説しておこう。具体的には，メッセージとしてやり取りするXML（eXtensible Markup Language）文書の構造や書式を定めた「SOAP（Simple Object Access Protocol）」と，連携させるシステムの機能（サービス）の呼び出し方法や引数などをXML文書で表した「WSDL（Web Services Description Language）」のことである。
ただしSOAPとWSDLの組み合わせだけで，システム連携に必要なESBの機能をすべて実現できるわけではない。ケースによっては，電子署名や暗号化によってセキュリティを高めたり，確実にメッセージが届いたことを保証したりする機能も必要になる。これらは，SOAPとWSDLだけでは実現できない。
そうした付加的な機能については，XML関連の標準化団体である「OASIS（Organization for the Advancement of Structured Information Standards）」やWebの仕様に関する標準化団体「W3C（World Wide Web Consortium）」，Webサービスの標準化団体「WS-I（Web Services Interoperability Organization）」などがそれぞれ，標準化を進めている。電子署名や暗号化などによってセキュリティを強化する「WS-Security」など，それらの団体によって標準化された仕様の一部は，すでにESBツールに採用されている（表1）。
| 表1●ESBが対応するWebサービスのプロトコル ESBでは，Webサービス標準であるSOAPやWSDLが利用可能である。ただしメッセージの送達保証や障害処理などの付加的な機能は，セキュリティなどを除いてまだ標準と呼べる仕様が定まっておらず，ESBのツール・ベンダー各社がデファクトに近いと判断した仕様や独自の仕様を採用しているのが現状だ（この表は米Sonic Softwareの「Sonic ESB 7.0」が採用している仕様） [画像のクリックで拡大表示] |
 |
Webサービスでも残る課題
ただし現状では，Webサービスの仕様は発展途上。このことによって，今後新たな問題が生じかねない。
メッセージの送達保証や障害処理，アクセス制御，トランザクション管理──などWebサービスの付加的な仕様が順次ESBに取り入れられていく見通しだが，それらを利用するには，基本的に開発者がそれらの仕様を学んだうえで，各アプリケーションのソースコードに手を加える必要がある。しかも一度ならまだしも，それら仕様ごとにバージョンが上がるたびソースコードに手を入れる必要が生じる可能性もある。開発者の負担は軽くない。
この問題に対処するのに，注目に値するのが，米IBMや米BEA Systemsなどが提唱している「SCA（Service Component Architecture）」というSOAのためのフレームワークだ。
SCAでは，アプリケーションの「ビジネス・ロジックの記述部分」と「メッセージをやり取りする通信部分」をコンポーネントとして切り離し，両者の仕様を定めている。そのためSCAの仕様に準拠させた形でアプリケーション（ビジネス・ロジックの記述部分）を開発しておけば，新しいWebサービスの仕様を利用する際に，ソースコードを書き換える必要はない。ミドルウエア・ベンダーなどが提供する通信部分のコンポーネントを更新するだけで，対応できる（図3）。
 |
| 図3●SCAの利点 ESBが標準仕様としているWebサービスは今後も，トランザクション管理やセキュリティなどの付加機能が追加されたり，バージョンアップされたりしていく。それら新しい付加機能を利用するには，Webサービスに対応した一般的な構造のアプリケーションでは，ソースコードの書き換えが必要だ。一方，「SCA（Service Component Architecture）」というフレームワークを用いれば，アプリケーションの修正は必要ない。新しい付加機能をサポートしたSCA準拠の通信用コンポーネントを用意するだけでよい [画像のクリックで拡大表示] |
こうしたことを可能にするために，SCAでは，コンポーネント間の依存関係をプログラムに記述しない「DI（Dependency Injection）」という考え方を取り入れている。実行環境が依存関係を注入することで，アプリケーションを修正せずにコンポーネントを取り替えられる仕組みだ。
SCAはプロトコルの違いを吸収
SCAはもともとWebサービスに限らず，多様なプロトコルを混在させる場合でも，アプリケーションのビジネス・ロジックの記述部分に影響が出ないようにすることを狙ったものである。そのため通信部分のコンポーネントは，Webサービスだけでなく，「JCA（J2EE Connector Architecture）」などの多様なプロトコルをサポートする計画だ。
