IBMの後押しが状況を変えた

画面3●XMethodsが公開するWebサイト
400近いWebサービスが登録されている。

　SOAPが現在のような標準技術として確立できたのは，IBMがSOAPのサポートを発表したことに負うところが大きい。アイルランドIONA Technologies社の仲介もあり12，IBMは2000年5月にWorld Wide Web Consortium（W3C）にNoteとして提出されたSOAP 1.1仕様に共同提出者として加わった。さらに6月には，自社のSOAP実装である「SOAP4J」をApache Software Foundationに寄贈する。

　時を同じくして，Microsoftが「Forum 2000」で.NET構想を発表。その中核には，XMLによるWebサービス連携が据えられていた。続けて，「SOAP Toolkit for Visual Studio」をリリースした。こうして，JavaとVisual Basicという2大プログラミング環境における実装が整った。

　筆者はWebサービスという言葉がいつごろから使われ始めたのかまったく思い出せないのだが，このころにはすでに使われていただろう＊2。Webサービスは当初，二つの整数を送信すると加算結果が返されるものや，シンボルを送信すると株価を返すというような，単純なサービスを例に語られることが多かった。こうした単純なサービスのディレクトリを開始したのが，米XMethods社である（画面3[拡大表示]）。XMethodsのWebサイトは当時，Webサービスのデモンストレーションなどで盛んに利用された。XMethodsには多くのツールキットによる実装が公開されており，簡単に触ってみることができるようになっていた。

　Webサービスの相互接続性を確保するための動きも，草の根で始まった。SOAPの目標とは裏腹に，IBM SOAP4J改め「Apache SOAP」とMicrosoftのツールキットの相互接続は，それほど簡単ではなかった。IBMとMicrosoft以外にも多種多様なSOAPのツールキットが登場し始めたが，それらの相互接続はさらに一筋縄ではいかなかった。また，仕様の解釈をめぐって混乱があるなど，ツールキットの実装者にとっても，SOAP仕様は万全とは言いがたい状況だったのだ。

　そこで，SOAPツールキットの実装者とXMethodsが中心となって「soapbuilders」を設立した13 。SOAPの実装に携わっている開発者が，仕様の解釈に関する議論をしたり，一斉相互接続テストなどを実施するコミュニティである。soapbuildersの設立当初から，参加者たちは非常にフレンドリーに，かつ効率的に作業を進めた。彼らはときには参加している企業の会議室に集まり，顔とソースコードを突き合わせて相互接続性を向上させるためのテストと修正を繰り返した。

　現在，SOAP 1.1仕様に準拠したツールキットやライブラリは，通常の用途での相互接続性はほぼ確立されていると言ってよい。ひとえにそれは，soapbuildersに参集した開発者たちの努力の賜物である。

　soapbuildersには，日本人の参加者もいた。Rubyのためのライブラリ「SOAP4R」14の開発者である，NaHiこと，なかむらひろし氏だ。NaHi氏は，SOAP 1.0の時点で，早くも実装を試みていたようだ。SOAP 1.1に対しても，最も相互接続性の高い（接続に失敗するツールキットが少ない）ライブラリを開発した。また，2000年の6月には「SOAP-ml-JP」という日本語によるSOAPの技術者メーリング・リストを開設し，日本での議論の土壌を作った。

SOAPブームの二つの誤解

　大手ベンダーによるサポートや草の根での動きに後押しされ，SOAPは徐々に注目を集めていった。SOAPの利点が盛んに宣伝され，ブームとも言える盛り上がりを見せ始めた。特によく語られた利点は二つある。一つ目は，「DCOM，CORBA，Javaなどの分散オブジェクト環境は，独自のプロトコルを用いてオブジェクト間の通信を行うため，ファイアウォールとの相性が悪い。SOAPはHTTPを利用するため，ファイアウォールを設定変更なしに越えられる」というもの。もう一つは，「DCOM，CORBA，Javaなどの分散オブジェクト環境は，相互接続性に乏しい。これらの技術が抱える“オブジェクト”に相互に簡単にアクセスできる共通プロトコルが求められている。SOAPはXMLとHTTPという，これらの技術が両方とも対応できる標準を活用し，アプリケーション（サービス）間連携を容易にする」というものである。

　今となってみれば，実はどちらも的外れな部分がある。まず前者の結論として，ファイアウォールの設定をまったく変えずに，外部にサービスを公開できるようになるといった安易な主張が少なからず見られた。企業のファイアウォールは，自社のWebサイトを外部の第三者が閲覧できるようにすることを目的に，HTTP通信を許可している場合が多い。SOAPメッセージはこのファイアウォールを設定変更なしに通過できるので，ファイアウォール管理の手間をかけることなくサービスが利用可能になるというのである。

　しかし，越えられないはずのファイアウォールを簡単に越えられるようになるのだとしたら，それはセキュリティ・ホール以外の何者でもない。HTTPのポートを開けている目的はWeb閲覧などを許可するためであって，ファイアウォール内部で稼働しているシステムに対して，外部からコマンドを受け付けるためではない。当初の目的とは異なる用途に開いているポートを流用するのは，セキュリティ上大きな問題を招きかねない。

　ファイアウォールでHTTP通信を許可していたとしても，外部にWebサービスを公開する際には，改めて議論がなされるはずである。外部からのSOAPメッセージを通すかどうか，どのように通すのかを入念に検討するだろう。それがHTTPであろうがなかろうが，関係ない。HT　TP通信であっても，不正なXMLデータが含まれているメッセージは遮断されることになるだろう。HTTPを利用するからファイアウォールの設定変更が不要で，管理の手間が省ける，というのは大きな誤解である。

　また，筆者の知る限りDCOMは当時からHT　TPを使って通信する方法を備えていた。HTTPだからSOAPがいい，というだけでは理由にならない。