このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
Web サーバが XML によるデータを外部に公開し、
データの形式や、利用（呼び出し）方法を規格化することで、
HTTP を媒介として構造化データの通信が可能となる。
こういう機能は Web サービスと呼ばれる。
ユーザエージェントから Web サーバに、
クエリ文字列や本体を経由してパラメータを渡し、
Web サーバが処理して XML で結果を返す。
基本はこれだけである。
さて、Web サービスでは XML が利用されるのだが、
そのプロトコル（通信規約やデータ形式）には、
何種類もの規格や実装がある。
最近では以下の 2 つが有名なところだ。
・SOAP (Simple Object Access Protocol)
・XML-RPC (Remote Procedure Call)
SOAP は、異なるプラットフォーム・異なる技術間で、
オブジェクトの操作を行うための取り決めである。
つまり、遠隔コンピュータ上に、
オブジェクトのインスタンスを作成したり、
そのメソッドを呼び出して利用したりすることが可能となる。
このように、離れた所にある機能を呼び出す手法を、
RPC (Remote Procedure Call) と呼ぶが、
SOAP は RPC を実現するための 1 つの規格である。
このような分散オブジェクトの技術としては、
CORBA や DCOM などの規格が存在したが、
これらは独自の手法を用いて通信を行うため、
両者には互換性がなかった。
SOAP はこれらの上の層に存在し、
オブジェクトの呼び出し（メッセージ）を、
XML を主体とした表現に置き換えて表現することで、
プラットフォームや技術の枠組みを超えて、
オブジェクトの相互通信を果たす為の規格である。
XML に変換されたメッセージは、
HTTP で送る場合は本体として送信されるため、
原則として POST メソッドを使って通信を行う。
SOAP 自身は HTTP に依存しておらず、
必要ならば他のプロトコルに乗せることも可能である。
極端な話、メールの本文に SOAP の XML を載せて、
それを処理できるメールアドレスに対して、
SMTP で送りつけることも可能だ。
SOAP は、プログラミング寄りのモデルである。
通常のプログラミングを少し拡張するだけで、
遠隔コンピュータ間に存在するオブジェクトを、
同一環境のオブジェクトの操作と同様に扱えるのだ。
その特性上 SOAP の通信で使われる XML は、
非常に複雑なデータ構造の XML となっており
Web 開発者が直接扱うための物ではなく
SOAP の XML を手動で生成するのは現実的でない。
さて、SOAP よりも少し敷居を下げ、
シンプルとなっているものが、XML-RPC である。
XML-RPC も HTTP の POST により、
XML 形式でデータをやり取りする。
XML-RPC では、RPC で利用される
データの構造や型を表現するための要素を定義している。
<int>、<string> や <boolean> の他、
配列 <array> や、構造体（や連想配列）<struct> 等、
プログラマならよく知るデータ型を表現できる。
サーバ側に送られる XML は、
<methodCall> をルートとする呼び出し構文であり、
メソッド名や、型指定されたパラメータなどが含まれる。
それに対してサーバが返却する XML は、
<methodResponse> をルートとする戻り値であり、
複雑なデータやエラー値などを返却することができる。
XML-RPC の XML はシンプルである。
Web 開発者から見ても、XML の構造に対して、
DOM や XSLT などでアクセスするのが容易となるのだ。
SOAP は通信内容の XML を直接扱うことを想定しておらず、
XML-RPC は、それも視野に入れているのも違いだろうか。
WWW には様々な技術が存在し、
開発のプラットフォームも色々である。
SOAP は非常に高水準な規格であるため、
Java や Microsoft.NET のように、
高水準な環境が整っているならば適合しやすい。
しかし、CGI や、クライアント側 JavaScript による、
Web 開発の環境においては、
SOAP は複雑すぎて利用が難しい。
そのため、WWW では、SOAP はあまり普及せず、
XML-RPC の方に、軍配が上がったようだ。