レベル: 上級 James McCarthy (jmccarthy@symmetrysolutions.com), President and CTO, Symmetry Solutions, Inc.
2006年 7月 28日 複数コンテナーでの Java™ Web サービスのデプロイメントは、開発者に問題を提起するはずです。Javaコミュニティーがどのようにこの問題を対処し始めているかについて学ぶとともに、いくつかのデプロイメント記述子の実装についても学びます。
はじめに
Web サービスは過去数年で数多くの変化を経験しています。これは、W3C (WorldWide Web Consortium) が Web サービスの中核となる仕様を更新し、また、初期の欠点に対処した新しい仕様を導入したことによります。W3Cの Web Services Activity グループが維持管理するこれらの仕様は XML 仕様一式として、ベンダー中立の立場でWeb サービスを扱っています。W3C のこの中核を担う Web サービス仕様は、この記事の｢参考文献」セクションに記載しています。
同時に JCP (Java™ Community Process) は、W3C の推奨事項を Java 言語に統合するための独自の仕様一式を維持管理しています。XML対応 Java API (JAX-RPC、JAXB、JAXP、JAXR、および SAAJ) は、Web サービス仕様をJava 言語にインプリメントする一連のインターフェースです。JWSDP (Java WebServices Developer Pack) コンポーネントの概要については、記事「Get ahead with Java Web Services」(developerWorks、2002年) を参照してください。
W3C が維持管理する現在の Web サービス仕様と JCP が維持管理する Java Webサービス API は、プラットフォームと言語間の非依存性を確実にするために「通信を利用した」Web サービスに取り組んでいます。開発者が XML 仕様に準拠するか、または JavaAPI を使用すれば、言語、プラットフォーム、そして通信プロトコルの違いに関わらず、アプリケーションがWeb サービスと確実に通信できるでしょう。Web サービスはすべてのアプリケーションの範囲を拡大するものであり、今日のWeb ベースのアプリケーションに対応した統合技術として努力に値するものであることはすでに明らかになっています。
一方、複数の Web アプリケーション・コンテナーに Web ベースのアプリケーションをデプロイしなければならない場合、通信を介した互換性が十分ではありません。これらのコンテナーを3 つ挙げるとすると、IBM® WebSphere® Application Server、BEA WebLogic、そしてTomcat です。Java Web サービスの場合、複数の Web アプリケーション・コンテナー・インプリメンテーションにまたがるWeb サービスの標準デプロイメント用の「web.xml」はありません。
複数の Web アプリケーション・コンテナーによる Web サービス・インプリメンテーションをアプリケーションにサポートさせるとなると、JavaWeb サービス・アプリケーションのデプロイは難題です。方法としては、ApacheWeb サービス・プロジェクトの Axis など、単一の Web サービス・インプリメンテーションをWeb アプリケーションで使用することが考えられます。Web サービス・クライアントの場合、クライアント・コードはWeb サービス・デプロイメント記述子に依存しないため、通常このストラテジーは複数のWeb コンテナーでうまくいきます。Web サービス・プロバイダー (サーバー) として、Webサービス・インプリメンテーションを Web アプリケーション・アーカイブ (war)ファイルに組み込むと、予期しないクラス・ローダー・コンフリクトが発生する原因となるため、ベンダーのWeb サービス・インプリメンテーションを使用することが最も望ましいデプロイメント・オプションとなります。
この記事ではこれから、Java Web サービスのデプロイメントの問題を検討し、さまざまなデプロイメント記述子のインプリメンテーションを紹介するとともに、Javaコミュニティーがどのようにこの問題に対処し始めているかを説明します。
複数のコンテナーにデプロイする 1 つの Web サービスを開発する
 |
