WSDLでWebサービスを記述する：パソコンで試してわかるWebサービス（6）（2/4 ページ）

[イチロー，樋口研究室監修]

「マニュアル運転」Webサービス化の流れ

　この後の話を進める前に、一度これまでのおさらいをしておきます。これまでの「マニュアル運転」がどのようなものであったかを再認識することで、「何が便利になるのか？」を明らかにしていきます。

　まず、サンプルのJavaBeans（SimpleAddBean.class）を作りました。このJavaBeansは、数字を加算して結果を返すものです。そして、JavaBeansの動作を確認するためにJavaアプリケーションとして実行しました。

図1　SimpleAddBean.classは数字を加算して結果を返すJavaBeans

　次にこのJavaBeansをWebサービスとして動かしました。Webサービスとして動かす場合、まず、JavaBeansをTomcat上のAxisアプリケーション配下のディレクトリにコピーします。これにより、Axisによって提供されているServlet版Webサービス・エンジン上でJavaBeansが実行されます。

図2 SimpleAddBeans.classをServlet版Webサービス・エンジン上で実行する。ただし、これだけではWebサービスとして動かない

　単にJavaBeansをコピーしただけでは、Webサービスとして動きだしません。JavaBeansをWebサービスとして動かすために、どのような条件で稼働させるかを記述した「配置記述子ファイル」を用いて「配置（Deploy）」という作業を行いました。配置作業にはAxisにより提供されているDeployプログラムを利用します。

　この配置情報によって、JavaBeansは「SimpleAddService」というサービス名として動き始めます。

図3　配置によってWebサービスとして動き始める

　この状態で、JavaBeansはWebサービスとして実行できる状態になります。さて、次にこのWebサービスにアクセスするためのクライアント・プログラムを準備しました。このWebサービス・クライアントは、「SimpleAddService」に接続し、このWebサービスの持つ機能を呼び出します。

図4 Webサービスをクライアント・プログラムから利用する

　そして、Webサービス・クライアントが最初のJavaアプリケーションのときと同じ結果を得るためには、Webサービスのスコープを考慮する必要があり、Webサービス・クライアントにおいても、Sessionスコープを利用できるように記述する必要がありました。

　これまでの「マニュアル運転」の流れは以上です。この流れの中で、2つの「立場」があることが分かりますか？ プログラム的にはWebサービスとWebサービス・クライアントになりますが、立場という意味では「Webサービスを提供する側」と「Webサービスを利用（要求）する側」の2つといえます。この2つの立場について少し考えてみましょう。

Webサービスを演じる2つの立場

　「サービス」をインターネットやイントラネットなどのネットワーク環境で提供することがWebサービスの基本的な目的です。この「Webサービス」を提供する人を「Webサービス・プロバイダ（Web Service Provider）」といいます。これまでのサンプル・プログラムでは、「SimpleAddService」サービス用のBean「SimpleAddBean.class」を作り、その配置用の配置記述子「SimpleAddService.wsdd」を用いて配置し動作させるまでの作業が、サービス・プロバイダの役割になります。

　Webサービスを提供する人がいれば、それを使う人がいます。Webサービスの利用者を「要求する人」という意味で、「Webサービス・リクエスター（Web Service Requestor）」といいます。サンプル・プログラムでは、Webサービス・クライアント「SimpleAddClient.class」を作る人になります。

図5 Webサービス・プロバイダとWebサービス・リクエスターの関係について考えることが大切

　これまでの連載では、Webサービス・プロバイダとWebサービス・リクエスターの立場を明確に切り分けて考えずに、「クライアント／サーバ」の関係で考えてきました。WSDLの特徴を知るために、Webサービス・プロバイダとWebサービス・リクエスターの関係について考えてみます。

　まずは、Webサービス・プロバイダの視点を考えてみましょう。Webサービス・プロバイダはJavaBeansなどをWebサービスとしてネットワークに公開します。公開するときにスコープなどは考慮する必要がありますが、Webサービス・クライアントのことを意識する必要はありません。たまたま、今回の連載では同じJavaによるWebサービス・クライアントを使いましたが、Webサービスが目指すのは異機種間の接続のため、Webサービス・クライアントは何が利用されるかは分かりません。

　次にWebサービスを利用するWebサービス・リクエスターの視点から考えてみます。Webサービス・リクエスターはWebサービス・クライアントを作ります。Webサービス・クライアントを作るときには何が必要だったでしょうか？

　第3回のWebサービス・クライアントのプログラムを見てみましょう。プログラムの中に固定文字列として書き込んでいる部分などは、クライアント・プログラムを作る前にサービス・プロバイダから聞いて知っておく必要があります。例えば、サービス名である「SimpleAddService」や、そのサービスの機能である「inputValue」などがあります。また、変数の型がString型なのかint型なのかも事前に聞いておく必要があるでしょう。Webサービスがネットワーク上のどこで提供されているかを指定するためのURLも聞いておく項目の1つです。

　このようにWebサービスを利用するWebサービス・クライアントを作るには、Webサービスの仕様を知っていなくてはプログラムを作ることができないというのが分かります。

Webサービス情報の共有

　これらの情報はWebサービスとWebサービス・クライアントがSOAP通信をするために必要な情報です。第5回までは、Webサービス・プロバイダもWebサービス・リクエスターも読者の皆さんが演じていたため、これらの情報を共有することができました。そのため何の問題もなくプログラムを作成することができましたが、ネットワークを介した2人の間で作ろうとしたら、どうなるでしょうか？ Webサービス・リクエスターはWebサービス・クライアントを作るために、Webサービス・プロバイダと事前にどのような会話をする必要があるでしょうか？ Webサービス・リクエスターはWebサービスを利用する前に、Webサービス・プロバイダとの「事前の会話」が必要になります。

　この会話は決まった情報をやりとりします。簡単には「どこ」「なに」「どのように」という情報です。よってこれを「システム化」することを考えるのは普通の流れであり、この「システム化された会話」こそ、これまでの「マニュアル運転」から「オートマ運転」にすることになるのです。システム化せずに事前の会話を電話でやるなんて、インターネット時代にスマートではないですから。

　この「システム化された事前の会話」を記述する言語が、WSDL（Web Services Description Language）です。もう1つの見方としては、WSDLはWebサービスの仕様書ともいえます。サービスを利用する際に利用者が仕様書を必要とするのは当たり前です。Webサービスでは、さらにWebサービスの実態がJavaBeansだろうがEJBだろうが、利用者にはあまり関係はありません。WSDLさえ記述しておいてくれて、SOAPの互換性が保たれているWebサービスであればそれでいいのです。

図6 WSDLはWebサービスの仕様書。これを作るのはWebサービス・プロバイダの役割

　WSDLはWebサービス・リクエスターがWebサービスを利用するのに必要な情報が含まれている必要があります。すなわち、Webサービス・クライアントを作るのに必要な情報が記述されているはずです。

　では、このWSDLは誰が作成するのでしょうか？ これはすぐに理解できると思いますが、WSDLを作成するのは、Webサービス・プロバイダの役割です。Webサービス・プロバイダはJavaBeansを作成し、配置記述ファイルを用いて配置し、その後このWSDLを作成します。

　この後WSDLの中身を見ていくことにしましょう。単に見ても面白くないので、これまで作ってきたサンプル・プログラムのWSDLを作って、それを解析してみることにしましょう。