SOAPの正体、その目論見（前編）：SOAPの正体、その目論見（1）（2/4 ページ）

[西谷亮，マイクロソフト株式会社]

クロスプラットフォームでオブジェクト間通信を実現

■SOAPとはオブジェクトへアクセスするプロトコル

　SOAPとは、その名のとおり、単純にオブジェクトへアクセスするためのプロトコルの仕様です。端的にいってしまえば、アプリケーションを構成するコンポーネントが存在していて、それらをインターネットなどの回線を通じて簡単に連携できるようにしようというのが大きな目標です。

　では、今までの、つまり現状のオブジェクト間連携を確認しておきましょう。

　今までオブジェクトというものの通信には、さまざまな手段が提供されていました。Windows の世界では一般的なコンポーネントテクノロジであるCOM(Component Object Model)では、RPC（Remote Procedure Call）といった呼び出し手続きがありますし、CORBA（Common Object Request Broker Architecture）の世界では、IIOP(Internet Inter-Orb Protocol)という手続きがあります。これらのオブジェクト呼び出しのための手続きは、おのおののアーキテクチャのために存在しており、もちろん、そのために最適化もされています。これらは、COMからCOM、もしくはCORBAからCORBAといった、同一アーキテクチャの中での参照、呼び出しを行うには非常に有効な手段であると考えられます。しかし、こうした状況は変わってきました。インターネットがアプリケーションの内部にまで浸透し、COMやCORBAなどの1つのアーキテクチャ内で閉じた世界だけでは解決できないソリューションというものが顕在化してきました。つまり、COMからCORBA、もしくはその逆。つまりクロスプラットフォームにおけるオブジェクト間連携のための手法が求められるようになってきたのです。

　もちろん、これらは既存の技術だけでも対応できる面はあります。COMからCORBAのためのブリッジが用意されて連携しあうことができるようになっている、というのはその一例でしょう。しかし、これらのようなブリッジが存在するといっても、根本的な解決とならないケースが見受けられます。例えば、特定のミドルウェアしかサポートすることができなかったり、品質や機能の不足、また、相互運用実現のためのコストが高くなってしまうなどが挙げられるでしょう。もちろん、使用されている言語間のマッピングやIDL（Interface Description Language）の相違など、さまざまな要件によって、実現への壁が高くなっていることは否めません。

　そこで、インターネットの世界で標準となったXMLに白羽の矢が立ちました。XMLのシンタックス形式を利用したプロトコルを開発することで、さまざまにはんらんしているオブジェクト技術を相互に結びつけられるようにしようと検討され始めました。その結果完成したのが、この SOAP だったというわけです。

　SOAPは、オブジェクト同士を連携させるためのプロトコルです。従って開発者は、SOAPを利用したXMLメッセージの交換を意識することなくアプリケーションの開発を行い、システム間連携を実現できるというのが開発環境上のベストなソリューションであるといえるでしょう。とはいえ、その中でどのような（XML形式の）メッセージ交換がされているのか、そしてどのようにして連携を実現しているかという点は、気になるところでもあります。SOAPというプロトコルの中をのぞきこんでいくことにしましょう。

■SOAPをやりとりする仕組み

　SOAPは、HTTPや SMTPといったプロトコルの上位に位置します。そして、そのパケットの中で、オブジェクト呼び出しに必要なXMLメッセージの交換を行うためのプロトコルです。SOAP自身は、HTTPやSMTPといった下位プロトコルには非依存です。どんなプロトコルであっても、SOAPのメッセージを送信、もしくは受け取ることができ、そしてその内容をシステムが解釈できれば、問題ないとされています。一般にはHTTPが利用されることが多いと思われますが、SMTPやFTPのプロトコルにのせることも可能です。

　SOAPが、単純にXML文書をHTTPやSMTPで送るのともっとも違う点は、XML文書に対してエンベロープと呼ばれる付加情報を追加できる点です。これによって、オブジェクトへの宛先、あるいは必要に応じてメッセージIDなどの付帯情報を自由に付加できる点です。エンベロープの構造などについては、後ほどあらためて説明します。

　ここでは、理解を容易にするためにHTTP上で交換されることを前提として、SOAPメッセージの仕組みを紹介していきましょう。

　SOAPのメッセージ交換では、呼び出すオブジェクトとパラメータ、そして呼び出し結果などの情報が交換しています。もちろん、その戻り値自身もXML文書になります。まずは、どのようにしてメッセージ交換を実現しているか、仕組みをまとめておきましょう。

　単純な流れで見ていくことにします。オブジェクトを提供する環境はどのようなものでも構いません。まず、クライアントとなる環境では、オブジェクトの呼び出しとして、オブジェクトが提供されているサイトに対しSOAPメッセージを送信します。受け取ったサイトでは、そのSOAPメッセージを解釈し、どのオブジェクトにマッピングするかを判断、その上で実行結果を XML文書（SOAP メッセージ）として生成し、送信元へ返します。

　この際に重要となるのが、それぞれのサイトでは、SOAPメッセージを生成するエンジンと、それを解釈するためのエンジンが必要になるということです。クライアント環境からのオブジェクト呼び出しでは、実際のオブジェクト呼び出しが実行されたときに、その命令がSOAPプロキシといわれるSOAP メッセージのシリアライザに受け渡されます。この部分でSOAPメッセージを生成し、オブジェクトを提供するサイトへ送信します。

　また、このSOAPメッセージを受け取るサイト側では、SOAPリスナというものが必要です。ここでは、受け取ったメッセージを解釈し、どのオブジェクトを呼び出せばいいのかを判断、そして実行した結果を送信元に返していきます。このようにして、送受信されているXMLベースのSOAPメッセージの仕様が標準化されていることで、異種プラットフォーム間でもオブジェクト間連携ができるようになったのです。

図1　SOAPの呼び出しと応答
オブジェクトを呼び出す側と、呼び出される側、両方で、SOAPメッセージを生成するエンジンと、それを解釈するためのエンジンの実装が必要になる

　ここでのポイントは、各プラットフォームもしくは、オブジェクトシステムにおいてSOAPリスナやプロキシが実装可能かどうかということです。もちろん、自前で実装してしまうというのも1つの方法です。

　Windows環境にのみフォーカスして紹介しますと、英語版ながら現在のところSOAP Toolkit for Visual Studio 6.0というツールがWeb上で提供されています。これは、作成したCOMコンポーネントを、SOAPを利用した仕組みにのせ、SOAPメッセージを利用し、外部からの呼び出しに対応させることができるツールです。ASP(Active Server Pages) やISAPI(Internet Service Application Programming Interface) を利用した、リスナやプロキシの生成をウィザード形式で行ってくれます。将来提供されていく.NET Frameworkのランタイム環境下では、SOAPの仕組みがはじめからインプリメントされているようになります。これによって、オブジェクト（クラス）を生成すると自動的にSOAPを利用したオブジェクト呼び出しに対応することができるようになっていきます。