「3カ月でもまだ遅い。1カ月で新しいシステムを作ってほしい」──。こうした短納期開発の要求が,近年ますます厳しくなっている。「通信業界や金融業界をはじめとして,システム開発のスピードを上げることが,企業の死活問題になってきた」と,アクセンチュアの小野沢博文氏(シニア・マネジャー)は指摘する。

 そんななか注目を集めているのが「SOA」(Service Oriented Architecture)というシステム設計の考え方と,今回取り上げる「ESB(Enterprise Service Bus)」だ。ESBを一言で表せば「SOAの実現に必要な,システム同士をつなぐ基盤」である。そのためESBを理解するには,SOAとは何かを押さえておく必要がある。まずは,SOAについて簡単に説明しよう。

システム同士を疎結合させるSOA

 SOAでは,企業の各システムが備える機能ごとに,Webサービスなどの標準化したインタフェースを設け,ほかのシステムやエンドユーザーのWebブラウザおよびクライアント・ソフトから,単純な手続きによってネットワーク経由で呼び出せるようにする。これを,システムの機能の「サービス化」と呼ぶ。

 さらに,連携させるシステムのいずれかに,取り扱うデータ項目の追加やネットワーク上の場所などの変更が生じても,ほかのシステムを修正せずにそのまま連携できるようにする。このような,連携させるシステム同士が互いの変更の影響をほとんど受けない状態を「疎結合」という。

システムの機能を自在に組み替え

 疎結合されたシステムが持つ機能(これを「サービス」と呼ぶ)は,自在に組み替えて利用することが可能だ。そのため,既存システムに必要な機能がそろっていれば,新しい業務のやり方に合わせたシステムを,大幅に改修することなく素早く実現できる。

 例えばSOAの考えに基づいたビジネスプロセスの管理ツールを使うと,在庫管理や配送管理のシステムが備える「在庫引き当て」「配送手配」といった機能がそれぞれアイコンとして表示され,それらをつなぎ合わせて設定をするだけでシステム連携の仕方を組み替えられる。

 ただしSOAは万能というわけではない。「サービス化によってシステム同士をつなぎやすくする半面,通信や処理性能のオーバーヘッドが大きい。高い性能が必要とされるシステム連携には向かない」(日本IBM ソフトウェア事業 シニア・テクノロジー・エバンジェリストの米持幸寿氏)。SOAが向くのは,処理性能が多少犠牲になったり性能を高めるためのコストが生じたりしても,ビジネスプロセスの変更に合わせて簡単に素早くシステム間の連携を組み替えたい,という用途である。

つなぐために必要な三つの機能

 では,SOAの基盤となる「ESB」とはどのようなものか。ESBの機能を挙げると,「ビジネスプロセスを設定してそれに合わせてシステムを連携させる」「システム間でやり取りするメッセージが確実に届いたかどうか監視する」「連携させたシステムの各機能がどれだけ利用されているかを管理する」──といった具合に様々なものがある(図1)。実はESBの定義は種々あり,それらの機能をどこまで含めるかで意見が分かれる。ただし最低限必要な機能として,次の三つが挙げられる。

図1●ESBの定義
図1●ESBの定義
現状ではESBの定義には様々なものがある。機能として見ると,「各システムの情報を管理するリポジトリ」「プロトコルやデータ形式の変換」「メッセージ・ルーティング」という三つが最低限必要であり,これらの機能を備えるシステム基盤が狭義のESBと言える。広義のESBには,セキュリティやトランザクション管理,記述したビジネスプロセスの実行環境など,システム同士をつなぐための諸機能が含まれる

・各システムの情報を管理するリポジトリ

・プロトコルやデータ形式の変換

・メッセージのルーティング

 ESBの具体的なイメージを持ってもらうため,接続した各システムから見てESBがどのような役割を果たすかを図2に示した。

図2●ESBの基本機能とシステム連携の例
図2●ESBの基本機能とシステム連携の例
ESBは,リポジトリ,変換,ルーティングという三つの基本機能を備える。接続された個々のシステムから見ると,相手のシステムの所在や利用するプロトコル/データ形式を意識することなく,ESBにメッセージを渡すだけで連携が可能になる
[画像のクリックで拡大表示]

 受注管理,在庫管理,配送管理──といった連携させるシステムは,すべてESBと直に接続する。必ずESBを通じて,ほかのシステムとメッセージをやり取りする。つまりESBは,連携させるシステム間のメッセージのやり取りを一手に担う通り道になる。

 ESBに接続された各システム(正確にはシステムの単一の機能もしくはそれらを組み合わせた「サービス」だが,分かりやすさを優先してここでは「システム」と表す)が別のシステムへのメッセージ送信をESBに依頼する際,送り先のシステムの物理的な場所まで指定する必要はない。ESBによって,各システムの場所を一元的に管理しているからだ。そのための情報の格納庫を「リポジトリ」と呼ぶ。

 ESBはリポジトリの情報に基づいて,仲介するメッセージのルーティング処理を実行し,送り先のシステムにメッセージを届ける。ルーティングする際,メッセージ中の引数に応じて送り先を変えるといった単純な分岐処理や,あるシステムにメッセージを届けた後で次に別のシステムにも届けるという行程の設定も可能である。

 メッセージを届けるとき,ESBは送り先のシステムに合わせて,プロトコルとデータ形式を変換する。このときも,リポジトリの情報を利用する。ESBでは,各システムが利用可能なプロトコルやデータ形式をリポジトリで管理している。その情報に基づいて,仲介するメッセージを送り先のシステムが解釈可能な形式に変換する。

EAIツールが抱える二つの問題

 これら「リポジトリ」「変換」「ルーティング」という三つの機能を見ると,「従来のEAI(Enterprise Application Integration)ツールと何が違うのか」と思うかもしれない。従来のEAIツールも,これら三つの機能を備えているので,その疑問はもっともである。

 しかし,従来のEAIツールでSOAの考えに基づくシステムを構築すると,以下の二つの大きな問題に直面する。

(1)システム同士をつなぐのに必要な大半の機能を,1台のサーバー機で集中処理する仕組みなので,そのサーバー機が性能上のボトルネックになりやすい

(2)ツール・ベンダーごとに独自仕様を採用しているので,接続するにはその仕様に合った専用ソフトが必要になるほか,他ベンダーのツールとの互換性がない

 誤解を恐れずに言えば,ESBはこれらの問題を解決したEAIツールの進化形ととらえることもできる。そこで,「処理性能のボトルネック」と「ベンダーの独自仕様」という二つの問題を,ESBではどのように解決しているのか見ていこう。