この記事は、 Java コードと WSDL ドキュメントの両方から、 Web サービスを構築し、そのアプリケーションを Web コンテナーに配備し、対応する Web サービスクライアントアプリケーションを構築するのに必要な、手順を示すことを目的としています。この例では、 Metro- 特有の技術を使用しません。これは広大な Metro のスタックを理解するための出発点として意図的にそうなっています。
ここでサポートするコードサンプルには Metro 環境での JAX-WS アプリケーションをビルドをする手順を示すものが含まれます。この例では、 web サービスを開発するに当たって Java ソースコードを出発点とするものと既存の WSDL ドキュメントを出発点とするものがあります。どちらのシナリオにしても、 web サービスの WSDL ドキュメントからどのように対応するクライアントアプリケーションを開発するかの手順を示します。サンプルコードは次から得ることが出来ます。:
上で述べたように、これらのサンプルでは Metro- 特有の技術を使用しません。しかしながらこのシリーズの次の記事 「 Web サービスアプリケーションで Metro 機能を有効にする」 では 、このドキュメントで示された情報に従ってビルドします。そこでは Metro で利用可能な高度な機能を使用して、 Web サービスと対応するクライアントを構成する手順を説明します。
このサンプルでの Java コードと、このドキュメントで使用される構成ファイルは web コンテナがポート 8080 でリッスンしていることを前提としています。ポート 8080 は GlassFish (domain1) と Tomcat 両方のデフォルトの“ Listen ”ポートです。“ listen ”ポートに変更を加えたとき、それに対応してサンプルソースファイルをエディタで編集する必要があります。次に示すのは“ Listen ”ポートを参照するファイルのリストです。
Web サービスと、そのクライアントをビルドして配備するまえに、 Web コンテナのホームディレクトリを 環境変数もしくは対応する build.xml のプロパティで設定しておかなければなりません。
コマンドラインで実行していることを想定していますが、 Web コンテナのホームディレクトリに適合する環境変数を設定するのは簡単です。GlassFish ならば “ AS_HOME ” に GlassFish インストール時のトップレベルディレクトリを設定します。Tomcat ならば、 “ CATALINA_HOME ” に Tomcat のトップレベルディレクトリを設定します。
新規のターミナルセッションごとに環境変数を設定する代わりに、サンプルのトップレベルディレクトリにある build.xml ファイルを編集する方法も有ります。そこには GlassFish ( as.home) と Tomcat ( catalina.home) に対応する 2 行のコマンドラインがあります。適合する行のコメントを解除して、ディレクトリー名を編集すれだけで済みます。
Web サービスアプリケーションを作成する１つの方法は Java でエンドポイントをコーディングすることです。Java Web サービスを最初から開発するにしても、 Web サービスとして公開したい既存のクラスがあるにしても、ここで説明する手順が最も最短の道です。
web サーヒスは通常の Java クラスとして書かれています。そこでは、クラスとその公開したいメソッドには Web サービスのアノテーションが付加されます。 “ @WebService ”と“ @WebMethod ”です。次にサンプルコードを示します。 :
@WebService
public class AddNumbersImpl {
@WebMethod
public int addNumbers(int a, int b) throws AddNumbersException {
if (a < 0 || b < 0) {
throw new AddNumbersException("Negative number cant be added!",
"Numbers: " + a + ", " + b);
}
return a + b;
}
}
GlassFish を使用しているならば "wsit-jaxws-fromjava" サンプルの中の web サービスは 単に次のように起動するだけで、コンパイル、ビルドされます。 :
ant server
Tomcat を使用しているならば、コマンドラインはこうなります。 :
ant -Duse.tomcat=true server
build.xml 内の server ターゲットは Ant スクリプトが起動されるとアノテーションを処理するツールを起動し、ソースファイルをコンパイルして Java クラスと構成ファイルを関連付け、配備可能な Web アーカイブ (WAR ファイル ) として作成します。WAR ファイルは "build/war/wsit-jaxws-fromjava.war" として作成されます。この手順の過程で Ant に呼ばれたツールについて次に手短に説明します。
AX-WS ツール apt ( アノテーション処理ツール ) はアノテーションが付加されたソースコードを処理しながらコンパイラを起動し、それぞれのソースコードからクラスファイルを作成します。付属の "fromjava" サンプル内の "build.xml" の "ant" ターゲット "build-server-java" は処理手順の中でこの部分を担います。その過程でそれぞれのクラスファイルは Web サービスのサポート構成ファイルと関連付けられてアプリケーション WAR ファイルとなります。これが Web コンテナに配備されるファイルです。このことは次のステップで説明します。"create-war" ターゲットがこの処理を実行します。
通常、意図する Web サービスを作成しようとするとき、 WSDL ファイルからスタートしますが、これは標準の、あるいは既存の Web サービスから定義されます。どちらの場合でも WSDL は既に存在します。 JAX-WS の wsimport ツールはローカルディスクにある、既存の WSDL ドキュメントあるいはネットワークアドレスから得られる WSDL ドキュメントを処理します。ブラウザを使って手動でサービスの WSDL にアクセスするサンプルは「配備の確認」の部分にあります。
以前のサンプルにあったように "wsit-jaxws-fromwsdl" サービスを GlassFish でビルドするには単に次のように起動します。 :
ant server
Otherwise for Tomcat use:
ant -Duse.tomcat=true server
Wsimport は WSDL の "description" に従って、相当する Java インターフェースとその他の補助クラスを生成します。そこでコンパイラが呼ばれて、ユーザーコードと、自動的に生成されたコードをコンパイルします。最後に、クラスファイルは WAR ファイルにバンドルされます。詳細は "wsit-jaxws-fromwsdl build.xml" ファイルの "build-server-wsdl" と "create-war" ターゲットに見ることが出来ます。
便利なことに、それぞれのサンプルの server ターゲットを起動すると Web サービスの WAR ファイルをビルドすると同時に Web コンテナに配備してくれます。しかしながら、場合によってはコンテナから Web サービスを配備を取消したあと、再びビルドすることなしに再配備するのが有効な場合があります。
上記の両方の「 Java から」 と 「 WSDL から」 のシナリオでも結果としてアプリケーションは同じように配備されます。しかしながら配備プロセスを詳細に見ると、 GlassFish と Tomcat web コンテナでは微妙な違いが有ります。
開発目的では GlassFish に備わっている “autodeploy” 機能を使うのが最も単純な方法です。そうするには、アプリケーションの WAR ファイルを配備したいドメインの autodeploy ディレクトリにコピーするだけです。GlassFish のインストールプロセスでデフォルトドメインの domain1 を使っているならば、適正なディレクトリパスは "<glassfish-install-home>/domains/domain1/autodeploy" です。
サンプルに付属の build.xml ファイル は GlassFish へ配備するためのターゲットを持ちます。各々のサンプルのトップレベルディレクトリか、 "fromjava" もしくは"fromwsdl" にある "ant" を実行してターゲットを次のように起動します。
ant deploy
Tomcat にも同じように “autodeploy” 機能があります。この機能は Tomcat の “out of the box” 構成の設定で有効となります。もし、不安なら "<tomcat-install-directory>/conf/server.xml" の “autoDeploy” 設定を見てください。 “autodeploy” 機能を有効とすれば、アプリケーションを "<tomcat-install-home>/webapps" にコピーすれば必要な手順はこれで全てです。重ねて言いますと、 Ant の build.xml ファイルの中にサンプルのを完成させるべきターゲットがあります。配備ターゲットはサンプルのトップレベルディレクトリにある次のコマンドを実行することにより起動することが出来ます。
ant -Duse.tomcat=true deploy
アプリケーションが正しく配備されたかどうかを確認する１つの基本的なテストは Web ブラウザを使用して、ホスティングしている Web コンテナからアプリケーションの WSDL を取り出すことです。次の URL で２つのサンプルの各々から WSDL を取り出すことが出来ます。Web ブラウザを使用していて、 Web コンテナが異なるマシーンで動作しているときは “localhost” を Web サービスをホスティングしているマシーンネームに置き換えてください。この時点で、 Web コンテナが実際に稼動していることを確認することが肝要です。
もし、ブラウザがページいっぱいに XML を表示すれば、事はうまく行っています。そうでなければ、 Web コンテナのログの、今配備したばかりのサンプル WAR に関連するエラーメッセージをを調べてください。 GlassFish ならば対応するログは "<glassfish-install-directory>/domains/<your-domain>/logs/server.log" で見つけることが出来ます。 Tomcat ならば、対応するログは "<tomcat-install-directory>/logs/catalina.out" で見つけることが出来ます。
Web サービスプロバイダを開発するのとは異なって、 Web サービスクライアントアプリケーションを作成するには常に既存のWSDLドキュメントからスタートします。このプロセスは既存の WSDL から Web サービスを作成するステップと似ています。通常、 WSDL は "wsimport" ツールを使うことにより、 Web サービスプロバイダから直接取り出すことことが出来ます。 "Wsimport" はそのときインターフェースに書かれている内容に沿った Java ソースコードを生成します。そのとき "Javac" すなわち Java コンパイラが呼ばれ、ソースコードをクラスファイルにコンパイルします。プログラマのコードは Web サービスにアクセスするに当たって、この自動生成されたクラスを利用します。ここにあるのはその抜粋です。Here is an example code snippet:
AddNumbersPortType port = new AddNumbersService().getAddNumbersPort(); int a = 10; int b = 20; int result = port.addNumbers(a,b);
関連する両方のサンプル共に、次のように起動します。
ant client
もしくは
ant -Duse.tomcat=true client
すると "wsimport" が実行されてサービスの WSDL を取り出し、ソースコードをコンパイルします。
両方のサンプル共に、つぎのように残りのコマンドラインを実行します。
ant run
もしくは
ant -Duse.tomcat=true
ターゲットは単に "java fromwsdl.client.AddNumbersClient" のように "java 「クライアントのクラス名」 " を実行します。便宜のためにターゲットの実行 で Java の -classpath オプションを渡して、 jar ファイルのリストを渡す仕事もしています。ターゲット実行で、クライアントから次に見るような出力が見られます。 :
[java] May 4, 2006 2:45:50 PM [com.sun.xml.ws.policy.jaxws.PolicyWSDLParserExten
sion] addClientConfigToMap
[java] WARNING: Optional client configuration file URL is missing. No client con
figuration is processed.
[java] Invoking addNumbers(10, 20)
[java] The result of adding 10 and 20 is 30.
[java] Invoking addNumbers(-10, 20)
[java] Caught AddNumbersFault_Exception: Numbers: -10, 20
上の WARNING 行は両方のサンプル共に現れます。 Metro 技術が有効になっていないときには構成ファイルは不要です。 Metro 構成ファイルについては次の記事で詳細を説明します。
Web コンテナからの Web サービスの配備取り消しはサービスの無効化と Web コンテナからの削除を意味します。ユーザによる明示的な再配備なしにはクライアントの Web サービスの使用はおろか Web サービス自体を再起動できないでしょう。開発プロセスにおいては、「 Web サービスの配備の取り消し」は有効な場合が多いでしょう。この章では GlassFish と Tomcat 両方に必要なステップを説明します。
"asadmin" コマンドに GlassFish から Web サービス配備の取り消しをする簡単なメソッドがあります。
asadmin undeploy --user admin wsit-jaxws-fromjava asadmin undeploy --user admin wsit-jaxws-fromwsdl
Tomcat から Web サービスの配備を取り消すには、 Tomcat の "webapps" ディレクトリからその WAR ファイルを削除する必要があります。典型的な UNIX シナリオでは次のようなコマンドでサンプルの WAR ファイルを削除できます。すると Tomcat は数秒のうちに自動的に Web サービスを取り消します。
rm $CATALINA_HOME/webapps/wsit-jaxws-fromjava.war rm $CATALINA_HOME/webapps/wsit-jaxws-fromwsdl.war