SOAPの役割がドキュメント送信へと変わる

　実際にSOAPを使ったサービスが公開され始めると，今度はSOAP（つまりXMLとHTTP）のパフォーマンスの悪さが指摘されるようになってきた。当時例として使われた，二つの数を加算するサービスや与えられたシンボルに対して株価を返すようなサービスをインターネット越しに実行すれば，遅いのは当たり前だ。しかも速度の遅いテキストベースのプロトコルである。ただオーバーヘッドが大きいことは厳然として事実であった。

　またSOAPはHTTPをベースにしていることから，セッションの維持が困難であるという欠点もあった。単一のオブジェクトのメソッドを何度も呼び出すような仕組みには，SOAPは不向きであることが明らかになってきた。

　実は同様の問題は，DCOMやCORBAなどの分散オブジェクト環境でも繰り返し指摘されていた。分散オブジェクト環境では，パフォーマンスの問題とセッションの問題を回避するために，「chatty（おしゃべりな）ではなくchunky（塊の大きな）」なアクセスが推奨された。

　つまり，クライアントとサーバーの間でのやり取りはできるだけ少なくし，より多くのデータを同時に送り込んで処理をさせることが回避策となった。メソッドやオブジェクトの粒度を粗くするのである。

　Webサービスの環境でも同じことが考えられた。より多くのデータを少ない往復でやり取りするために，オブジェクトへのメソッド呼び出しではなく，封筒に文書を入れる，あるいは注文伝票をまとめてFAX送信するという比喩が使われ始めた。XMLで表現する伝票の構造をXML Schemaで定義し，取引先と共有する。またWS　DLで伝票のやり取りの手順を定義し，共有する。これらの共有知識が確立した上で，それを表現するXMLデータをメッセージとして送信することがSOAPの役割であると考えられるようになった。SOAPはSimple Object Access Protocolの略称ではなくなり，封筒を表現するためのプロトコルになった。

二つある「利用方法」

　この事実が象徴的に現れているのが，デフォルトで採用しているSOAPの「利用方法」だ。WSDL定義の中の「use」属性で指定する。Microsoftは，.NET Frameworkでいわゆる「document/literal」と呼ぶ利用方法を標準とした＊4。

図2●rpc/encodedとdocument/literalの違い rpc/encodedは，オブジェクトをXML形式に符号化して送信し，受信側で再度オブジェクトに復号するという考え方に基づいている。オブジェクトのメソッドを呼び出す方法と親和性が高い。これに対してdocument/literalは，ドキュメントをそのまま相手に送るという考え方を採る。ドキュメントの中身をどのように解釈するかは，アプリケーションに任される。

　それまでのツールは「rpc/encoded」と呼ばれるSOAPの利用方法が主だった。具体的にはSOAP 1.1で規定されていたRPC（Remote Procedure Call）モデルに基づく利用方法のことである。rpc/encodedでは，SOAPのBodyに含まれるXMLデータは，Javaや.NETなどのプログラミング言語で使われるデータ（オブジェクト）を符号化したものである。電子メールにファイルを添付して送信する場面を想像してみると分かりやすい。電子メールそのものはテキストベースのプロトコルが使われているので，画像などのバイナリデータはそのままでは送れない。バイナリデータをBase64などのアルゴリズムで符号化し，テキストデータとして送信する。同様にrpc/encodedも，本来はXMLで表現されていないデータをXMLで送信できるように決められた符号化をする。この場合，受信したXMLデータは，オブジェクトなど元のデータに戻す必要がある。戻す手順がプログラミング環境ごとに異なってしまうと接続できないので，soapbuildersなどを通じてrpc/encodedでの相互接続性が確立された。

　document/literalと呼ばれる利用方法では，RPCとしての動作にこだわっていない。この利用方法ではSOAPのBodyに含まれるXMLデータは文字通り（literalとは文字通りという意味である），XMLデータとして扱われる（図2[拡大表示]）。Bodyに含まれるXMLデータは，まさに送り手が送信したかったデータそのものである。XMLデータの中に画像データをBase64でエンコードした文字列を含めて送信することもあるだろうが，それをバイナリデータと解釈し，復号して元のデータに戻すのはアプリケーションの機能であって，SOAPプロトコルでは関知しない。まさに，封筒に文書を入れて送るイメージであり，新しいSOAPの使い方に適したものだったのである。

　ちなみに，rpc/encodedとdocument/literalの違いをもってSOAPの相互接続性が脅かされたなどとする論調は，少々的はずれである。rpc/　encodedとdocument/literalではSOAPのBodyに含まれるXMLデータに対する思想がまったく異なるので，rpc/encodedを要求するサービスに対してdocument/literal方式で作られたSOAPメッセージを送信してもうまく接続できないのは当たり前だ。rpc/encoded同士，あるいはdocument/literal同士であれば，かなり早い時期から相互接続は確立していた。soapbuildersをはじめとする実装者たちの努力のたまものである。もっとも現在では，Webサービスの相互接続性確保を目指す業界団体であるWS-I（Web Services Interoperability Organization）が，「Basic Profile」と呼ばれるガイドラインによって強制的にrpc/encodedの利用を禁止している。二つの方式が誤解を招く余地はなくなったと言っていいだろう。