一方で、HTTPは基本的に状態を保存しないプロトコルで、リクエスト/レスポンスの一往復で処理が完結することを想定して設計されている点が制約になる可能性もある。単純なWebページの閲覧なら問題はないが、コンポーネントを組み合わせてビジネスプロセスを作成する際に、通信経路にはより高度で多彩な機能が必要とされることもあるだろう。
例えば、あるコンポーネントを呼び出した際に、応答がなかったらどうするか、という問題がある。あるいは、一定時間内に応答が返らなければいけないといった、いわゆるSLA(Service Level Agreement)の問題をどうするか、という問題もある。
これらはいずれも、メッセージ交換の信頼性の問題であり、HTTP自体にはこの部分の機能は実装されていない。しかし、ビジネスプロセスの一部に組み込んだ場合、応答が返らない理由が分からないと、再度メッセージを送るべきか、エラー処理に移るべきかの判断はできない。かといって、いつまでも、待ち続けているわけにもいかないだろう。
もちろんプロセスの内容にも依存するが、メッセージングの信頼性を保証するための仕組みが必要になることは間違いない。それが、SOAで情報システムを構築する際にESBが必要になる理由だ。
結局のところ、Webサービスが実現した「コンポーネント間のインタフェース仕様」だけでは低水準過ぎて、実際にコンポーネントをサービスとして扱うためには欠落要素が多過ぎるということだ。
もちろん、Webサービス以前には、そのインタフェース仕様さえもできてはいなかった。先行するCORBAのような仕様は存在したとはいえ、アーキテクチャー非依存かつ手軽に利用できる標準インタフェース仕様の確立は大きな進歩であったのは間違いない。
しかし、Webサービスのインタフェースを利用して「サービス」としてコンポーネント間を接続する上では、やはりさらに多くのソフトウェアスタックの整備を待たなくてはならなかった。このスタックを各社が各様の取り組みで提供しようとしているのが、現在の「ミドルウェア」を舞台とした各社の競合なのである。
Copyright © ITmedia, Inc. All Rights Reserved.