WSDL文書によるインターフェイス定義の仕上げ：Webサービスのキホン（6）

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:biding要素の例
抽象的な定義に対応する具体的な定義を行うのが、wsdl:binding要素だ

　リスト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要素によって具体的なプロトコルやフォーマットに関連付けられたバインディングに、具体的なネットワークアドレスを関連付ける要素だ。

リスト2　wsdl:port要素の書き方

　wsdl:port要素には、binding属性とname属性という2つの属性がある。binding属性には、wsdl:binding要素で定義されたバインディングのうち使用するバインディングの名前を指定し、name属性にはポート名を指定する。リスト2では、binding属性に「impl:EstimateSoapBinding」というバインディング名を指定してバインディングを参照している。

（3）サービスを定義する（wsdl:service要素）

　wsdl:port要素をグループ化して1つのサービスを定義するのがwsdl:service要素だ。以下のリスト3を見ていただきたい。

リスト3　wsdl:service要素の書き方
wsdl:service要素の中でサービス名「Estimate」を定義している

　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のようになる。

図3　wsdl:service要素、wsdl:port要素、wsdl:binding要素の関係

抽象的な定義と具体的な定義の分離

　WSDLは、抽象的なメッセージやポートタイプのような抽象的な定義と、バインディングやポートのような具体的な定義とを分離して定義している（図4）。

図4　抽象的な定義と具体的な定義の分離

　この連載の第4回「WSDL：Webサービスのインターフェイス情報」で、WSDLは抽象的な定義と具体的な定義の2段構えでインターフェイスを記述すると述べた。図4で示すとおり、WSDLは再利用できる抽象的な定義と再利用できない具体的な定義とを分離して定義し、それらをバインドさせるという仕組みになっていることが分るだろう。

WSDL拡張性要素を使ってプロトコル依存の定義を行う

　第4回でも述べたが、抽象的な定義と具体的なプロトコルに依存する定義の橋渡しをするため、WSDLでは、WSDLの中核となる要素に加えて特定のプロトコルに依存する拡張性要素を使用する。WSDL仕様では、以下の3つのプロトコルについて拡張性要素を定めている。

　例として、SOAP 1.1にバインドするための拡張性要素（以下、SOAP拡張性要素と呼ぶことにする）を取り上げてみよう。抽象的に定義した操作をSOAP 1.1プロトコルにバインドする際、SOAP拡張性要素を使用して定義する主な情報は以下のとおりだ。

　これら以外にも、エラー情報の内容やSOAPヘッダの内容を指定するSOAP拡張性要素が用意されている。SOAP拡張性要素がwsdl:binding要素で出現しているところを以下のリスト4に示し、簡単に解説する。

リスト4　wsdl:binding要素の子孫として出現するSOAP拡張性要素の例

　リスト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で以下の点を改善すると表明している。

　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サービスの開発を行なう技術者の常識になってゆくことだろう。