統合開発環境でWebサービスを作る：パソコンで試してわかるWebサービス（8）（4/4 ページ）

» 2003年05月21日 00時00分公開

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

JavaBeansのWebサービス化

　いよいよJavaBeansをWebサービス化します。

　J2EEナビゲーター内の「SimpleAddBean.java」でマウスを右クリックします。「Webサービス」−「Webサービスとしてデプロイ」を選択します。次のウィザードが立ち上がったら、何も変更することなく「終了」ボタンを押してください。

（クリックすると拡大します）

　これでWebサービス化は完了です。JavaBeansはWebサービスとして実行可能な状態になりました。

（クリックすると拡大します）

　下部のコンソール・ウィンドウを見ると先ほど停止したWebSphereテスト環境が再度起動していることが分かります。第7回までのAxisではTomcatを起動してWebサービスを利用しましたが、WSADではWebSphereテスト環境上にWebサービスが起動します。

　これでWebサービス・プロバイダの作業は終了です。後はWebサービス・リクエスターにWSDLファイルを渡してWebサービス・クライアントからアクセスしてもらうだけです。

WSDLからWebサービス・クライアントを作る

　ここからはWebサービス・リクエスタの作業です。第7回で行ったようにWSDLからWebサービス・プロキシ・クライアントを作成していきます。

　「Web Content」フォルダの中に「wsdl」フォルダがあります。ここにWebサービス・プロバイダにより作成されたWSDLファイルがあります。第7回までにおいて利用してきたWSDLファイルは１つのファイルでしたが、ここでは4つに分かれていますが内容的には同様なものです。

（クリックすると拡大します）

　Webサービス・クライアントを作成する場合は「SimpleAddBeanBinding.wsdl」ファイルを利用します。ここにフォーカスを当てたまま、メニューから「ファイル」−「新規」−「その他」を選択します。

（クリックすると拡大します）

　ウィザードが起動したら、「Webサービス」の「Webサービス・クライアント」を選択し、「次へ」ボタンを押します。

　ここでは、クライアント用プロキシを作成し、さらに作成されたプロキシをテストしますので、「作成されたプロクシーをテスト」にチェックを付けて「次へ」ボタンを押します。

　次の画面ではWSDLファイルを選択しますが、すでにbindingファイルが選択されています。もしbindingファイルが選択されていない場合は「ブラウズ」ボタンを押して選択してください。最後に「終了」ボタンを押します（「次へ」ボタンを押していっても構いませんが、設定はデフォルトのままでOKです）。

　「終了」ボタンを押すと下記のような警告ウィンドウが表示されますが、これは「OK」を押してください。

　これでWebサービス・クライアントの作成完了です。

Webサービス・クライアントのテスト

　フォルダ内には「SimpleAddBeanProxy.java」ファイルが作成されています。そして、右側の「Webブラウザ」にはテスト・クライアントが起動しています。

　Methodsウィンドウには、先ほどJavaBeansをテストした際の汎用テスト・クライアントと同様なメソッドが並んでいます。しかし、Webサービス・クライアントをテストしている証として「setEndPoint」「getEndPoint」メソッドが現れています。これは、Webサービス・プロバイダのURLを指定するためのメソッドです。

右側にテスト・クライアントが表示されている（クリックすると拡大します）

　テストは次の手順で進めます。

　まず、「setEndPoint」メソッドをクリックして、下記のURLを入力し、「Invoke」ボタンを押します。ただし、1点確認してください。ポート番号「9080」はWebブラウザのURLに記述されているポート番号と同一にします。

http://localhost:9080/JavaBeansWebServiceWeb/servlet/rpcrouter

InputsにURLを入力し、Invokeボタンを押す（クリックすると拡大します）

　これで、WebサービスのURLが設定されました。後は、前に行った汎用テスト・クライアントのときと同じように操作をします。ここではその手順をおさらいしておきます。

setInputValue()で「2」をInvoke
Add()をInvoke
setInputValue()で「5」をInvoke
Add()をInvoke
getResultValue()をInvoke

　結果の「7」が取得できましたか？

Resultに結果の「7」が表示される（クリックすると拡大します）

　これまでAxisでやってきたWebサービスと同様な動きをしていることが分かるはずです。

スコープは配置記述ファイルで設定

　さて、このテストを少し続けていると、値がどんどん加算されていくことが分かります。この動作がスコープで定義されているのは第4回、第5回で解説しました。現在のスコープを確認するには次の2カ所を確認します。

