Webサービスと既存アプリケーションドメインとの統合
ここまでの手順でWebサービスのプロバイダサイドの構造は用意できたので、次は既存のPOJOドリブンドメイン機能との統合を行います。先に見たように、SpringによるPOJOクラスの注入はSkeletonについて行われます。よって下記のように、そのためのセッターメソッドをスケルトン中に作成する必要があります。
public void setservice(AccountManager service) { this.service = service; }
このオブジェクトを用いると、ドメインクラス中のメソッドを起動することができます。このドメイン関数はドメインオブジェクトを返すので、これをWebサービスのスキーマオブジェクトにマッピングします。このプロセスをさらに最適化するには、JiBXなどのツールを使ってドメインオブジェクトに直接マッピングします。変更後のサーバサイドコードは次のようになります。
Account acct = service.getAccount(accountId);
GetAccountResponse response = new GetAccountResponse();
com.corp.account.domain.bo.xsd.Account acctXSD
= new com.corp.account.domain.bo.xsd.Account();
acctXSD.setAccountId(accountId);
acctXSD.setAddress(acct.getAddress());
acctXSD.setFirstName(acct.getFirstName());
acctXSD.setLastName(acct.getLastName());
acctXSD.setStatus(acct.getStatus());
response.set_return(acctXSD);
このコードの最後のステートメントは、サービスレスポンスとしての戻り値を示しています。
サービスの配備
Axis2の特徴の1つはその配備モデルにあります。Axis2の配備モデルはJ2EE配備のアーカイブベースの構造を踏襲しており、配備およびサービス記述子を包括するアーカイブを使用します。このアーカイブはAxis Application Archive（AAR）と呼ばれています。
配備するサービスのアーカイブを作成するには、Axis2プロジェクトから提供されている別のEclipseプラグインを使用します。その際に、アーカイブ作成に関するオプションを指定する必要があります。この場合もコマンドラインオプションを使用できます。このアーカイブファイルには、すべてのサービスコードに加えて、サービス記述子として機能する「service.xml」も取り込まれます。基本的な考え方は、このアーカイブをAxis2 Webアプリケーションを通じてアップロードすることで、アプリケーションのホット配備とアップデートを実行時に行うというものです。
この他に、これらのサービスを既存EARの一部として配備する場合（組み込み型のAxis2配備）のオプションとして、WebプロジェクトにおけるWEB-INFの下層に特殊な「services」ディレクトリを作成し、このディレクトリにアーカイブをドロップするという方法もあります。エンタープライズアプリケーションの多くは管理された環境下で事前に組まれたリリース計画に従って配備されるので、通常は後者のオプションの方が好まれます。後者の場合、アプリケーションの配備EARの中にWebサービスを取り込むことができるからです。この機能を利用すると、管理、所有権、説明責任の取り扱いが簡単化されます。
なお、このWebプロジェクトのWARは（アプリケーションEAR内の）独立したプロジェクトにすることをお勧めします。他のJSP/Servlet WebアプリケーションのWARと共有するべきではありません。このようにしておくと柔軟性が向上し、またコンテナのWebアプリケーションライブラリとの競合を防止できます。
展開形式での配備アプローチ
ただし、Springサポートを利用してAARファイルをWebSphereやWebLogicなどのエンタープライズアプリケーションサーバに配備する際には、いくつかの問題があります。よってこれらのサーバについては、展開形式での配備アプローチが推奨されます。下記の手順は、Axis2アプリケーションをWebSphere Application Serverプラットフォームに展開形式で配備するステップをまとめたものです。
- AARファイルをWEB-INF下層の専用ディレクトリに展開する。通常は、AARファイル（基本的にはJARファイル）を「WEB-INF/services/<WSDL中のサービス名>」ディレクトリに展開する。ただしSpringサポートを利用して定義されたBeanの実装クラスへの参照を許している場合はプロセスが若干異なり、以降の手順を経る必要がある。
- 「WEB-INF/services/<サービス名>」ディレクトリには、サービス構造全体ではなく、「services.xml」およびサービスWSDLのみが格納される。「META-INF」ディレクトリを含めた残りのファイルについては、JAR化してアプリケーションクラスパス中の「WEB-INF/lib」ディレクトリに追加する。これによりSpringは定義されたクラスを検索してそのBean定義をインスタンス化することができる。
- 「WEB-INF/」ディレクトリに「service.xml」のコピーを配置する。
- Axis2 Webアプリケーションを利用した配備を行わない場合は、配備対象のWebアプリケーションに対して、SOAPサービスまたはRESTサービス宛てのすべてのリクエストを適切なServletにマッピングするための指示を与えなければならない。そのため「WEB-INF/web.xml」についても下記のように変更する必要がある。
- WebSphereに配備すると、WebSphereが持つAxis 1.xベースのWebサービス実装クラスと直接競合することになる。こうした競合は主として「wsdl4j.jar」および「qname.jar」ライブラリで発生する傾向が見られるが、これらに限定されるわけではない。そのためEARとWARの双方に関し、
WebSphereクラスローダのポリシーをPARENT_LASTと変更する必要がある。これによりWebSphereは最初にアプリケーションライブラリをロードし、その後にWebSphereの固有ライブラリをロードするようになり、Axis2の配備に関連する問題を回避できる。
<servlet> <servlet-name>AxisServlet</servlet-name> <servlet-class> org.apache.axis2.transport.http.AxisServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet> <servlet> <servlet-name>AxisRESTServlet</servlet-name> <servlet-class> org.apache.axis2.transport.http.AxisRESTServlet </servlet-class> <load-on-startup>2</load-on-startup> </servlet> <servlet-mapping> <servlet-name>AxisServlet</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>AxisRESTServlet</servlet-name> <url-pattern>/rest/*</url-pattern> </servlet-mapping>
動作確認
アプリケーションの配備と起動が正常に行われたら、次のアドレスにアクセスして動作を確認します。
- http://localhost:9080/AccountWeb/services/Accountservice?wsdl
RESTバージョンの場合は、次のアドレスで確認します。
- http://localhost:9080/AccountWeb/rest/ccountservice/getAccount?accountId=1
WebLogicの場合も、基本的に同様のプロセスを用います。
