SOAを成功に導く統合バックボーン「ESB」：動き出したSOAのいま（1/3 ページ）

いまやすべてのソフトウェアベンダーにとって、アプリケーション統合を考慮してソフトウェアを設計することは必須だ。SOAで統合の役割を果たす重要なプラットフォームがESBである。

[谷川耕一，ITmedia]

本記事の関連コンテンツは、オンライン・ムック「動き出したSOAのいま」でご覧になれます。

　いまやすべてのソフトウェアベンダーにとって、アプリケーション統合を考慮してソフトウェアを設計することは必須だ。メインフレームの時代のように、1社独自のハードウェアに独自ソフトウェアを搭載するという組み合わせによるシステム構成を求めるユーザーは少ない半面、社内外の各システムとのアプリケーション連携が求められる傾向はさらに強まっているのである。

　また、ビックバン型で導入されるERPパッケージであっても、SOAを意識した外部システムとのインタフェースやミドルウェア部分での統合機能は、ユーザーから当たり前のものとして求められることになる。

　最近のはやり言葉の1つにSaaS（Software as a Service）がある。これはサーバマシン、アプリケーションの実体部分をベンダーに預けて運用するASP型のサービスだ。しかし、ユーザーからすれば独自性の出しづらいはずのSaaSでも、既存システムとの連携機能が提供されている。というよりも、カスタマイズや既存システムとの連携機能を持つ新しいASP型サービスを、区別してSaaSと呼んでいるともいう。

ESBがSOAの複雑性を吸収する

　こうした動きには、SOAという概念が真に市場で認められ始めているという背景がある。かつては「SOAは本当に使えるのですか」という質問がユーザーから投げかけられていたが、いまでは「どうすればSOAを実現できますか」というものに質問が変化していることからも、このことは理解できる。

　「SOAは使えるのか」いう質問がされていた頃は、ともかくプロセスとビジネスコンポーネントを分離独立させ、それらを個々に連携させることに注意が向かっていた。P2Pでプロセスをつなぐ、その際のXMLのデータ形式やそこで利用される通信プロトコルに注目が集まり、SOAの問題を解決するのはこれらの機能や整合性、パフォーマンスなど、技術的な問題として取り上げられてきた。

　実際には、苦労して切り出したプロセスを個々に連携させ、その結果を一元的に見えるようにユーザーインタフェースにポータルを導入する。場合によっては、これを期に多大な苦労をして全社規模ですべてのデータを格納するような、巨大統合データベース構築プロジェクトが走り出すかもしれない。

　この方法でも、結果はSOAによってシステム統合されたかのように見えるが、実態はかなり複雑怪奇なシステムが完成していることだろう。さらに、当時の処理系では、XMLなりが間に入ることでパフォーマンスが十分に出なかったり、接続性や性能を重視してセキュリティなどの重要な要素は後回しにされることも多かった。

　「どうすればSOAを実現できますか」という質問に変わった1つのエポックメイキング的な事象が、ESB（Enterprise Service Bus）という概念の登場であろう。ここでESBを製品ではなくあえて概念と表現したのは、さまざまなタイプのESB製品が世の中には存在し、唯一の定義付けをすることが現段階では難しいためだ。このESBはメッセージ指向のミドルウェアに代わるもので、SOAの統合バックボーンとして働く。P2Pで連携、統合していた複雑さを、ESBによって整理し円滑に管理できるようになるのだ。