WSDLの部分の関連
では、前頁の（1）〜（4）の関連を考えてみましょう。（1）のmessageは（2）のoperationで利用されています。（2）のoperationは（3）で利用されています。（3）のbindingは（4）で利用されています。WSDLファイルの構造は次のようになっていることが分かります。
この図からも分かるように、（1）（2）のメッセージ／ポートタイプの定義と、（3）（4）のバインディング／サービス情報が分離されていることが分かると思います。（1）（2）には「どのような機能」であるかだけが記述されており、（3）（4）には「どこで」「どのようなプロトコルで」利用できるかが記述されています。特に（3）では、プロトコルが指定されており、わざわざ「SOAPのRPCを利用」という記述が見られます。
すなわち、WSDLではSOAPを利用することを前提に作られているわけでなく、さまざまなプロトコルに利用できることが前提として作られていることが分かります。たまたま、今回のサンプル・プログラムではSOAPのRPC機能でサービスを利用しているために、バインディング情報にSOAPのRPC利用の情報が記述されています。
Webサービス・リクエスターは？
Webサービス・プロバイダは、WSDLファイルをネットワーク上に公開します。Webサービス・リクエスターは「事前の会話」の代わりに、WSDLファイルをダウンロードします。ダウンロードしたWSDLファイルを見ればWebサービスの仕様を知ることができ、Webサービス・クライアントが作れるはずです。
確かに、WSDLファイルの中身をよく見れば作れそうな気がします。Webサービスがどこにあり、どのような引数と戻り値を持つ機能を持っているかを理解できます。それでは、WSDLの情報を基にWebサービス・クライアントを書いてみましょう。
と、これでは、「オートマ運転」ではないですね。確かに、Webサービス・プロバイダに電話して機能を聞く必要はなくなりましたが、単に「会話」が「説明書」になったくらいの違いなので、あまり便利になった感じがしません。
そこで、せっかくWSDLファイルがXML形式で提供されているわけですから、これを使わない手はありません。Webサービス・クライアントさえもWSDLを基にして自動的に作れないものでしょうか？
前回までは、「？」部分は作ってもらいました。まさに「マニュアル運転」だったわけです。そこで、この「？」部分を簡単にすることがWebサービス・リクエスター側の「オートマ運転」といえます。早速このWebサービス・クライアント側の「オートマ運転」教習にいきたいところですが、この教習は次回詳しくやっていきましょう。
まとめ
Webサービス・プロバイダの作業の流れは次のようになります。
作業の1つはWebサービスそのものを作ることです。そして、もう1つがそのWebサービスを記述したWSDLを外部に向けて公開することです。配置もWSDL作成もAxisの便利なコマンドで実施することができます。WSDLのおかげで、Webサービス・プロバイダはWebサービス・リクエスターからのWebサービスの使い方の問い合わせにいちいち回答する必要がなくなり、「オートマ運転」となります。
Webサービス・プロバイダの作業はおおむね見えました。そこで、今度はWebサービス・リクエスターの作業です。Webサービス・リクエスターはWSDLファイルを読めばWebサービス・クライアントをこれまでのサンプル・プログラムのように作ることができるかもしれません。しかし、それではやはり「マニュアル運転」のままです。
そこで、次回はこのWSDLファイルを基にWebサービス・リクエスター側の「オートマ運転」Webサービス・クライアント作成をやってみましょう。
それでは、次回をお楽しみに。
Copyright © ITmedia, Inc. All Rights Reserved.