検索
連載

Webサービスをツールキットで作るSOAPの仕掛け(5)(2/4 ページ)

PC用表示 関連情報
Share
Tweet
LINE
Hatena

Web Service Tool Kitのセットアップ

 本稿では、IBM WebSphere Application Server V3.5(以下、WAS 3.5)+IBM DB2 UDB V7.1(ワークグループ版、以下、UDB 7.1)を組み合わせて、SOAPサーバを構築する手順を紹介する。OSは、Windows 2000を利用する。WAS3.5、およびUDB7.1は、すでにインストールが済んでいるとし、UDB 7.1とWAS 3.5のプロセスが起動していることを確認してからインストールの手順を説明しよう。

インストールウィザードを起動する

 WSTKのダウンロードパッケージは、Linux用の「wstklinux23.bin」と、Windows用の「wstkwin23.exe」の2種類があるので、必要なものをダウンロードする。今回は、Windows用のものを利用する。JavaによるインストールプログラムであるJavaインストール・シールドになっているので、そのまま起動すればいい。すると、下記のような画面1が表示される。

画面1 WSTKを起動したときのインストール画面
画面1 WSTKを起動したときのインストール画面

インストールのウィザードには、以下のものが順に表示される。

  1. ウェルカムメッセージ
  2. インストール時の注意事項
  3. AlphaWorksの90日ライセンス
  4. JAVA_HOMEをどこに設定するか
  5. WSTKをどこにインストールするか
  6. 通常インストールか、カスタム・インストールか、フル・インストールか
  7. 最終確認

 以上を答えると、インストールが始まる。まずファイルのコピーが行われ、それが終わるとコンフィグレーター(構成プログラム)が起動する。これは、binディレクトリにある「wstkconfig.bat」と同じものなので、あとで起動してやり直すこともできる。

コンフィグレーターによって、次のことが行われる。

  1. 環境変数の設定
  2. Webアプリケーション・サーバーへのプログラムのインストール
  3. WSTKの構成ファイル(wstk.config)の設定
  4. UDDIレジストリ用データベースの初期化

 画面2に、コンフィグレーターの画面を示す。最初に、利用するWebアプリケーション・サーバを選択する。ここではローカルC:\にインストールされているWebSphereを指定することになる。これによって、Apache-SOAPランタイム、管理プログラム、いくつかのサンプルプログラム、UDDIなどがWebアプリケーション・サーバにインストールされる。

画面2 コンフィグレーターでは、WebサーバとしてWebSphereを選択
画面2 コンフィグレーターでは、WebサーバとしてWebSphereを選択

 「Next」ボタンを押すと、次にUDDIの構成が現れる(画面3)。これは「WSTKがどのUDDIを使うのか」という設定である。今回は、ローカルUDDIを使うこととする。

画面3 UDDIとして、プライベートなUDDIを利用する
画面3 UDDIとして、プライベートなUDDIを利用する

 ローカルUDDIを使うのであれば、ローカルUDDI自体を構成する必要がある。「Create Database…」を押して、データベースの作成を行う(画面4)。

画面4 ローカルUDDI用のデータベースを作成
画面4 ローカルUDDI用のデータベースを作成

 ここでは画面の表記がちょっとおかしいので気を付けよう。UDBのユーザーIDを指定すると、そのユーザー名がスキーマ名として使われる。「Database Schema Name」は、DB名となる。「Create」を押すとデータベースが作られる。「Cancel」ボタンを押して前のウィンドウに戻り、「Finish」を押せば準備完了である。

セットアップに成功するためのヒント

 WSTKのセットアップに挑戦する多くの利用者から、「WSTKの利用がうまくいかない」というお嘆きをよく耳にする。そこで、ここではいくつかコツをお教えしよう。

■SOAPやUDDIにアクセスできない
よくありがちなのは、WASの管理サービスが起動していないのと、WSTKによって登録されたアプリケーションが起動していないことだ。これらが起動していないと、うまくアクセスできない。

■UDDIブラウザやSOAPへの登録時に、WSDLが参照できないといわれる
WSTKでは、なにかとURLとして「localhost:8080」が設定される。気を抜いていると、いつの間にかそのまま生成されてしまうことがある。特に、サービスのURL、WSDLの参照URLなどは気を付ける。一度作ってしまうと、UDDI上にそのURLの参照ができてしまい、WSTK-APIを実行したときにエラーが頻発することがあるが、それは無視しても構わない。ローカルでテストするときにこれを回避するには、トンネル・モニターでlocalhost:8080というポートを作ってしまう、という手がある。ホストlocalhostに対してlocalhost:8080のポートを作るには、以下のコマンドでトンネル・モニタを起動しておく。

org.apache.soap.util.net.TcpTunnelGui 8080 localhost 80

■アクセスするURLが分からない
WSTKが稼働するサーバのURLがイマイチ分かりにくいので、一覧表にしておく。

ローカル UDDI http://localhost/services/uddi/servlet/uddi
WSDLのアクセス http://localhsot/wsdl/xxxx.wsdl
SOAPサービス http://localhost/soap/servlet/rpcrouter

 ちなみに、ツールをうまく使えば、ホスト名の部分はかなり自由に設定できる。外からアクセスするときには、当然のことながらlocalhostではなく、固定のホスト名を使う必要がある。

■ClassNotFoundなどが出る
コンパイル時にパッケージが見つからないといわれたり、実行時にNoClassDefFoundExceptionなどが出るのは、クラスパスが足りないからなのはいうまでもないが、WSTKが使うjarファイルは非常に多いので、けっこうやりにくい。JAVA_HOME\lib\extにコピーしてもよいが、何かダーティーなやり方で賛成できない。そこで、筆者は以下のようなバッチファイルを作って利用している。

set java.ext.dirs=%WSTK_HOME%\lib;%WSTK_HOME%\soap\lib; WSTK_HOME%\wstk\lib;%WSTK_HOME%\uddi4j\lib; %WSTK_HOME%\wsdl-toolkit\lib; %JAVA_HOME%\classes;%JAVA_HOME%\jre\ext;
ソースコード 1 環境設定バッチファイル(setenv.bat)
実際には、上記は長い一行なので注意
javac -extdirs %java.ext.dirs% %1
ソースコード 2 コンパイル用バッチファイル(javacomp.bat)
java -Djava.ext.dirs=%java.ext.dirs% %1 %2 %3 %4 %5 %6
ソースコード 3 実行用バッチファイル(runjava.bat)

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る