　まずは「コンソール」を見てください。JavaBeansファイルに仕込んでおいた「SimpleAddBeanがインスタンス化されました！」というメッセージが1回だけ表示されています。これはRequestスコープではなく、SessionスコープかApplicationスコープの動作であることが分かります。

　そして、もう1つの確認です。配置記述ファイルであるdds.xmlファイルを開いてみます。このscopeアトリビュートが「Application」になっていることが分かります。第7回までにやってきたのと同じように、スコープがJavaBeans版Webサービスの動作を決めていることが、統合開発環境の中でも確認できました。ということは、このスコープを変更することでJavaBeans版Webサービスの動作が変わるはずですので、それも試してみてください。

dds.xmlファイルを開く。scopeアトリビュートで動作が変わる（クリックすると拡大します）

本番環境へ配置するには

　さて、統合開発環境の中で十分テストされたWebサービスは、最終的に統合開発環境から取り出して、本番のJ2EEアプリケーション・サーバに配置します。最初に解説したようにJ2EEサーバに配置するにはJ2EEアプリケーション・パッケージであるEARファイルを作成し配置します。このEARファイルを取り出すにはJ2EEパースペクティブにて「JavaBeansWebService」を選択し、「EARファイルのエクスポート」を実行します。表示されたウィザードに適当な出力ディレクトリを指定して終了ボタンを押すことで、EARファイルを出力することができます。このEARファイルをJ2EEサーバに配置（Deploy）すると、そのサーバ上でWebサービスが動きだすことになります。

EARファイルをサーバにデプロイする（クリックすると拡大します）

　これで、WebサービスをJ2EEアプリケーションとして開発する手順を一通り解説しました。少し長い説明になりましたが、これを基本として、読者の皆さんの持っているJavaBeansを簡単にWebサービス化してみてはいかがでしょうか。

まとめ

　ここまでで、第7回までにやってきたことのほとんどすべてが統合開発環境の中においても実施できたことになります。これだけであればあまり便利になった感じがしないかもしれませんが、もう一度よく考えてみましょう。

　Webサービス・プロバイダは、「Webサービス化」することが重要なのではなく、いかによいサービスを提供するかが重要です。この「サービス」そのものが記述されているのがJavaBeans部分です。これを「業務ロジック」「ビジネス・ロジック」あるいはMVCパターンにおける「モデル」ということがあります。この部分の開発に専念し多くの時間を割くことが重要です。すなわち逆をいえば業務ロジック以外の開発はなるべく少なくすることが重要です。「Webサービス化する」部分は「業務ロジック以外の部分」であり、統合開発環境のウィザードなどにより容易に開発できればその分だけ業務ロジックに注力することが可能になります。

　今回のサンプルプログラムにおける「業務ロジック」部分は大変簡単に作成できるものだったため、あまり恩恵を受けてないような気がするはずです。しかし実際のJavaBeansはもっと複雑なものになるはずですので、その業務ロジックに注力できることは大変重要になるはずです。

　今回試していただいたように、統合開発環境ではJDKなどを利用して開発を進めるよりも、さらに自動化されたように感じるかもしれません。すなわち、コマンドで開発をしていたときよりもさらに「オートマ運転」になっていることが分かりますが、ここまできても「自動運転」にはなっていません。

　最も自動化されていない部分はどこでしょうか？もう気付いていらっしゃると思いますが、setInputValueやaddなどのメソッドを呼び出す部分は、かなり手動で実行していたはずです。この「どのメソッドを実行して、次にどのメソッドを実行するか？」という部分が自動化されない限り「オートマ運転」の域は脱していないことになります。さて、この部分を解決する方法はあるのでしょうか？

　結論からいってしまえば、「SOAPとWSDLだけでは無理」ということになります。すなわち、この連載では「自動運転」までたどり着くことはありません。「自動運転」を実現するには、ほかの技術を取り入れる必要があります。この技術は現在さまざまなものが検討され、一部利用できるようにもなってきています。今後これらの技術が成熟してきたときには、Webサービスの「自動運転」も可能になるかもしれません。

　さて、今回はここまでです。最初に「Enterprise JavaBeansのWebサービス化」をやってみると書きましたが、これは次回に持ち越します。WSADを導入された方は、自分でトライしてみてください。EJBを作ることができれば、Webサービス化は今回の作業と似ています。

　これまでの連載記事でWebサービスのハードルは低くなったかもしれませんが、EJBのハードルは依然として高い方がいらっしゃるかもしれません。せっかくですので、次回はEJBの敷居も低くしてしまいましょう。

　それでは、次回をお楽しみに。

「次回」へ

「パソコンで試してわかるWebサービス」バックナンバー