SOAP（簡易オブジェクト・アクセス・プロトコル）と呼ぶメッセージ・プロトコルが注目を浴びている。XMLを用いて「インターネット版RPC（遠隔手続き呼び出し）」を実現するプロトコルである。SOAPの普及が進めば，企業間ECやアプリケーション・サービス・プロバイダのあり方が根本から変わる可能性がある。すでに，SOAPを使ったサービス・ディレクトリの整備なども始まっており，インターネットを使った分散システム構築の基盤技術となりつつある。
インターネットに接続したシステム同士を連携させるプロトコルSOAP（簡易オブジェクト・アクセス・プロトコル）が注目を浴びている。XML（拡張可能マークアップ言語）と企業間の電子商取引（EC）という，今ひとつ関係のすっきりしなかった両者を埋めるメッセージ・プロトコルである。「情報システムでXMLを使うには，どうしてもこの種のプロトコルが必要だった」（日本アイ・ビー・エム 東京基礎研究所 インターネット＆ランゲージ・テクノロジー担当 丸山 宏氏）という。米IBMのe-businessや，米マイクロソフトのMicrosoft.NETといった，インターネットを使った情報システムの基盤技術となりつつある。
ECやASPが根本から変わる
SOAPによって，企業間のECが根本的に変わる。これまで企業間のECといえば，FAXや電話の代わりにWebブラウザで受発注を処理する，いわゆるWeb EDIが主流だった。Web EDIで実際に受発注者の操作をするのは人である。
一方，SOAPでは人が操作するためのユーザー・インタフェースではなく，プログラムから呼び出すためのAPI（アプリケーション・プログラミング・インタフェース）を公開することができる。これらAPIが提供する機能を「Webサービス」と呼ぶ。
Webサービスには，通常のプログラムでアクセスする。たとえば，商品在庫が少なくなると自動で取引先のシステムにアクセスして発注するといった仕組みを簡単に作ることができる。
|
|
図1 SOAPを利用すれば外部のサービスを利用したシステム構築が可能に （a）従来の情報システムは，ほとんどの機能を自社内に作り込む必要があった。（b）SOAP（簡易オブジェクト・アクセス・プロトコル）を用いることで，ASP（アプリケーション・サービス・プロバイダ）がインターネットに公開したサービスをシステム構築に利用できるようになる。 |
業種に関係なく利用可能な汎用のサービス部品や，特定の業種内で共通に利用できるサービス部品は，いずれASPがWebサービスとして提供するようになる。細かな機能単位でサービスを提供するので，従来型のASPに見られたようなユーザーごとのカスタマイズの必要がほとんどない。その分スケール・メリットも大きく，ユーザーが同じ機能を作り込むよりもずっと安価にサービスを提供できる可能性が高い。さまざまなWebサービスが普及すれば，各企業は自社のシステムに固有の機能や，セキュリティ上どうしても自社に持つ必要がある機能だけを作り込めばよくなる（図1[拡大表示]）。
インターネットでRPCを実現
SOAPの仕様は，IBMやマイクロソフトなどが参加してWorld Wide Webコンソーシアム（W3C）で進めている。現在，SOAP1.1と呼ぶ仕様がドラフトになっている。原本は英語だが，マイクロソフトや日本アイ・ビー・エムが和訳したものを開発者向けサイト（http://www.microsoft.com/japan/developer/workshop/xml/general/soapspec.asp，http://www.jp.ibm.com/developerworks/link/soap.html）で公開している。
SOAPを使ったシステム連携では，SOAP対応のクライアントがWebサービスに何らかの処理を要求し，Webサービスが処理結果を返答する。このため，SOAPはインターネット版のRPC（遠隔手続き呼び出し）のプロトコルと言われることもある。
|
|
図2 SOAPを使ったメッセージ交換のメリット サービスとのメッセージ交換にXML（拡張可能マークアップ言語）を用いるため，細かな仕様の違いを比較的簡単に吸収できる。HTTP（ハイパーテキスト転送プロトコル）を利用してメッセージを転送すれば，ファイアウォールの内側からサービスを利用することもできる。 |
インタフェースの違いを吸収
RPCを実現する仕組みとしてはすでにCORBA（共通オブジェクト要求ブローカ・アーキテクチャ）や，マイクロソフトのDCOM（分散コンポーネント・オブジェクト・モデル），JavaのRMI（遠隔メソッド起動）といったものがある。しかしSOAPには，インターネットでRPCを実現するうえで，これら既存の仕組みに比べて大きな利点が2つある（図2[拡大表示]）。1つはデータの表現にXMLを用いていることである。企業間のECやASPのシステムは，さまざまなユーザー同士で通信できる方が都合がよい。XMLにはXSLT（拡張可能スタイルシート言語変換）と呼ぶ仕組みが標準で用意されており，柔軟にデータを変換することができる。
|
|
図3 SOAPメッセージの構造（HTTPを用いる場合） 手続き呼び出しに関する情報はSOAPエンベロープに格納する。エンベロープ内のSOAPヘッダーはトランザクション処理やセキュリティ情報のやり取りなどに使う。単純な手続き呼び出しではSOAPヘッダーを省略することもある。 |
ファイアウォール内から利用できる
SOAPのもう1つの利点は，メッセージ転送にHTTPを利用できる点である。ファイアウォールの内側の社内システムからインターネット上のWebサービスにアクセスする場合にも，ファイアウォールの設定をほとんどそのまま使える。クライアントとサーバーのやり取りはWebアクセスとほとんど同じだが，HTTPのヘッダーに続くメッセージ本体はSOAPエンベロープと呼ぶXML形式のメッセージになる（図3[拡大表示]）。手続き名やパラメータ値の指定はこのエンベロープ内に記述される。実際にはSOAPではメッセージ転送に使うプロトコルを規定していないので，FTP（ファイル転送プロトコル）やSMTP（簡易メール転送プロトコル）なども利用できる。データが大きくなるデメリットも
|
|
図4 SOAPメッセージの例 “www.stockquoteserver.com”というサーバー上のメソッド“GetLastTradePrice”を呼び出すメッセージ。SOAPボディ内に，このメソッドの引数（symbol）が格納される。この例ではSOAPヘッダーが省略されている。 |
SOAPでは約500バイトある図4のメッセージがそのままネットワークを伝わる。これに対し，DCOMやCORBAなどでは，引数をバイナリで符号化することや，SOAPのようなタグをメッセージに含めないことなどからSOAPに比べて数割程度サイズが小さくなる。
このように処理の効率までを含めて考えればSOAPが常に最適な選択肢だとはいえない。実際のWebサービスでは，サービス・プロバイダ内のサーバー間の連携や，高速処理が必要な連携部分はCORBAやDCOMで構築し，Webサービスとして公開するインタフェースだけをSOAP対応にする方法が一般的になるだろう。
評価ツールはすでにリリース
SOAPを使って実際にシステムを連携させるためには，クライアントとサーバーにSOAP対応のモジュールが必要である。具体的にはクライアント上で手続き呼び出しの情報をSOAP形式に変換するシリアライザと，サーバー上でSOAPメッセージから必要な情報を取り出して，目的の手続きを呼び出すディスパッチャである。
すでにIBMやマイクロソフトがSOAPを利用するためのツールをリリースしている。しかしこれらを使えば，すぐにSOAPを使った分散システムを構築できるわけではない。現在のツール群で実現できることは，せいぜい特定のサーバー間で単純な問い合わせを処理するといったことに過ぎない。トランザクション処理，セキュリティなどはSOAPの仕様で規定しておらず，整備はこれからである。現在のSOAP環境自体，評価目的の性格が強い。将来はDCOMやCORBAなど既存技術とシームレスに統合できる開発環境が整備されてくるだろう。
ディレクトリの整備が始まる
Webサービスを提供するプロバイダが増えれば，必要なWebサービスを探し出す仕組みも必要になる。
|
|
図5 UDDIのサービス 米IBM，米アリバ，米マイクロソフトの3社が共同でWebサービスの情報を登録，公開するディレクトリ・サービスを運営する。まず，Webサービス・プロバイダがこのディレクトリにサービスを登録する。サービス利用者は，必要なサービスの情報をディレクトリから取り出し，サービス・プロバイダにアクセスしてサービスを利用する。 |
UDDIではまずIBM，アリバ，マイクロソフトの3社が，共同でWebサービスのディレクトリ・サービス（ビジネス・ディレクトリ）を立ち上げる。Webサービスの提供を始めたプロバイダは，このディレクトリにサービスを登録する。
サービスを利用したい企業は，このディレクトリに欲しいサービスがあるかどうかを問い合わせる。ビジネス・ディレクトリ自身がWebサービスとなっているのでサービスの登録や検索にはSOAPを使える。必要なサービスが見つかれば，あとはそのサービスのプロトコルを用いてサービスを利用する。
こうしたディレクトリ・サービスを構築/運用するには，サービス内容を正確に記述するための言語も必要である。従来，IBMやマイクロソフトがそれぞれ記述言語を提案していた。それが2000年9月25日に，両社が共同でWSDL（Webサービス記述言語）を発表し，実質的な標準になると見られる。
