ファイアウォールを越えて異なるシステムを連携させるWebサービス。企業間で連携できるシステムでの利用が期待されている。ただし，幅広く普及するには乗り越えるべき課題がある。中でも大きなものが相互接続性と応用規約の一本化，そしてライセンス問題である。

（本誌）

図1●Webサービスの基本的な仕組み
Webサービスの提供者は，サービスのインタフェース情報をWSDL文書として公開する。利用者はまず，この情報を取得する。WSDL文書の定義に合わせて，相手のWebサービスを呼び出す。両者は，SOAPに基づいたXML文書をやり取りする。
リスト1●encoded 方式を用いたSOAP メッセージ
一つひとつのデータ要素に，型の情報が付与されている。
リスト2●literal 方式を用いたSOAP メッセージ
データ要素に付与されているのは，そのデータが表す意味のみ。 型の情報は含まれない。
　「Webサービス」という言葉が登場してから早くも数年が経過した。一部では既に実務に利用されている。Amazon.comの「Amazon Web Service（AWS）」や，Googleの「Google Web APIs」など，広く公開されているものもある。また最近は，応用分野も広がりつつある。例えばインターネット接続機能を持ったDVDレコーダーに，Webサービスを使って予約情報を登録するなど，ネットワークに接続可能な家電製品にWebサービス技術を利用することが検討されている。

　今後Webサービスがより広く普及するには，どの用途に使うべきか明らかにすることが重要だ。「キラー・アプリケーション」と呼べるものが出てくれば，勢いは加速するだろう。ただしその前提として，Webサービスにはクリアしなければならない課題が三つある。まず，Webサービスの相互接続性の確立。次に，Webサービスを応用する際に必要な規約（応用規約）の一本化。そしてライセンス関係の明確化である。

SOAPとWSDLがWebサービスの柱

　個々の課題に触れる前に，Webサービスの基本技術について整理しておこう。Webサービスはさまざまな規約に基づいて実現されている。中でも柱となるのはSOAP＊1とWSDL（Web Services Description Language）だ（図1[拡大表示]）。

　SOAPは，Webサービスでやり取りするメッセージに関する規約である。具体的には，XMLで記述したエンベロープ（封筒）の形式と，そのやり取りの方法を定めている。エンベロープに入れるメッセージもXMLで記述する＊2。

　SOAPではエンベロープ自身も，メッセージ本体もXML形式で記述する。それならばわざわざSOAPのようなエンベロープに入れず，そのまま送った方が効率的なはずだ＊3。しかしわざわざこのような規約が考えられたのには理由がある。メッセージ本体に追加する情報を同時に送れるからだ。

　例えば，メッセージ本体に電子署名を付加して，送信者を証明したいとする。電子署名の情報をメッセージそのものに含めようとすると，メッセージの構造が変わってしまう。封筒に記述した付加情報として，メッセージ本体とは別の情報を同時に送ることができればこのような問題は発生しない。

　もう一方のWSDLは，Webサービスの呼び出しインタフェースとアクセス・ポイントのURLを記述するためのものだ。Webサービスの利用者は，WSDLで書かれた内容を基にクライアント・ソフトウェアを作成する。

　WSDLで記述するインタフェースは大きく三つに分かれている。まず，Webサービスを呼び出す際のサービス名（portType）や必要な引数，戻り値などを記述する。次に，利用するプロトコルやメッセージのエンコーディング方法などを指定する。最後に，Webサービスそのものが提供されている場所をURLで記述する。

規約に選択の余地がある

　本来，この二つの基本仕様に準拠してWebサービスを開発すれば，異なるシステム同士が問題なく通信できるべきだ。しかし現実は違う。これが，Webサービスがクリアすべき一つ目の課題である。

　相互接続できない理由は大きく二つ。(1)システムによって規約の実装範囲が異なる，(2)システムによって規約の解釈が違う，である。

　(1)の問題は，実装すべき規約に選択の幅があるために起こる。規約には，どのシステムにも実装が義務付けられる「必須」の規定のほか，実装することが望ましいが必須ではない「推奨」の規定や，実装するかどうかを選択できる「許容」の規定がある。このため「一つの規約を実装した」と言っても，実態が同じとは限らない。規約の実装範囲が異なるシステムの間では，接続を保証できない。

　こうした問題のうちで最も大きなものが，SOAPメッセージのデータ型を指定する方式である。WSDLの規約では，2種類のデータ型指定方式を規定している。データ型指定方式はWSDLのuse属性で指定するが，use属性の値として「encoded」と「literal」の二つが認められている。

　encodedの場合，SOAPメッセージにデータ型指定の情報を付加して送る（リスト1[拡大表示]）。XML要素に，その内容となるデータのデータ型情報を属性として含める。それに付け加えて，SOAP Encodingという方法でSOAPメッセージに独自のデータ構造も指定できる。

　これに対してliteralでは，データ型をWSDLに記述しておき，SOAPメッセージには記述しない（リスト2[拡大表示]）。WSDLには，XML Schemaの形式で記述されたXMLのスキーマ定義を含める。ここに，データ型の情報も記述する。

　これまで広く使われてきたのはencoded方式である。SOAPの規約は，XML Schemaより前に規定されたためだ。特にJavaを採用したミドルウェアやアプリケーションの間で普及した実装方法である。しかし，Microsoftの.NET Frameworkではliteral方式が採用された。このため，Javaで開発されたWebサービスと.NET Framework上で動作するWebサービスとの間でうまく接続できなかった。

沼田 利典 Toshinori Numata

富士通 ソフトウェア事業本部 開発企画統括部 第一計画部
1984年，明石工業高等専門学校（電気工学科）卒業後，富士通に入社。POSIX，UI，OSF，The Open Group等でUNIXの国際化，地域化，日本語処理に関連した標準化活動に従事。Webサービス関連では，WS-I Basic Profile WG及びJapan SIGのメンバーとして活動中。