![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Apache Axis2 (主要なオープン・ソース Web サービス・フラットフォームの 1 つ) には数々の新しいフィーチャーが生かされていますが、賢明にもその多くは、開発者たちに一層使いやすい方法を提供する結果となっています。Axis の以前のバージョンでは、使いやすさは二の次にされていました。例えば Axis1 では、ユーザーは管理クライアントを手動で起動してサーバーのクラス・パスを更新し、それからサーバーを再起動して変更を適用しなければなりません。このような手のかかるデプロイメント・モデルが初心者にとって障壁となっていたのは明らかです。そのため、Axis2 はこの障壁を取り除き、より柔軟で構成しやすいデプロイメント・モデルになるように設計されました。
Axis2 デプロイメント・モデルでは、新しい多くのフィーチャーを Apache Web サービス・スタックに導入しています。そのうちのいくつかは、Web サービスのパラダイムにとって目新しいものではありません。以下に、重要性が最も高い主要な変更内容と新規フィーチャーをリストします。
- J2EE (Java™ 2 Platform, Enterprise Edition) のようなデプロイメント・メカニズム (アーカイブ・ベース)
- ホット・デプロイメントとホット・アップデート
- リポジトリー (サービスとモジュールをドロップする場所)
- ハンドラー (モジュール) のデプロイメントにおける変更
- 新規デプロイメント記述子
- 複数のデプロイメント・オプション
以降のセクションでは、上記の項目ごとに詳細を説明していきます。
J2EE アプリケーション・サーバーでは、必要なものを完備した (自己完結型) パッケージとしてアプリケーションをデプロイすることが可能なので、リソース、構成ファイル、そしてバイナリー・ファイルのすべてを 1 つのファイルに組み込んでデプロイできます。この利便性は明らかです。そのため Axis2 でも同じメカニズムを採用して、サービス (およびモジュール) をデプロイするのが便利なようにしています。
ここで、サード・パーティーに対するいくつかの依存関係と一連のプロパティー・ファイルを持つサービスがある一方、J2EE のようなデプロイメント・メカニズムは使えないというシナリオを考えてみてください。この場合、従属する JAR ファイルとプロパティー・ファイルをすべて手作業でクラス・パスに組み込まなければなりません。サーバーが 1 つ、あるいは 2 つあったとすると、その作業は倍になります。さらに使用しているのがクラスター環境で、数百の複製があるような場合、従属する JAR ファイルやその他のリソースをクラス・パスに追加するのは非現実的な作業です。その一方、J2EE のようなデプロイメント・メカニズムがあれば、このような問題はなくなります。サービスを複製に組み込みさえすればいいだけの話になるからです。
図 1 は、Axis2 の自己完結型パッケージ (アーカイブ・ファイル) の内部構造です。両方の Axis2 サービス (アーカイブおよびモジュール・アーカイブ) は非常によく似ています。多少の違いとしては、以下の点が挙げられます。
- Axis サービスの記述子ファイルは services.xml で、Axis モジュールの記述子ファイルは module.xml です。
- Axis2 サービスのファイル拡張子は .aar (サービスのファイル名は foo.aar) で、Axis2 モジュールのファイル拡張子は .mar (モジュールのファイル名は foo.mar) となります。
図 1. アーカイブ・ファイルの構造
エンタープライズ・レベルのアプリケーションとなると、可用性が重大な問題になってきます。わずかなダウンタイムでも大きな悪影響を及ぼすため、サーバーを再起動するのは賢い選択肢とは言えません。必要なのは、システムをシャットダウンせずに更新することです。そこで活躍するのが、ホット・デプロイメントとホット・アップデートです。ホット・デプロイメントとホット・アップデートは、Apache Web サービス・スタック (Axis および Axis2 など) に今までになかった新しいフィーチャーとなります。この 2 つのフィーチャーの内容は、以下のとおりです。
- ホット・デプロイメントとは、システムを実行している状態で新しいサービスをデプロイする機能のことです。例えば、service1 と service2 という 2 つのサービスを実行しているときに、システムをシャットダウンしないで service3 という新しいサービスをデプロイするとします。この場合、service3 のデプロイメントがホット・デプロイメントのシナリオとなります。システム管理者としてサービスのホット・デプロイメントが好ましくないと思う場合は、Axis2 のグローバル構成ファイル axis2.xml にあるグローバル構成パラメーターを <parameter name="hotdeployment">false</parameter> に変更するだけで、この機能を簡単に無効にできます。
- ホット・アップデートとは、システムをシャットダウンせずに既存の Web サービスを変更する機能のことです。これは、テスト環境では重要かつ必要なフィーチャーですが、リアルタイム・システムでの使用は推奨されていません。ホット・アップデートによってシステムの状態が不明になるおそれがあるためです。さらに、該当サービスの既存のサービス・データの結合が緩められる可能性もあります。これを防ぐため、Axis2 ではデフォルトで、ホット・アップデートのパラメーターが FALSE に設定されています。このフィーチャーを使用するには、構成パラメーターを <parameter name="hotupdate">true</parameter> に変更してください。
基本的に、Axis2 リポジトリーはファイル・システム内に含まれる特定の構造を持つ 1 つのディレクトリーです。リポジトリーはローカル側に置くことも、リモート・システムに配置することもできます。このリポジトリーという概念は、アーカイブ・ベースのホット・デプロイメント・フィーチャーを使いやすくするために導入されました。
repository ディレクトリーを構成するのは 2 つの主要なサブディレクトリー、services と modules です。lib というオプションのサブディレクトリーが含まれる場合もあります。サービスをデプロイするには、該当するサービス・アーカイブ・ファイルを services ディレクトリーにドロップしなければなりません。同様に、モジュールをデプロイするにはモジュール・アーカイブ・ファイルを modules ディレクトリーにドロップします。一方 lib ディレクトリーについては、services と modules に共通のサード・パーティー・ライブラリーの保管場所にするという意図があります。リポジトリーの構成は、図 2 のとおりです。
図 2. Axis2 リポジトリー
注: modules ディレクトリーに含まれる一部またはすべてのモジュールにリソースを共有させるには、該当するリソースを modules ディレクトリー内の lib ディレクトリーに追加します。同様に、services ディレクトリーに含まれる一部またはすべてのサービスで共通のリソースを共有させる場合は、該当するリソースを services ディレクトリー内の lib ディレクトリーの適切な場所に追加します
サービス拡張 (つまりモジュール) という概念は Apache Axis パラダイムには新しいフィーチャーで、その狙いは、システムのコア機能を拡張すること、あるいはサービス品質を提供することです。Axis1 でコア機能を拡張しようと思ったら、まずハンドラー (実行チェーンの最小単位) を作成しなければなりません。それからグローバル構成ファイルを変更してそのハンドラーを追加し、最後にシステムを再起動する必要があります。
モジュールはハンドラーと同じように機能しますが、必要な作業は少なくなります。その一方で、モジュールは module.xml というモジュール記述子と併せて 1 つ以上のハンドラーを持つことができるます。大抵の場合、モジュールは特定の WS 仕様の実装となります。その一例として、Axis2 アドレッシング・モジュールは WS アドレッシングの実装です。
前述したように、モジュールはアーカイブ・ファイルとしてデプロイできます。図 3 は、モジュール・アーカイブ・ファイルの構造です。
図 3. モジュール・アーカイブ・ファイルの構造
Axis2 の柔軟性と拡張性の重点は、Axis2 のデプロイメント記述子に置かれています。そのため、Axis2 では 1 つの構成ファイルだけを操作するのではなく、構成のレベルによって異なる構成ファイルを使い分けることになります。例えば、ハンドラーをシステムに追加する場合、グローバル構成を変更する必要は一切ありません。該当するモジュール構成ファイルを変更するだけで済むからです。Axis2 の記述子 (構成ファイル) には、以下の 3 つのタイプがあります。
- グローバル記述子 (axis2.xml)
- サービス記述子 (services.xml)
- モジュール記述子 (module.xml)
グローバル記述子には、以下をはじめとしたシステム全体にわたる構成が axis2.xml で指定されます。
- パラメーター
- トランスポートの送信側
- トランスポートのリスナー
- フェーズ
- グローバル・モジュール
Axis2 にはデフォルトの axis2.xml が付属しています。このファイルには Axis2 を起動するために必要な最小構成が含まれていますが、好きなように変更して独自の axis2.xml で Axis2 を起動することもできます。ここで注意しなければならないのは、axis2.xml に何らかの変更を加えた場合、システムを再起動するまでは変更が適用されないということです。
サービス記述子には、サービスに関する構成が services.xml で指定されます。サービスを有効にするには、そのサービス・アーカイブ・ファイルに services.xml が含まれていなければなりません。サービス構成ファイルの内容は以下のとおりです。
- サービス・レベルのパラメーター
- サービスの説明
- メッセージの受信側
- Web 操作として公開する必要がある操作 (サービス内の操作)
- サービス・レベルのモジュール
モジュール記述子ファイル (module.xml) は、モジュールをシステムに接続するために必要な構成データで構成されます。重要な構成には以下があります。
- ハンドラーとそのフェーズ規則
- モジュールのパラメーター
重要な点として、module.xml には以下の要素が含まれている場合もあります。
- モジュールについての説明 (および、モジュールが実装している仕様)
- エンドポイント (信頼性の高いメッセージングの場合、エンドポイントのような作成シーケンス)
Axis2 には、以下の 3 つの主要なサービス・デプロイメント方法があります。
- サービス・アーカイブ・ファイルをリポジトリーにドロップする。
- アーカイブ・ファイルを使ってサービスをプログラムで作成する。
- サービスを POJO (Pain Old Java Object) としてデプロイする。
Axis2 でサービスをデプロイするときに最もよく使われるのは、サービスのアーカイブ・ファイルを単にリポジトリー (services ディレクトリー) にコピーあるいはドロップするという手法です。Axis2 WAR ファイル・ベースの配布を使用している場合には、ドロップ方法として以下の 2 つの選択肢があります。
- アーカイブ・ファイルを手動でリポジトリーにドロップする。
- Web コンソールを使ってサービスをアップロードする。
サービスをプログラムでデプロイするという方法は、ユーザーにとってはあまり必要でありません。それよりむしろモジュール作成者に要求されるデプロイメント方法で、モジュールの機能を完全に提供するためには Web サービスをデプロイしなければならない場合にこの方法が採られます。サービスをプログラマによって作成するには、services.xml、クラス・ローダー (クラス・ファイルをロードするために使う可能性がある)、そして AxisConfigurationが必要になります。この方法の利点は、サービス・アーカイブ・ファイルをリポジトリーにコピーする必要がないことで、該当するサービスは実行時にようやく目にすることになります。リスト 1 を見ると、プログラムによるサービスのデプロイメントについての基本を理解できます。
リスト 1. プログラムによるサービスのデプロイメント
ConfigurationContext configContext;
// you need to have reference to ConfigurationContext
File file = new File("Location of the file");
ClassLoader clsLoader = new URLClassLoader(new URL[]{file.toURL()});
InputStream in = new FileInputStream("location of service.xml");
AxisService service = DeploymentEngine.buildService(in, clsLoader,
configContext); |
Java クラスを使ったサービスのデプロイメントは、Axis2 の便利なフィーチャーです。この方法では、Web サービスに Java クラスを作成するだけで済むため、サービス・アーカイブ・ファイルや services.xml を使う必要は一切ありません。唯一の要件としてサービスを作成する前に Java クラスをクラス・パスに組み込めば、実行時にモジュールまたはサービスのいずれかによって新しいサービスを作成してデプロイできます。Axis2 で POJO をデプロイするためのコードは、リスト 2 に示すたった 3 行です。
リスト 2. Axis2 での POJO のデプロイメント
AxisService service = AxisService.createService(
MyService.class.getName(), axisConfig, RPCMessageReceiver.class);
axisConfig.addService(service);
|
Axis2 は Web サービスの概念を証明するためのものではなく、より優れた SOAP 処理モデルを提供するためのものです。Axis2 では、速度とメモリー両方の点で Axis1 やその他の既存の Web サービス・エンジンよりも大幅にパフォーマンスが向上するだけでなく、便利なデプロイメント・メカニズムも手に入れることができます。そんな Axis2 を早速使ってみてください。
学ぶために
-
Apache Axis2 の Web サイトにアクセスしてください。
- 「SOA development with Axis2, Part 1: Understanding Axis2 basis」(developerWorks、2006年8月) を読んでください。
- IBM® developerWorks の SOA and web services ゾーンには、Web サービス・アプリケーションの開発方法について情報を提供する記事、そして初級者、中級者、上級者向けのチュートリアルが豊富に揃っています。
-
IBM SOA Web サイトでは、SOA の概要と IBM による SOA 支援について記載しています。
-
developerWorks technical events and webcasts で最新情報を入手してください。
- Apache プロジェクトについての詳細は、developerWorks の Open source ゾーンで紹介している多数の Apache 関連記事と無料の Apache チュートリアルを参照してください。
製品や技術を入手するために
- IBM ソフトウェアの試用版を使用して、次の開発プロジェクトを革新してください。ダウンロード、あるいは DVD で入手できます。
議論するために
