SOAPだけで相互運用性は向上しない

　もう一方の，分散オブジェクト環境同士の相互接続性の向上もかなり疑わしい。確かにSO　APは元々，アプリケーション（サービス）を構成しているオブジェクトにアクセスできる，XMLベースのメッセージを作成するためのプロトコルとして作られた。当時のSOAPが，Simple Object Access Protocolの略称であったことからもそれはうかがえる。

　MicrosoftのCOM技術にしても，IBMが利用するJava技術にしても，どちらもオブジェクトという概念がある。だから，それにアクセスする手順を統一すれば問題は解決する，と考えられたのは，安易ではあるがある意味必然だった。当初の各社の実装を見ても，方向は明らかに「オブジェクトをつなぐこと」に向いている。例えばMicrosoftの実装は，COMのオブジェクトをWebサービスとして公開するという方法を採っていた。IBMのそれは，JavaのオブジェクトをSOAPを通じて利用できるようにするものだった。COMやJavaだけでなく，C++，Perlなど他の言語でのSOAP実装も，XMLをそのままオブジェクトにバインドすることだけを考えて開発されていた。

　しかし，分散オブジェクト環境の相互運用性の向上をSOAPだけに求めるのは酷な話である。SOAPの意義は，オブジェクトがやり取りするデータ形式を規定したということにある。データ形式の統一だけで相互運用が実現できるほど，分散オブジェクト環境は甘くない。

　COMを例を取ってみればよく分かる。実はDCOM環境同士の接続でさえ，素人には手に負えないほどの困難を伴っていた。DCOMは，COMという単一マシン内でアプリケーション同士の通信を実現するための技術を，LAN環境に持ち込んだものである。COMのときには無視できたセキュリティ，オブジェクト・アクティベーション，ライフタイム管理，分散ガベージ・コレクションなどの問題が立ちはだかっていた。こうした問題をプログラマに負担を強いずに解決するには，ランタイム環境がこれらのサービスを吸収する以外にない。そのためプログラミングそのものよりも，ランタイム環境を整えるための手順を実施することが大変だったのである。また当然，CORBAやJavaにもこのようなサービスは存在する。しかしその設計思想や実装方針はそれぞれまったく異なるだろう。

　このように高度なレベルで考え方の異なる実装を相互に接続させたときに，思想のブレが問題になるのは当然だ。セキュリティ一つとっても，Windows環境でのセキュリティを前提に設計されているものが，異なるセキュリティ基盤を持つランタイムと接続できないことは明らかである。このような問題が，SOAPだけで解決できるはずもない。
　今後新たにさまざまな規約が出てきてこれらの問題も解決するだろう，というのが当時の楽観的な論調だった。今となってみれば，SOAPしかない状況で分散オブジェクト環境同士の相互接続を語るのは，空虚な理想論に過ぎなかった。

この時期の熱狂が後に意味を持つ

　当時のSOAPの熱狂は，主にツール製品やサーバー製品のベンダーから発せられたものだった。しかしそれら製品のユーザーが抱える問題を本当に解決するための技術ではなかった以上，実例は現れず，システム開発の本流にもならなかった。「Webサービスは普及していない」「Webサービスは単なるbuzzwordだ」という，今でもよく聞かれる懐疑論は，このあたりから出てきている。

　ただこの時期に，大手，中小，個人を問わず，多様な開発者が熱狂に従ってSOAPに触れ，SOAPを実装してみたことは，見逃せない事実である。soapbuildersに参集した開発者たちの成果物や，その他多くのライブラリがこの時期から開発されたことは，後々大きな意味を持つ。