Google の進めていることを「WebServices の夢」に照らし合わせてみたとき、見えてくる技術的な課題を抽出した。
ここに「Google の次」がどういうものかを考えるヒントがある。
すなわち「サービスの相互運用性(Interoperability)を確保する Web 的な技術」だ。
Google がこれから集中を進めているまさに今こそ、次にくる分散に備えた技術を開発しておきたいと思う。
それはハイパーリンクがドキュメントの多様性を生み出したように、サービスの多様性を確保するための技術だ。
さて、その「Interoperability の課題」を解決する技術とはどういうものになるだろう。
ここから先は直感なので、真に受けるか受けないかはそれぞれ考えてみて欲しい（まあここまでの話だって、的を射ているかどうかは保証の限りではないのだが）。
まず WebServices と同じことをしたら、同じ轍を踏むことになる。とはいえ、WebServices の途中経路は演繹的であり間違っていないようにも思える。
すると変えるべきは最初の前提か。
WebServices は SOAP メッセージを使ってサービス連携を行う技術であるわけだが、既存技術との親和性をおもんぱかるあまりに、RPC 色が強くなりすぎ、ガチガチの手続きだらけになってしまった。
つまり、既存のクラサバ技術や Web アプリケーションサーバ技術から離れることが必要だ。
実際のサービス呼び出しは、WebServices よりもっとライトな方法でいい。
それを証明してくれたのは GoogleMaps だ（Google に対するアンチテーゼ的な話をしておいて、引き合いに出すのはなんだが）。
GoogleMaps と連携して構築されたサービスを見て、「WebServices って、あまり疎な結合じゃなかったんだ……」と思っちゃった人も多いのではないか。
最後のポイントは「リソース」＝「データ」＋「サービス」の扱いだと考えている。
Web は分散・孤立していたデータをつなぐ手段を提供することで、インターネットに引きずり出した。
Google は検索・分析・加工・利用するサービスを提供することで、データを集約しようとしている。
今の技術では、分散したデータに統合したサービスを提供することはできないから、サービスのあるところにデータを提供するしかない。しかし「サービス」を提供できる人は「データ」を提供できる人より圧倒的に少なく、したがって Google のやっていることは必然だと言える。
つまり、Interoperability の解決とは「サービス提供者にデータを提供しなくてもよい技術」と言い換えることもできるのではないだろうか？
