SOAPは、Webサービスを支えるもっとも重要なXMLのテクノロジです。名前だけを見るとXMLによるプロトコルと思いがちですが、実際にはXMLの封筒構造としての側面が非常に重要です。SOAPが誕生した背景、規約が決めていること、サポートしている実行環境、規約策定の現状と今後などを説明していくこととします。
SOAPは、Webサービスを支えるもっとも重要なXMLのテクノロジです。名前だけを見るとXMLによるプロトコルと思いがちですが、実際にはXMLの封筒構造としての側面が非常に重要です。SOAPが誕生した背景、規約が決めていること、サポートしている実行環境、規約策定の現状と今後などを説明していくこととします。
SOAPの原点はUserland社が作った「XML-RPC」というプロトコルです。XMLを使って「RPC（Remote Procedure Call）」すなわち遠隔手順呼び出しを行うための仕様です。SOAPでRPCを行うことの重要な点は、異なったプラットフォームや異なった言語間で相互接続性の高いRPC環境が構築できる点にあります。 RPCとは、あるコンピューターにあるプログラムが、同じアドレス空間にあるプロシージャー（メソッドやサブルーチン）を呼び出すのと同じ感覚（コーディング）で、別のアドレス空間（別のコンピューター）にあるプログラムにアクセスする方法を言います。同様のテクノロジとして「分散オブジェクト」という考え方もあります。オブジェクト指向型のプログラミングモデルにおいて、オブジェクトのライフサイクルまでを含めて遠隔で呼び出されるようにする仕様です。
クライアントサーバー型プログラム開発では、サーバープログラム、クライアントプログラム双方が、ネットワーク仕様（たとえば、NETBIOSやTCPIP）に依存したものになりがちですが、RPC、分散オブジェクトにおいては、ネットワークにあまり依存しないアプリケーションコードを記述することができます。
XML-RPC仕様は、その後Microsoft社に買い取られ、COMをXMLでアクセスするための仕様が作られました。このときSOAPという名前がついたのです。コンポーネント（Object）をRPCとしてアクセス（Access）するためのシンプルな（Simple）XMLプロトコル（Protocol）であるため、SOAPという名前である、ということになります。
別の流れとして、e-マーケットプレースを行っていた技術者の努力がここに関係します。 e-マーケットプレースをXMLで作っていた技術者は、同じような構築モデルの上にシステム連携を実装していました。主に、以下のような機能が共通で使われています。
共通ボキャブラリはいわゆるXMLのスキーマ定義です。機能の登録所とは「見積りXMLを受け取って、見積もり結果XMLを返すサイト」といった検索をプログラム的に（すなわちXMLによって）登録、検索ができるようなサーバーをさしています。データベースであったり、LDAPのようなディレクトリーサーバーであったりします。レジストリーを検索してアクセスするモデルを使うことで、電子入札システムに簡単に参入できるしくみを作れます。
最後の封筒構造は、XMLに封筒の機能を提供する、ということです。封筒の機能とはなんでしょうか。 実際の紙で取引を行うとき、封筒はさまざまな意味をもって使われます。たとえば以下のようなことです。
XMLアプリケーションでも同様の要求があり、e-マーケットプレースのような仕組みにはしばしば封筒構造が使われます。とくに、複数のXMLを同時に送るという用件は非常に多く発生します。理由は次のようなことです。
あるXML標準を使ったシステムを作るとします。たとえば酒屋協会が決めた酒見積もりXMLです。見積もりXMLには、酒の種類、本数、単価、小計、税金、合計などが入れられます。ところで、この見積もりXMLを使って電子入札を行おうとすると、困った事が起こります。電子入札では、見積もりを送ってきたシステムに見積もり結果を返さなければなりません。非同期型で行われることが多いため、見積もり結果を返すためのアドレス（同じように見積もり結果を受け取るXMLアプリケーションやeメールアドレス）を依頼主から送信する必要があります。しかし、見積もりXMLはビジネス文書から作ることが多いので、こういったシステムに特化した情報項目は入らないのが通常です。
そこで、エンジニアは工夫をこらして、先ほどの見積もりXMLと一緒にURLなどを送信する方法を考えます。そしてよく行われるのがXMLに封筒構造を作り、複数のXMLを同時に送ったり、XMLに追加情報を付加したりする、というやりかたです。
XMLに封筒構造ができることで、以下のようなメリットがあります。
ところで、eマーケットプレースを構築していたグループや企業はいくつかあったので封筒構造に方言ができてしまいました。eマーケットプレースは、一度構築したあと流動することが多く、別のマーケットプレースと統合することもあります。封筒構造が違えば、自ずとアプリケーションは書き換えになります。エンジニアたちは、みな「共通の封筒構造」を模索しました。そこでSOAPが注目されたのです。SOAPにはもともとEnvelope、Header、Bodyという封筒構造のためのタグが存在していました。しかも非常にシンプルで、さまざまな用途に使えそうに見えました。そしてこのSOAPの封筒構造をXML封筒構造の標準にしよう、ということになったのです。
SOAPには、当初COMにアクセスするためのさまざまな機能、データ項目が残っていましたし、データのエンコーディングもXDR（XML Data Reduced：Microsoft社独自のスキーマ言語仕様）を利用していたりするなどオープンな仕様ではありませんでした。IBM社とLotus社がここに加わり独自仕様と思われる部分をはずし、オープンなプラットフォームに依存せずに使える仕様として修正を加えました。こうしてSOAP v1.1が完成し、1999年4月にW3CにNoteとして提案されたのです。
SOAP v1.1は、Microsoft社、IBM社、Lotus社の共同提案で1999年4月にW3Cに提案されたSOAPの規約案（Note）です。以下のアドレスから入手することができます。
SOAPの封筒構造はSOAPエンベロープと呼ばれ、複数のXMLを同時に送ったり、XMLに追加情報を付加したりすることのできるXMLタグです。
封筒構造は、Envelope、Header、Bodyから成っています。
SOAPでは名前空間を使うことになっています。SOAPエンベロープの名前空間は次のものです。
http://schemas.xmlsoap.org/soap/envelope/
実は、SOAP封筒構造のHeaderやBodyには、なにを入れるか、ということは封筒構造の決まりでは「なにも決めてない」のです。これは現実の世界で封筒に入れるものはとくに決まっていないのと同じです。ただし、「基本的には渡したいXMLをBodyに入れ、付加的なXMLをHeaderに入れる」ということになっています。現実の封筒でいえば、Headerは封筒の外側、Bodyは封筒の中、ということになります。
SOAPはRPCを行うためのプロトコルと思い込んでいる人が多いようですが、SOAPの封筒構造はさまざまな用途に使えることになっています。SOAP-RPCは、SOAP封筒構造の単なるひとつの使い方、ということです。
SOAPヘッダーには、いくつかの属性が決められています。
複数のXMLをSOAPで同時送信し、封入されているXMLごとに処理するサーバー（アクターといいます）が違う場合などにactor属性で記述することができます。
XMLでは「知らないタグは読み飛ばす」ということをよく行いますが、SOAPのアプリケーションではそれを禁止することができます。mustUnderstand属性が1（true）であり、アクターがそのXMLを知らない（処理する機能がない）場合、次に説明するFaultを返さなければなりません。
SOAPのランタイムがエラーを検出したとき、SOAPにFault要素を入れて送信することが決められています。Fault要素はBodyの中に一つだけ入れることができます。
Fault要素には、以下の要素が入れられます。
| VersionMismatch | SOAPエンベロープの名前空間が合わない |
| MustUnderstand | mustUnderstand=”1”が指定されているXMLが処理できなかった |
| Client | クライアントが送ってきたXMLがおかしい |
| Server | サーバー上のなんらかのエラー |
人が読むためのエラーメッセージ
このFaultを作ったサーバー
詳細な情報
SOAPはそもそもRPCを行うために作った仕様ですから、RCPを行うための規則が標準で含まれています。SOAPエンコーディングもRPCを行うために重要です。
RCPを行うためにはメソッドの引数や戻り値に使われる変数、配列、オブジェクトなどをXMLに変換したり、もとに戻したりする必要があります。データをXMLとして記述することを「エンコード」または「シリアライズ」、元に戻すことを「デコード」または「デシリアライズ」といいます。
XMLは単純に記述するとすべてのデータはテキストとして記述されてしまいますから、データ形式をいっしょに記述する必要があります。SOAPの規約では、データをXMLにエンコードする方式として「XML Schema Datatype」を使うことになっています。XML Schema Datatypeを使うSOAPエンコードの名前空間は以下のものを使います。
http://schemas.xmlsoap.org/soap/encoding/
これに対して、普通のXMLエンコーディングを行うことをXMLリテラルエンコーディングといいます。
XMLエンコーディングにおいて、複雑な構造体もエンコードできるように、値、単純型、複合値、アクセサ、配列、構造体、単純型、複合型、単一参照、多重参照、独立、埋め込みなどが決められています。詳細は、規約案を読むことをお勧めします。
たとえば、浮動小数点の100は、XMLリテラルエンコードとSOAPエンコードでは、次のようになります。
|
XMLリテラルエンコード <value>10.5</value> SOAPエンコード <value xsi:type="xsd:float">10.5</value> |
HTTPで使う場合、SOAPは多くの場合「リクエスト／レスポンス」型のとしてプログラムとして実装されます。このようなプログラムを「サービス」と呼ぶことから、SOAPサービスと呼ぶこともあります。「Webサービス」という言葉の語源ともなっています。
HTTPリクエストには、SOAPActionというHTTPヘッダーをつけることが決められています。これは、SOAPの意図を中間サーバーなどに伝えるために使われます。また、HTTPレスポンスでは、成功した場合は状態コード200を、エラーが起きたときは500を返すことが決められています。
SOAPのひとつの使い道としてSOAP-RPCが定義されています。SOAP-RPCでは、以下の情報を送受信する必要があります。
基本的に、メソッド名と同じタグ名、引数と同じ型と順序で同じタグ名でXMLを組み立てます。戻り値も同様です。対象オブジェクト（サービス）は名前空間で判断します。たとえば「priceList」サービスの「setPrice」メソッドで、文字列の商品コード「code」と整数の価格「price」を呼び出す場合、以下のようなXMLを組み立てます。
| <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Body> <m:setPrice xmlns:m="priceList"> <code xsi:type="xsd:string">0001</code> <price xsi:type="xsd:integer">2980</price> </m:setPrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> |
SOAP v1.1がNoteとしてW3Cに提案されたことにより、「XML プロトコルワーキンググループ」が発足しました。XMLプロトコルワーキンググループでは、SOAPの規約を策定しSOAP仕様を完成させる活動をしています。現時点での最新の仕様は2000年12月に発表されたワーキングドラフトです。
SOAP v1.2では、SOAP v1.1で決めていたことをより実用的に完成度を上げるとともに、規約を3つに分けて、記述してある内容を整理しました。大きな変更点はありませんが、言葉を明確に定義しなおしたり、複数のXMLを同時に入れる場合の方法を明文化したりするなど、まとめなおしを行っています。
SOAP v1.2の仕様はワーキングドラフトであることからも、今後変更される可能性があり、本文献では、目次の紹介にとどめます。
以下のアドレスから入手することができます。
以下のアドレスから入手することができます。
以下のアドレスから入手することができます。
SOAPは、今後RPCやXMLデータ交換だけでなく、非同期メッセージング、ワークフローなどにも使われることが考えられています。ここでは実用化されているSOAPの規約案を二つ紹介します。
XML電子署名の証明書や証明データを、SOAPヘッダーに入れて送受信する方式を決めたものです。
SOAPに添付ファイルを入れて送受信するための方式を決めたものです。HTTPにMIMEパートを使ってSOAPエンベロープとバイナリ−データを同時に送受信する方式です。
SOAPはXMLですから、SOAPメッセージを自分で組み立てて送受信するプログラムを作ればSOAP通信は可能です。しかし、SOAPがそもそもRPCのために作られたこともありサービスを提供する側にはサーバーランタイムが、サービスを呼び出す側にはクライアントAPIが準備され、RPCでよく使われるスタブコード（SOAPではプロキシーといいます）を生成して動かします。そうすることにより、SOAPアプリケーションの開発を格段に簡素化することができます。
SOAPの仕様はXMLで、プラットフォームに依存しない仕様となっていますが、実際に使うときにはSOAPを実行するときの実行環境がさまざまなプラットフォームや言語に提供されています。
Microsoft社のSOAPランタイムです。Microsoft社のSOAPはドットネット（.NET）のフレームワークの重要な位置付けをもっており、ビルディングブロックサービスを構築するための手段となっています。
MS-SOAPでは、SOAPのXML構造を直接操作する低レベルAPIとRPCとして操作するための高レベルAPIがあります。次に紹介するApacheSOAPと並んで、多くの機能を提供するSOAP実行環境です。
ApacheSOAPは、IBMが開発したJava用のSOAP実行環境「SOAP4J」をオープンソース団体「Apache」でオープンソース化したJava用の実行環境です。ApacheSOAPはServletAPI 2.2とJSP 1.1をサポートするサーブレットエンジンで稼動します。
ApacheSOAPには、サーバーでSOAPサービスを実行するための実行環境、クライアント用APIなどを提供しています。
ApacheSOAPでは、JavaBean、EJB、COMなどのSOAP-RPC化、SOAPメッセージング、SOAPアタッチメント、SOAP電子書名、HTTP、SMTP、Filterプログラムなど、非常に多くの機能を提供します。
ApacheSOAPの正式最新版は2.2です。次のバージョンは名前が変わり、ApacheAXISとなります。AXISになるとSAXを利用した実装によりパフォーマンスが改善され、WSDLのサポートなども追加されます。
Javaには非常に多くのSOAPランタイムが存在します。GLUE、JSOAPなどフリー、あるいは安価なSOAPランタイムのほか、ほとんどのJavaアプリケーションサーバーを提供しているベンダーがSOAPの実行環境を提供しています。AapcheSOAPを採用したり、参考して独自実装したりしているものが多いため、Java同士のSOAPの相互接続性は非常に高いと言われています。
その他、Ruby用の「SOAP4R」、Perl用の「SOAP::Lite」などがあります。