WSDL文書によるインターフェイス定義の仕上げ：Webサービスのキホン（6）
Webサービスの基軸を構成するのは、SOAP、WSDL、UDDIの3つのテクノロジだ。この連載では、Webサービスの基本的な知識を身に付けるために、この3つのテクノロジの背景と仕様、機能などを分かりやすく解説していく。（編集局）
Webサービスインターフェイスの具体的な定義
WSDL文書によるWebサービスのインターフェイスを定義する方法の解説も3回目となる（前々回「WSDL：Webサービスのインターフェイス情報」、前回「WSDL文書が持つ二層構造の前段部」）。これまで、WSDL文書はWebサービスのインターフェイスを抽象的に定義したうえで、それを具体的なインターフェイスとして定義し直すという構造を持つことを解説してきた。前回はその抽象的な部分を説明したので、今回は後半の具体的な定義を解説する。
前回、前々回にも登場したWSDL文書の構造図をあらためて示す。今回はこの中で、具体的な定義を行っているwsdl:binding要素と、wsdl:service要素について説明することになる。
図1 WSDL文書を構成する主要な要素
図中で箱が3重に表現されている要素は、複数回出現可能なことを表している。wsdl:message要素、wsdl:portType要素、wsdl:operation要素、wsdl:binding要素、wsdl:service要素とwsdl:port要素がそれに該当する
（1）プロトコルにバインドする（wsdl:binding要素）
抽象的な操作や抽象的なメッセージを、具体的なプロトコルや具体的なメッセージにバインドするために使用する要素がwsdl:binding要素だ。WSDLでは、抽象的なポート定義であるポートタイプに、具体的なプロトコルをバインドした定義のことをバインディング（binding）と呼ぶ。
以下のリスト1で、wsdl:portType要素で定義された抽象的な操作が、どのように具体的に定義し直されるかに注目していただきたい。
リスト1にあるとおり、wsdl:binding要素にはname属性とtype属性がある。次で説明するport要素で参照できるよう、name属性にバインディング名を指定しておく。またwsdl:type属性は、どのポートタイプをバインドするかを指定する。リスト1では「impl:Estimate」というポートタイプ名を指定して、参照するportType要素を指定している。
ここまでで説明したwsdl:binding要素、wsdl:portType要素、およびそれらの子孫要素の関係を整理すると図2のようになる。
図2 wsdl:binding要素とwsdl:portType要素の関係
wsdl:portType要素によって抽象的に定義された内容が、wsdl:binding要素によって具体的な操作へと再定義される
（2）具体的なポートを定義する（wsdl:port要素）
ネットワーク上に存在するWebサービスにアクセスするには、そのネットワークアドレスを知る必要がある。wsdl:port要素は、wsdl:binding要素によって具体的なプロトコルやフォーマットに関連付けられたバインディングに、具体的なネットワークアドレスを関連付ける要素だ。
wsdl:port要素には、binding属性とname属性という2つの属性がある。binding属性には、wsdl:binding要素で定義されたバインディングのうち使用するバインディングの名前を指定し、name属性にはポート名を指定する。リスト2では、binding属性に「impl:EstimateSoapBinding」というバインディング名を指定してバインディングを参照している。
（3）サービスを定義する（wsdl:service要素）
wsdl:port要素をグループ化して1つのサービスを定義するのがwsdl:service要素だ。以下のリスト3を見ていただきたい。
wsdl:service要素のname属性にはサービス名を指定する。リスト3では「Estimate」というサービス名を指定している。wsdl:service要素は、子要素としてwsdl:port要素を0個以上持つ。つまり、同一サービス内に複数のポートを定義できる。具体的な例として、同じ内容のサービスを、HTTP/SOAPやHTTP GET/POSTやSMTP/SOAPなど、複数のプロトコルを使ってアクセスできるようにする場合が考えられる。また、ネットワークアドレスの異なる複数のサーバに負荷分散させる場合にも複数のポートをサーバの数だけ定義することになる。
ここまでで説明したwsdl:port要素、wsdl:service要素、wsdl:biｎding要素の関係を整理すると図3のようになる。
抽象的な定義と具体的な定義の分離
WSDLは、抽象的なメッセージやポートタイプのような抽象的な定義と、バインディングやポートのような具体的な定義とを分離して定義している（図4）。
この連載の第4回「WSDL：Webサービスのインターフェイス情報」で、WSDLは抽象的な定義と具体的な定義の2段構えでインターフェイスを記述すると述べた。図4で示すとおり、WSDLは再利用できる抽象的な定義と再利用できない具体的な定義とを分離して定義し、それらをバインドさせるという仕組みになっていることが分るだろう。
WSDL拡張性要素を使ってプロトコル依存の定義を行う
第4回でも述べたが、抽象的な定義と具体的なプロトコルに依存する定義の橋渡しをするため、WSDLでは、WSDLの中核となる要素に加えて特定のプロトコルに依存する拡張性要素を使用する。WSDL仕様では、以下の3つのプロトコルについて拡張性要素を定めている。
● SOAP 1.1
● HTTP 1.1 GET/POST
● MIME
例として、SOAP 1.1にバインドするための拡張性要素（以下、SOAP拡張性要素と呼ぶことにする）を取り上げてみよう。抽象的に定義した操作をSOAP 1.1プロトコルにバインドする際、SOAP拡張性要素を使用して定義する主な情報は以下のとおりだ。
（1）SOAP 1.1プロトコルへのバインドの宣言（wsdlsoap:binding要素）
wsdlsoap:binding要素は、SOAPプロトコルにバインドする。wsdlsoap:binding要素は、操作が「RPC指向」なのか「文書指向」なのかを指定する。「RPC指向の操作」とは、入力メッセージがパラメータで構成され、出力メッセージがその戻り値となるRPCを実現する操作のことだ。「文書指向の操作」とは、例えばXML形式で記述された発注書のようなXML文書をそのままやり取りする操作のことだ。さらにwsdlsoap:binding要素ではSOAPメッセージがどんなプロトコルで送受信されるのかも指定する。
（2）操作全体の定義（wsdlsoap:operation要素）
soap:operation要素は、操作全体に関する情報を定義する。HTTPヘッダに含めるSOAPActionの値はこの要素で指定する。
（3）SOAPメッセージ本体の内容指定（wsdlsoap:body要素）
wsdlsoap:body要素は、SOAPメッセージ本体であるsoapenv:body要素内をどのように組み立てるか、を指定する。組み立た方は2種類ある。wsd:part要素で指定されたスキーマ定義のまま組み立てる「リテラル形式」と、SOAPエンコーディング規則のような特定のエンコーディングルールにしたがって組み立てる「エンコード形式」の2種類だ。
（4）通信ポートのアドレス指定（wsdlsoap:address要素）
wsdlsoap:adress要素は、wsdl:port要素の子として出現して具体的なネットワークアドレスを指定する。
これら以外にも、エラー情報の内容やSOAPヘッダの内容を指定するSOAP拡張性要素が用意されている。SOAP拡張性要素がwsdl:binding要素で出現しているところを以下のリスト4に示し、簡単に解説する。
リスト4では、wsdlsoap:binding要素のstyle属性に「rpc」が指定されているので、操作方式は「RPC指向」になる。またtransport属性に「http://schemas.xmlsoap.org/soap/http」というURI値が指定されており、プロトコルとしてHTTPを使用することを意味している。またwsdlsoap:body要素のuse属性に「encoded」が指定され、encodingStyle属性にSOAPエンコーディング規則を意味するURI値「http://schemas.xmlsoap.org/soap/encoding/」が指定されている。これは、この入出力メッセージはいずれもSOAPエンコーディング規則に従ってエンコードされることを意味している。
WSDLのその他の要素・属性
この記事で説明した要素以外にもWSDLには、ほかのWSDL文書の定義を取り込むwsdl:import要素や、注釈を記述するwsdl:documentaion要素など、実用上重要な要素がいくつかある。それらについては、参考書籍などを読んで勉強されることをお勧めする。
WSDLの今後と課題
現在一般に実装されているWSDLバージョン1.1の仕様にはあいまいな記述が存在しており、仕様の解釈の違いが原因で、異なる開発ツールで開発したWebサービスが相互に接続できないという事態が生じてしまった。例えば、wsdl:types要素、wsdl:message要素、wsdl:portType要素の出現順序が明確でなかったり、SOAPをXML Schemaで表現する方法があいまい、などの点がある。
W3CはWSDLの改訂作業を進めており、これまでのあいまいさを排する努力がなされている。ただし、進められているWSDL 1.2は本稿執筆段階ではドラフトレベルにすぎず、まだ確定していない。W3CはWSDL 1.2で以下の点を改善すると表明している。
- 開発者が理解したり使ったりしやすい明確な記述言語にする
- 仕様の記述を、XML Schemaや、XMLの抽象的なデータモデルであるXML Information Setに対応させる
- 簡潔で柔軟なコンポーネント定義を行えるフレームワークを採用する
- 相互運用性の点で問題のあった仕様を削除する
- SOAP 1.2バインディングを追加する。さらに、HTTPバインディングを改善する
WSDLだけの話ではないが、WSDLやSOAPやUDDIといったWebサービスのコア技術の仕様が確定するまでの間、相互運用性の問題が生じないようにするために主要ベンダも積極的に努力している。2002年2月、BEAシステムズ、IBM、インテル、およびマイクロソフトは、Webサービスの相互運用性を促進させるため業界団体WS-I（Web Services Interoperability Organization）を設立させた。発足当初は参加していなかった大手ベンダのサン・マイクロシステムズも加盟し、主要ベンダの力が結集されつつある。
WS-Iは、Webサービス仕様の利用方法の規約策定やテストツールの開発によって、相互運用性を確保する活動を進めている。WS-Iが2003年2月に公開した「Basic Profile Version 1.0」（本稿執筆時点でワーキンググループ承認ドラフト）は、SOAP、WSDL、UDDIの仕様の解釈を明確に規定している（参考記事「WS-I：Webサービス互換性の実現に向けて」）。
W3CもWS-Iも相互運用性確保を目指しており、これらの仕様が確定すれば、Webサービスの実用化に向けてまた一歩大きく前進することだろう。
WSDLによる記述があれば、開発ツールやシステムがそれを読み込んでWebサービスのインターフェイスを実装するコードを自動的に生成できる。Webサービスを構築する技術者は生成されたWSDL文書をカスタマイズすればよく、効率的な開発が可能になる。またWebサービスを利用するユーザにとってもアクセスのための負担が減り、WSDLは重要な技術といえる。
WSDLはインターネットに公開されたアプリケーションを動的に発見・統合するという将来的なWebサービスの理想の実現に欠かすことができない技術だ。WSDLの基本的知識は、Webサービスの開発を行なう技術者の常識になってゆくことだろう。
Copyright © ITmedia, Inc. All Rights Reserved.