“Web2.0 for Enterprise”という切り口を発案したきっかけの一つは，「既存のSOAP/WSDLベースのWebサービスはどうなるのか」という疑問を抱いたことでした。Web 2.0のブームで急速に注目を集めつつあったREST準拠のWebサービス，例えばGoogle Maps APIのようなJavaScript APIの呼び出しによるWebサービスに，取って代わられる可能性はあるのでしょうか。
SOAP/WSDLベースの業務システムを設計したことのある方なら，とてもそうは思えない，というのが正直な感想でしょう。GoogleのサイトにあるAPIのドキュメントを眺め，サンプル・コードを読んでみれば，REST準拠のWebサービスは非常にシンプルであることが分かります。少なくとも，現行の業務システム間連携をいきなり代替するのは難しい，と考えた技術者が，「両者は別物」と感じても不思議はありません。ひいては，“Web2.0 for Enterprise”というコンセプト自体に疑問をもつのも無理からぬことでしょう。
Googleのサイトにあるサンプル・コード（「Introduction: The "Hello, World" of Google Maps」より引用）は実に簡単です。Google Maps Version 2を画面に読み込むJavaScriptの関数loadを，以下のように定義しています。
function load() {
if (GBrowserIsCompatible()) {
var map = new GMap2(document.getElementById("map"));
map.setCenter(new GLatLng(37.4419, -122.1419), 13);
}
}
GBrowserIsCompatible関数でブラウザがサポート対象かどうかをチェックしたら，実体はたったの2行。GMap2というオブジェクトを生成し，緯度と経度によって地図の中央を指定するだけです。
Google Mapsのコンテンツをロードし，自分のアプリケーションと「マッシュアップ」するのも難しくありません。借りてきたコンテンツの領域と自分の領域との間で，JavaScriptのコードを使うなどしてデータをやりとりすれば，両者の間で新しい有意味な連携をさせることができます。
こうしたWebアプリケーションが，SOAPベースのWebサービスからデータを受け取ることも当然可能です（例：Google AdWords API)。したがって，これら2つの方式で受け取ったデータを組み合わせ，計算し，加工して新たな付加価値を生むこともできます。かようにして，REST型のWebサービスとSOAP型のWebサービスとを併用し，必要に応じて両者を連携させることができるのです。
これは大変重要なことです。REST型のWebサービスは，SOAP型のWebサービスと違ってトランザクションなどの複雑な仕組みを備えていませんが，そのぶん，オーバーヘッドが小さい，簡単に使える，といったメリットがあります。RESTとSOAPは必ずしも競合するものではなく，適材適所で使い分けるべきものなのです。もちろん，サービスを提供する側としては，両方のWebサービスを用意しておくのもよい方法です。
次回以降，RESTタイプのWebサービスとSOAP/WSDLベースのWebサービスの使い分けについて少しずつ説明してまいります。また，「BPEL（Business Process Execution Language）もマッシュアップだったかもしれない」と称して，SOAP/WSDLベースのWebサービスでも，複数のサービスを組み合わせて使う方法が追求されてきたことに目を向けてみたいと思います。