オープン・ツールセット
この記事では、以下のツールを使用してサンプルを作成しています。
-
Eclipse IDE -- Eclipse は、Java コミュニティーで急速に標準化が進んでいる開発プラットフォームです。Eclipseのプラグイン・アーキテクチャーにより、拡張可能な IDE には理想的なプラットフォームとなっています。
-
Ant ビルド・ツール -- Ant と Maven は、Java 開発コミュニティーにおける 2 つの主要なビルド・ツールです。どちらのツールも非常に強力で、両方一を緒に使用することもできます。この記事では、完全なAnt ビルド・ファイルを記載していますが、説明するのは例に関連する特定のタスクについてのみです。Antは Eclipse に統合されていますが、標準 Ant タスクの説明が必要な場合や、独自のAnt タスクを作成 (非常に簡単です) する場合は、この資料が役に立ちます。
-
WTP (Eclipse Web Tools Platform) -- これは Eclipse IDE のアドオンで、Web ベース・アプリケーションのビルドとデプロイメントに役立つ多数のツールを提供します。複雑なWSDL ファイルをごく単純化して理解できるようにする、優れた XML、スキーマ、そしてWSDL エディターが備わっています。
|
|
Web アプリケーション・デプロイメントの段階では、オプションをオープンにしておきたいものです。WebSphereや WebLogic などの商用 J2EE インプリメンテーションに投資しているクライアントは、そのプラットフォームの利点を生かしたいと思うでしょう。一方、導入コストを抑えたいというクライアントにとっては、JBossやApache Tomcat などのオープン・ソース・ソリューションを利用するほうを選ぶかもしれません。いずれの場合も、開発努力をできるだけ再利用できるようにするには、ベンダー固有のIDE が使用できるとしてもこれには依存できないはずです。J2EE アプリケーション・ベンダーが提供するIDE を使って開発を行うと、Java Web サービスでは柔軟性が制限され、Web サービス・デプロイメントの詳細の多くが隠されてしまうことになります。
この記事に記載する例では、オープン・ソース・コミュニティーで無料で入手できる開発ツールの標準セットを使って、ターゲットWeb アプリケーション・コンテナーそれぞれの Web サービス・デプロイメント記述子をビルドします。これらのツールはすべて、開発者が頻繁に使用するもので、オープン標準技術をサポートします。ツールの説明については、補足記事「オープン・ツールセット」を参照してください。
目標は、Axis を使ってターゲット Web アプリケーション・コンテナーの WebSphere、WebLogic、JBoss、およびTomcat にデプロイ可能な Web サービスを作成できる単一のプロジェクトを作成することです。warファイルは、最小限の変更、そして一切のソース・コードの再コンパイルなしでターゲットWeb アプリケーション・コンテナーにデプロイ可能でなければなりません。
この記事は、Web サービスや Web サービス・デプロイメントのチュートリアルとしてではなく、JavaWeb サービスでの問題と、将来その問題をどのように対処できるようになるかを説明することを目的としています。使用するWeb アプリケーション・コンテナーが 1 つだけで、Web アプリケーション・コンテナーを変更する予定がない場合は、Webサービス・メタデータ (JSR-181) に関するセクションに進んでください。このJSR は、今後の開発努力に影響する可能性があります。
Web サービスの説明
ここでのデプロイメントの例に関する十分な情報を提供するため、インターフェースにマッピング・ファイルが必要なWeb サービスを作成しました。従来の Hello World や Stock Ticker などの Webサービスでは、ここで取り上げる Web サービス・デプロイメントの要件を説明するには情報が足りないためです。
Web サービス・エンドポイントには、デプロイメント中に必要となる各種ファイルを説明するために使うことができる複数のメソッドを持たせます。このWeb サービスの例は、リモート・アプリケーションのパフォーマンスに関する情報を戻します。もちろん、このインプリメンテーションの例は実際の情報を戻しません。これは、より複雑なWeb サービス・インターフェースの要件を示すための単純な例です。以下は、Webサービス・エンドポイントを作成するために使用したインターフェース・ファイルです。
リスト 1. Web サービス・エンドポイント・インターフェース
public interface StatsService extends java.rmi.Remote {
public StatsContainer[] getAllStatistics() throws java.rmi.RemoteException;
public StatsContainer[] getStatistics(String category) throws java.rmi.RemoteException;
public void resetAllStatistics() throws java.rmi.RemoteException;
public void resetStatistics(String category) throws java.rmi.RemoteException;
public void clearStatistics() throws java.rmi.RemoteException;
public String[] getCategories() throws java.rmi.RemoteException;
}
|
このインターフェースには、マッピングが必要な 2 つの戻りの型があります。1つは StatsContainer オブジェクトの配列で、もう 1 つはストリング・オブジェクトの配列です。StatsContainerは単純なコンテナー・オブジェクトで、これには複数の基本型と 2 つのストリングがあります。私たちの目標は、まずこのインターフェースとインプリメンテーション・ファイルから、「オープン・ツールキット」に記載しているツールを使用して必要なデプロイメント記述子を作成し、ターゲット・プラットフォームにWeb サービスをデプロイすることです。この過程で必要な各ステップ、そして該当する場合には作成されたファイルについて説明していきましょう。
ビルド・プロセスの説明
この Web サービスのビルド・プロセスでは、各種の自動化ツールを利用します。これらのツールは、Javaイントロスペクションによって Web サービス成果物をビルドできる Web サービス・インプリメンテーションによって提供されます。デプロイメント記述子は2 つのグループに分かれるため (J2EE 1.4 をサポートする記述子とカスタム Webサービス・デプロイメント記述子)、デプロイメントには 2 つのビルド・ツールを利用します。
J2EE 1.4 Web サービス
標準 J2EE 1.4 Web サービスに必要な成果物をビルドするため、Java Web ServiceDevelopers Pack (JWSDP v1.5) で提供される wscompile コマンドを使いました。wscompileコマンドで、Web サービス記述言語 (WSDL) ファイル、Web サービス・マッピング・ファイル、そして呼び出し側アプリケーションに対してWeb サービスを整列させるためのインプリメンテーション・ファイルを作成しました。
wscompile コマンドを実行するには、まず、wscompile に実行させるアクションを記述するXML 構成ファイルを作成する必要があります。この例では、サービス・エンドポイントを処理させ、インプリメンテーションに必要なXML 成果物とシリアライゼーション・コードを作成させています。以下に、wscompileコマンドに必要な構成ファイルの例を示します。
リスト 2. 構成ファイルの例
<?xml version="1.0" encoding="UTF-8"?>
<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
<service name="StatsWS"
targetNamespace="http://services.symmetrysolutions.com/stats"
typeNamespace="http://types.symmetrysolutions.com/stats"
packageName="com.symmetrysolutions.statsws">
<interface name="com.symmetrysolutions.statsws.StatsService"
servantName="com.symmetrysolutions.statsws.StatsServiceImpl"/>
</service>
</configuration>
|
上記の構成ファイルでは、サービス要素を使って Web サービスを記述しています。この要素は、wscompileコマンドに対して、インターフェースに関連付けられた名前空間とそのインターフェースに関連する型を指定します。名前空間の他にも、このサービス要素がwscompile コマンドに対して指定するものとして、生成されるソース・コードに使用するパッケージ名、イントロスペクションを行う対象インターフェースの名前があります。
自動化ツールの実行は、J2EE 1.4 準拠の Web サービスをデプロイする際の最終ステップではありません。最終ステップは、ご使用のWeb アプリケーション・コンテナーによって異なりますが、いずれの場合も、最後に組み込む必要があるWeb サービス・デプロイメント成果物は webservices.xml ファイルです。このファイルは、J2EE1.4 アプリケーション・コンテナーに、Web サービス記述の場所、そして Webサービスに使用するインターフェースと実装クラスを指定します。
Axis Web サービス
Aixs には固有のデプロイメント記述子があるため、Axis Web サービスのビルド・プロセスはJ2EE 1.4 Web サービスの場合とは異なります。Axis Web サービスには、実行時にdeploy.wsdd ファイルが提供する情報が必要です。このファイルは、サービス・エンドポイントの名前、そしてその名前をWeb サービスとして公開する方法を指定します。deploy.wsdd ファイルは Axisサーバーに送られ、Axis サーバーはこの情報を Web サービスのイントロスペクションに使って、Webサービス・ランタイムに必要な情報を作成します。注: このプロセスは J2EE 1.4準拠 (デプロイメント成果物) ではなく SOAP 1.1 準拠であるため、Axis Webサービスはどの Web サービス・クライアントとも相互運用可能になります。
Axis Web サービス・デプロイメント記述子は手動でビルドすることも、あるいはWeb サービスの WSDL を処理する Axis WSDL2Java Ant タスクを使用してビルドすることもできます。この例では、Webサービス・エンドポイントのインターフェースから開始したため WSDL ファイルはありませんが、幸いAxis にはインターフェースを処理して WSDL ファイルを出力する Ant タスクもあります。その結果、Axisビルド・プロセスは次の 2 つのステップとなります。
- Java2WSDL タスクを使って、インターフェースから WSDL ファイルを作成します。
- WSDL から Web サービス・スケルトン (この例では使いません) とデプロイメント記述子(この例で使います) を作成します。
Axis Web サービスがビルドされたら、次に Web アプリケーション・コンテナーにデプロイするサービスとそのデプロイ方法を指定して、このサービスをデプロイする必要があります。これは、deploy.wsddファイルを、Web サービスをデプロイする Axis アドミニストレーター・タスクに渡すことによって行います。つまり、AxisWeb サービスには、Web コンテナーの起動後に Web サービスをデプロイするステップが必要になります。詳しくは、「Tomcat での Axis デプロイメントの場合」のセクションを参照してください。
デプロイメント・プロセスの説明
必要な Web サービス・デプロイメント記述子がすべて作成されたら、最終ステップとして、各ターゲット・プラットフォームにアプリケーションをデプロイします。Webサービスをデプロイするために必要な最終ステップを、ターゲット Web アプリケーション・プラットフォームごとに説明していきましょう。
IBM WebSphere および JBoss 4.0.4
IBM WebSphere と JBoss 4.0 はどちらも J2EE 1.4 準拠なので、Java Web ServicesDeveloper Pack (JWSDP v1.5)、または JAX-RPC Web サービス成果物を生成する同様のツールを使用できます。デプロイメント用に生成されない唯一のWeb サービス成果物は webservices.xml ファイルで、これはこれらのコンポーネントすべてをまとめる方法を記述します。
JBoss 4.0.4 でのデプロイメントの場合
Web サービスを JBoss にデプロイするには、以下のステップに従います。(ここではJBoss 4.0.4 を使用しています。これより前のバージョンでは、配列型のデプロイメントに関する問題があるためです。)
- 以下のように、J2EE 1.4 Web サービス･デプロイメントを記述する webservices.xmlファイルを作成します。
リスト 3. webservices.xml ファイルの例
<?xml version="1.0" encoding="UTF-8"?>
<webservices xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://www.ibm.com/webservices/xsd/j2ee_web_services_1_1.xsd"
version="1.1">
<webservice-description>
<webservice-description-name>StatsWS</webservice-description-name>
<wsdl-file>WEB-INF/wsdl/StatsWS.wsdl</wsdl-file>
<jaxrpc-mapping-file>WEB-INF/mapping.xml</jaxrpc-mapping-file>
<port-component>
<port-component-name>StatsWS</port-component-name>
<wsdl-port>StatsServicePort</wsdl-port>
<service-endpoint-interface>
com.symmetrysolutions.statsws.StatsService
</service-endpoint-interface>
<service-impl-bean>
<!?This servlet is declared in our web.xml file -->
<servlet-link>StatsWS</servlet-link>
</service-impl-bean>
</port-component>
</webservice-description>
</webservices>
|
- 以下のように、web.xml ファイルが Web サービス・エンドポイントをサーブレットとして宣言するように変更します。ここで<servlet-link>StatsWS</servlet-link> が実装クラスにバインドされていることに注意してください。web.xmlファイル内でインプリメンテーションをサーブレットにバインドする宣言は、以下のとおりです。
リスト 4. web.xml 内の Web サービス・サーブレット参照
<!-- This name is declared in the webservices.xml file -->
<servlet>
<servlet-name>StatsWS</servlet-name>
<servlet-class>
com.symmetrysolutions.statsws.StatsServiceImpl
</servlet-class>
</servlet>
|
- Web アプリケーション・アーカイブ (war) をビルドしてパッケージ化し、Webアプリケーションをデプロイします。
IBM WebSphere でのデプロイメントの場合
IBM WebSphere Web サービスのビルド・プロセスは J2EE 1.47 Web サービスの場合と同様で、唯一異なる点は、WebSphere固有のツールを使って、必要なデプロイメント記述子 (J2EE 1.4 標準 + WebSphere固有のデプロイメント記述子) を生成することです。WebSphere Web サービス・デプロイメント記述子は手動でビルドすることも、あるいはWeb サービスの WSDL を処理する WSDL2Java タスクを使ってビルドすることもできます。この例では、Webサービス・エンドポイントのインターフェースから開始したため、WSDL ファイルはありません。その結果、WebSphereビルド・プロセスは次の 2 つのステップとなります。
- Java2WSDL タスクを使って、インターフェースから WSDL ファイルを作成します。
- WSDL から Web サービス・デプロイメント記述子を作成します。
上記のタスクを使って WebSphere Web サービスをビルドしたら、生成されたすべての成果物(シリアライゼーション・クラスとデプロイメント記述子) を war ファイルにパッケージ化して、WebSphereサーバーにデプロイできるようにする必要があります。
Tomcat での Axis デプロイメントの場合
Axis Web サービスのデプロイメントには、Axis 固有のコマンドを Web コンテナー内で実行して、Axisエンジンに Web サービスをデプロイするよう指示する必要があります。これは、Webサービス・デプロイメントの手動ステップによって再起動が行われる実働アプリケーションでは困難な場合があります。この問題に対処するには、Webアプリケーションによって公開された Web サービスのすべてのデプロイメント・コマンドを実行し、その結果生成されるservice-config.wsdd ファイルを war ファイルに組み込むという方法をとれます。この方法により、Axisエンジンが (web.xml ファイルの構成設定から) 起動すると、service-config.wsddファイルを検出して自動的に Web サービスを再デプロイします。
Axis Web サービスをデプロイするには、以下のステップが必要になります。
- リスト 5 に示すように、web.xml ファイルを変更して、Axis エンジンの宣言(サーブレット宣言) を組み込みます。
- WSDL から Web サービス・デプロイメント記述子を作成します。
リスト 5. web.xml 内の Axis エンジン・サーブレット宣言
<!-- AXIS servlet definition -->
<listener>
<listener-class>
org.apache.axis.transport.http.AxisHTTPSessionListener
</listener-class>
</listener>
<!-- Axis servlet declaration -->
<servlet>
<servlet-name>AxisServlet</servlet-name>
<display-name>Apache-Axis servlet</display-name>
<servlet-class>org.apache.axis.transport.http.AxisServlet</servlet-class>
</servlet>
<!-- Servlet mappings -->
<!-- AXIS Definitions -->
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/servlet/AxisServlet</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>*.jws</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet-mapping> |
- Web アプリケーションをパッケージ化してデプロイする。
- Axis AdminService を実行して、Web サービス用に生成されたデプロイメント記述子をデプロイします。生成された構成ファイルがwar ファイルに組み込まれていない場合は、サーバーが起動するたびに、このステップを実行する必要があります。
- オプションで、service-config.wsdd を war ファイルに再パッケージ化して、今後のデプロイメントに使用できるようにします。これにより、Axisエンジンが起動するごとに前のステップを繰り返す必要がなくなりますが、Axisエンジンのバージョンがパッケージ化とデプロイメントとで異なる場合は機能しない可能性があります。Axisエンジンが変更された場合には新しい service-config.wsdd デプロイメント記述子を生成できるようにするため、これはデプロイメントの際にだけ行ってください。
BEA WebLogic
BEA WebLogic 商用 Web サービス・コンテナーでは、バージョン 8.1 以前のカスタム・デプロイメント記述子が使われます。また、標準JAX-RPC 記述子も使われます。これは、JSR-181 準拠のアノテーションを使って生成できます。BEAでは、JSR-181 を Java コミュニティー・プロセスに導入しています。WebLogic9.x 開発者ガイドによると、WebLogic プラットフォームに推奨されるデプロイメント・プロセスは、WebServices Meta-Data (以下に説明する JSR-181) を使って Web サービスをインプリメトするJava ファイルをマークアップし、JDK 5.0 (アノテーションのサポートに必要)でアノテーション付きファイルをコンパイルし、WebLogic JSR-181 プロセッサーで生成されたクラス・ファイルを処理することです。これによって、J2EE1.4 仕様に適合する残りの Web サービス成果物が作成されます。WebLogic には、最後の操作を実行するためのjwsc という Ant タスクがあります。jwsc タスクが実行されると、Web サービス・デプロイメント記述子をデプロイメント用のwar ファイルにパッケージ化することが可能になります。
Web サービスの開発とデプロイメントを単純化する JSR-181
今までの説明のポイントには、以下の 2 つの要素がありました。
- 複数の Web アプリケーション・コンテナーに Web サービスをデプロイするために必要なステップを説明する。
- Web サービスを Java プラットフォームでデプロイする際に開発者が直面する難問を説明する。
ここからは、後者の目的に絞って、Web サービス・デプロイメントを単純化する上でのJSR-181 の利点を説明します。
JSR-181 は、Java プラットフォームを使った Web サービスの開発とデプロイメントを単純化する方法として、BEASystems, Inc. によって Java コミュニティー・プロセス (JCP) に導入されました。JSR-181に記載された仕様は、Web サービス・インプリメンテーションを記述する Webサービス・メタデータにアノテーションを付ける上で、J2SE 5.0 の機能に依存しています。ソース・コードで少数の単純なWeb サービスアノテーションを使うことによって、開発要件を追加することなく、Webコンテナーが Web サービスを公開できるようになります。
仕様に記載されている JSR-181 の適用範囲は以下のとおりです。
- Web サービス・アプリケーションをプログラミングするためのアノテーション付きJava 構文を定義する
- 開発を容易にして迅速化させる Web サービス開発の単純なモデルを提供する
- ツールによる操作に従った構文を提供する
- 汎用 API およびデプロイメント記述子の知識とインプリメンテーションを必要としないWeb サービスのビルドとデプロイメントのための標準を定義する
この仕様の全体的な目標は、Java Web サービスを単純化し、最も一般的な Webサービス機能を簡単にデプロイできるようにすることです。この仕様では、Webサービスをデプロイするために Web コンテナーが実行しなければならないアクションを定義してはいません。定義しているのは、結果となるWSDL (Web サービス契約) が Web コンテナー全体で一貫しており、開発者が意図するとおりであるということだけです。
JSR-181 プログラミング・モデル
JSR-181 によって導入されるプログラミング・モデルは J2EE 1.4 サーバー・モデルとJAX-RPC に基づくモデルで、開発者が維持管理しなければならない Web サービス成果物の数が抑えられています。サービス・インプリメンテーションをどこから開始するかによって、JSR-181では、Java Web サービスをインプリメントするために維持管理する必要がある成果物の数を大幅に減らすことができます。仕様には、Webサービスの開発を開始する複数の方法、そして Web サービスアノテーション機能がどのように開発努力を支援できるかが記載されています。以下に、Webサービスの開始プログラミング・モデルについて説明します。
Start with Java (Java からの開始)
Start with Java はおそらく Java Web サービスのオリジネーターにとって最も一般的な方法でしょう。またこれは、仕様が必要とする唯一のプログラミング・モデルです。このプログラミング・モデルでは、開発者が実装クラスを作成して目的のWeb サービス機能にアノテーションを付けることができます。残りの Web サービス成果物(WSDL、スキーマ、およびデプロイメント記述子) は、JSR-181 プロセッサーがアノテーション付きJava クラスから自動的に生成します。デフォルトでの WSDL 生成は、JAX-RPC1.1 で定義された Java と XML/WSDL 間のマッピングに従っていますが、開発者はWeb サービスアノテーションを使って WSDL をカスタマイズできます。
Start with WSDL (WSDL からの開始)
Start with WSDL プログラミング・モデルは、WSDL 内に定義されたスキーマ定義とメッセージ・パートを表すクラスとともにサービス・エンドポイント・インターフェースを生成するために使われます。このモデルでは、JSR-181アノテーションはインプリメンテーション・ファイル内でのみ使用されます。このファイルは、WSDLサービス契約から省略された詳細 (バインディングやサービス・ロケーション情報など)を定義するために開発者が作成する必要があります。
Start with WSDL and Java (WSDL および Java からの開始)
Start with WSDL and Java プログラミング・モデルは、インプリメンテーションをWSDL で定義されたインターフェース契約にマッピングするために使われます。このプログラミング・モデルを使うと、インプリメンテーション・ファイル内で記述されているアノテーションがWSDL 内に定義されている契約と一致しない場合、JSR-181 プロセッサーがフィードバックを提供します。
JSR-181 プロセッサー
JSR-181 仕様は、Web サービス・コンテナー内での JSR-181 プロセッサーのインプリメンテーション詳細に対して非常にオープンです。唯一の要件は、プロセッサーが実行可能なWeb サービスを作成するということだけです。この開放性による正味の効果は、JSRのインプリメンテーションが市場に登場し始めても依然として明らかです。開発者にとっては、Startfrom Java プログラミング・モデルをインプリメントする数種類のプロセッサーが期待できます。例えば、J2EE1.4 互換 Web サービス成果物を作成するプリプロセッサーという単純なモデルが考えられます。この場合、プリプロセッサーは構成ファイルとwebservices.xml デプロイメント・ファイルを作成し、Java2WSDL コンパイル・ステップを呼び出すことになるでしょう。別のインプリメンテーションでは、実行時にアノテーションが処理され、Webアプリケーション内に含まれるコンパイル済みクラスから直接 Web サービスを公開する、ドラッグ・アンド・ドロップのWeb サービス・デプロイメントが行われることも考えられます。
JSR-181 での Web サービスアノテーション
前述の Web サービスの例を引き続きビルドする場合、J2EE 1.4 Web サービス成果物の作成を支援するJSR-181 アノテーションを使ってインプリメントすることが可能です。JSR-181プロセッサーを使うことによって、この例には開発時にデプロイメント成果物を含める必要がなくなり、インプリメンテーション・ファイルのアノテーションから実行可能なWeb サービスを作成することができます。以下に、JSR-1881 によって提供されるアノテーションをいくつか概説します。Webサービスアノテーションの詳しい説明については、｢参考文献」のセクションに記載されていてる仕様を参照してください。
リスト 6. WebService アノテーション
@WebService(
name = "StatsWS",
targetNamespace = "http://services.symmetrysolutions.com/statsws",
serviceName = "StatsWS"
)
|
WebService アノテーション (必須) は、Java ファイル内のクラス宣言またはインターフェース宣言の前にあります。WebServiceアノテーションがクラス宣言の前にある場合、そのクラスは Web サービスのインプリメンテーション時にマークされ、WebMethodアノテーションで明示的に宣言されるか、あるいは endpointInterface が宣言されない限り、すべてのpublic メソッドが Web サービス・インターフェースの一部となります。WebServiceアノテーションがインターフェース宣言の前にある場合は、そのインターフェースはWeb サービス・インターフェースとして識別され、インターフェース内の WebMethodアノテーションに関わらず、インターフェースに含まれるすべてのメソッドがWeb サービス・エンドポイントの一部であるとみなされます。
リスト 7. SOAPBinding アノテーション
@SOAPBinding(style = SOAPBinding.Style.RPC,
use = SOAPBinding.Use.ENCODED) |
SOAPBinding アノテーション (オプション) は、Java ファイル内のクラス宣言またはインターフェース宣言の前にあります。SOAPBindingアノテーションを使うと、開発者が Web サービスの SOAP メッセージ・プロトコルへのマッピングを制御することが可能になります。
リスト 8. WebMethod アノテーション
@WebMethod(operationName = "getAllStatistics") |
WebMethod アノテーション (オプション) はメソッド・レベルで宣言され、Webサービス操作として公開されるメソッドをカスタマイズするために使われます。このアノテーションを実装クラス内で使うと、開発者はWeb サービスとして公開するメソッド、操作に関連付けられた名前、そして SOAPActionバインディングを制限できます。インターフェース・ファイルで使用する場合は、操作に関連付けられた名前とSOAPAction バインディングのみを制御できます。
リスト 9. WebParam アノテーション
@WebParam(name = "category", mode="IN") |
WebParam アノテーション (オプション) はメソッド内で宣言され、Web サービス操作内のパラメーターをカスタマイズするために使用されます。WebParamは一般的に RPC スタイルのバンディングで使用されますが、DOCUMENT スタイルのバインディングでも、パラメーターを要素名と名前空間に関連付けるために使用できます。
リスト 10. WebResult アノテーション
@WebResult(name = "categoryList") |
WebResult アノテーション (オプション) はメソッド・レベルで宣言され、Webサービス操作の戻り値をカスタマイズするために使われます。
上記のリストから分かるように、JSR-181 プロセッサーを使って Web サービスをデプロイすると、Javaベースの Web サービスの開発およびデプロイメント作業を大幅に減らすことができます。このアノテーションのリストは完全なものではありませんが、標準的なデプロイメントで使われる可能性が高い、最も一般的なアノテーションの例を示しています。Webサービスアノテーションのすべての機能を完全に理解するには、JSR-181 仕様全体を読むことをお奨めします。
Web サービスアノテーションを使用する
JSR-181 をサポートする Web アプリケーション・コンテナーを探してみると、その数が非常に少ないことが分かるでしょう。この記事を作成した時点で、JSR-181、JBoss4.0.4、BEA WebLogic 9.x、そして JSR-181 参照インプリメンテーションをサポートする製品はほんのわずかしかありません。アノテーション付きJava Web サービスをテストに書き込むには、以下のステップを提案します。
- J2SE 1.5 (5.0) がインストールされていて、デフォルトの Java コンパイラーになっていることを確認します。アノテーションをコンパイルしてみれば、デフォルトJava コンパイラーであるかどうかがすぐに分かります。
- JSR-181 のインプリメンテーションをダウンロードします。私が選択したのはJBoss 4.0.4 です。これは、完全な JAX-RPC サポートを備えた数少ない JSR-181のオープン・ソース・インプリメンテーションだからです。
- JBoss 4.0.4 をインストールし、EJB3 オプションが選択されていることを確認します(このステップは必要ない場合があります)。この記事が掲載される頃には、JBoss4.0.4 の GA バージョン以上が使用可能になるはずです。そうでなければ、JSR-181アノテーションの完全なサポートを備えた GA バージョンの JBossWS をダウンロードしてインストールしてください。
- Web サービスのインプリメンテーション、またはインプリメンテーションとインターフェースの両方にアノテーションを追加します。
- Web アプリケーションをコンパイルして、パッケージ化します。
- war ファイルを JBoss のデプロイ・ディレクトリーにドラッグ・アンド・ドロップし、開始します。これで、JBossWSJSR-181 プロセッサーによって Web サービスがデプロイされます。
上記のステップから分かるように、JSR-181 プロセッサーが Web コンテナー内にインプリメントされていれば、JavaWeb サービスのデプロイメントはドラッグ・アンド・ドロップ操作と同じく単純になります。
前述したように、JSR-181 仕様には、Web コンテナー内で実行するプロセッサーに関する要件はありません。唯一の要件は、JSR-181プロセッサーが完了すると、一貫した WSDL 契約を持つデプロイメント可能なWeb サービスが完成するということです。この要件は、おそらく何通りかの方法でインプリメントされることでしょう。例えば、JBoss4.0.4 サーバーで説明したように、ドラッグ・アンド・ドロップのデプロイメントをサポートするという方法です。この方法は、開発者が使用できるデプロイメント記述子の成果物を作成しませんが、最も簡単なデプロイメントとなります。デプロイメント記述子のカスタマイズが必要な場合には、この方法ではうまくいかない可能性があります。そのような場合は、前述した標準J2EE1.4 デプロイメントに戻ることが最善の方法です。
あるいは、統合開発環境 (IDE) や、ビルド・プロセス中に実行可能な Ant タスクのアドオン・コンポーネントとしてのデプロイメント方法もあります。(上記のBEA WebLogic のデプロイメントについての説明を参照してください。)プロセッサーのアドオンは、製品がwar ファイルとしてパッケージ化される直前に実行され、アノテーションに基づいてサーバー固有のWeb サービス用デプロイメント記述子を作成します。Apache Beehive プロジェクトでは、そのようなコンポーネントを作成しているようなので、JSR-181の汎用インプリメンテーションが提供される日が近いうちにやってくるかもしれません。(｢参考文献」セクションに記載した Apache Beehive を参照してください。)このインプリメンテーション方法を使うと、プロセッサーによって、開発者が後でカスタマイズできるデプロイメント記述子が作成されることになります。
Web Services Meta-Data (JSR-181) が、Java Web サービスのビルドとデプロイメントを現在に比べてはるかに簡単にすることは明らかです。これによって、開発者が多種多様なデプロイメント記述子を学ぶ必要はなくなり、デプロイメントの際にWeb アプリケーションを変更する必要もなくなることでしょう。Web サービスアノテーションは、Java言語を進化させ、アプリケーション・アーキテクトとアプリケーション・デプロイメントとの間に重要なつながりをもたせる方法の1 つです。アーキテクトにはインターフェースの意図を記述する能力があり、ランタイム・プラットフォームには、その意図をデプロイ可能なソリューションに変換する能力があります。
参考文献 学ぶために
製品や技術を入手するために
著者について | | | McCarthy は Symmetry Solutions の最高技術責任者で、企業の技術的方向を定義し、すべてのプロジェクト管理と開発を監視しています。Symmetry Solutions は、民間企業とアメリカ政府の両方を対象とした、XML およびサービス指向アーキテクチャー・ソリューションを専門とするシステム・インテグレーターです。McCarthy は 20 年以上にわたるソフトウェア開発の経歴を持ち、Lotus Development Corporation (現在は IBM に合併)、Deloitte, Haskins & Sells (現在の Deloitte & Touche)、そして Aluminum Company of America (ALCOA) など、複数の大企業で活躍してきました。 |
記事の評価
| 
