IBM WebSphere Application Server により、サービス指向アーキテクチャー (SOA) アプリケーションに求められる俊敏かつ堅固な基盤が得られ、ビジネス/IT 両面でのイノベーションが可能となります。また、スピーディーなビジネスを実現するさまざまなアプリケーションやサービスを再利用/作成し、基幹業務に関する課題を予測・対応して、市場での競争に勝利できるようになります。
WebSphere Application Server V7 は、過去のリリースを核とする強力で安定した基盤の上に、いくつもの新機能を追加し、機能強化を図った製品です。最新の標準やプログラミング・モデルをサポートしているほか、システム管理、インストール、セキュリティーなども大幅に改善されています。これらの機能が一体となって、WebSphere Application Server のプラットフォーム上のランタイム管理機能、アプリケーション・デプロイメント・オプションが拡張され、一層のコスト削減と事業拡大を支援します。
-
Java EE 5
WebSphere Application Server V7 でサポートされる標準のうちで特筆すべきなのは、Java™ Platform, Enterprise Edition (Java EE) 5 です。WebSphere Application Server V7 は、以前の V6.1 でFeature Packとして提供されていた Web サービス機能や EJB 3.0 機能を含む、Java EE 5 仕様を完全にサポートしています。
Java EE 5 について説明します。この標準の最新リリースで Java エンタープライズ・プログラミング・モデルが大きく進化し、アプリケーション開発者の操作性が大幅に向上した結果、アプリケーション開発者の生産性が著しく上がったのです。Java EE 5 プログラミング・モデルを説明する際によく使われるフレーズに「段階的開示 (progressive disclosure)」というものがあります。これは、今日に至るまで Java EE 開発に必要とされてきた「ボイラープレート (定型)」コードが排除されることを意味します。代わりに、最も一般的に使われるアプリケーション・コンテキストをデフォルトの振る舞いとして提供し、それらのデフォルトをアノテーションで適宜オーバーライドすることによって、必要な実装を実行可能にするのです。この方法なら、アプリケーションを段階的に、しかも必要な範囲のみ構築できます。
WebSphere Application Server V7 には、Java Platform, Standard Edition (Java SE) 6 に対するサポートも追加されています。
-
依存性注入 (Dependency injection)
デフォルトをオーバーライドする際も、アノテーションを使えばコードを書かずに手早く処理できるので、開発者の生産性はさらに向上します。アノテーションは、「依存性注入」または「制御の反転 (IoC: Inversion of Control)」と呼ばれるプログラミング・パターンと合わせて使用されます。この方法は、アプリケーション・コードでは変数のみを宣言し、何が必要かを示すアノテーションを追加するだけにして、指定されたオブジェクト参照やリソース参照はコンテナーで「注入」するというものです。
図 1 に依存性注入の簡単な例を示します。左側は EJB 2.1 アプリケーションのコードです。右側は EJB 3.0 アプリケーションのコードで、EJB であるということをコンテナーに示す、@EJB というアノテーションが使われています。コンテナーは必要なラッパー (ボイラープレート) と一緒に EJB 3.0 アプリケーションを「注入」するため、手作業で処理を行う必要はありません。
図 1. 依存性注入
-
Java Persistence API
EJB コンポーネントを Plain Old Java Objects (POJO) として開発できる点も、Java EE 5 におけるプログラミング・モデル単純化を特徴付けるものの 1 つです。EJB 開発の一層の単純化に役立つのが、アノテーション付き POJO を使ったエンティティーの作成を可能にする Java Persistence API (JPA) です。これを使用すれば、EJB の開発・使用がより容易になり、Java SE 開発者が Java EE を速やかに習得して、エンタープライズ・アプリケーションを開発できるようになります。図 2 は、EJB 2.1 のエンティティー Bean のコードと EJB 3.0 のエンティティー Bean のコードを比較したものです。図 1 での比較と同じく、EJB 3.0 での開発を容易にするためにアノテーションが重要な役割を果たしています。図 2 の @Entity @Table (name ="CUSTS") というアノテーションは、これが CUSTS というテーブルを使用するエンティティー EJB であり、CUSTS テーブルへのキーが @ID のアノテーションを介したフィールド ID として定義されていることを示しています。
図 2. アノテーション付きの POJO
-
Web サービス
Java EE 5 プログラミング・モデルの改良は EJB 開発にとどまりません。Web サービス開発もアノテーションによって大幅に単純化されます。図 3 は、Java EE 1.4 JAX-RPC アプリケーションを左側に、そしてそれに対応する Java EE 5 JAX-WS アプリケーションを右側に示しています。
図 3. Webサービス開発
WebSphere Application Server V7 の JAX-WS 実装では、SOAP 1.2をサポートします。プロトコル・バインディングとして、一般的なXML や HTTP を使用するのと同様に、ワイヤ・レベルのメッセージ形式に SOAP を使用しない WS クライアントや WS プロバイダーも作成することが可能です。
WebSphere Application Server V7 に追加された重要機能としては、Message Transmission Optimization Mechanism (MTOM) に対するサポートも挙げられます。これはバイナリーの添付ファイルの送信方法を改良したものです。MTOM は Java EE ベース以外の Web サービスで好まれる添付メカニズムなので、MTOM がサポートされていれば、Java EE の Web サービスと Java EE 以外の Web サービスの間の相互運用性が向上します。
-
Portlet 2.0 API
WebSphere Application Server V7 には Portlet 2.0 API に対するサポートも追加されています (Portlet JSR 286 仕様とも称されます)。
システム管理も WebSphere Application Server V7 で拡張されており、多くの新規管理機能の追加により、柔軟性と拡張性に富んだ非同期管理トポロジーを容易に実装し、コストを削減しながら効率向上を図れるようになっています。
-
インテリジェント・プロビジョニング
まず最初にご紹介する機能は WebSphere Application Server ランタイムによるインテリジェント・プロビジョニングです。このプロビジョニングでは、アプリケーションに必要とされるランタイム機能のみが選択されるため、メモリーのフットプリントとアプリケーション・サーバーの起動時間の両方を減らすことができます。WebSphere Application Server は、各アプリケーションをインストール時にチェックしてアクティベーション・プランを作成し、実行時には、そのプランで必要とされるコンポーネントのみを起動します。
WebSphere Application Server V7 は、Web コンテナーとコア・ランタイム・コンポーネントのみが起動するという Web/JDBC アプリケーションのシナリオをサポートしています。このことは、EJB コンテナー、SIP コンテナー、Web サービス・ランタイムなども起動している V6.1 とは対照的です (図 4 を参照してください)。またこの機能は、特定の機能しか使用しないサーバー (WebSphere Application Server のプロキシー・サーバーなど) でメモリー・フットプリントを減らす場合にも使用されており、WebSphere Application Server 上で稼働する他の WebSphere 製品の拡張用として設計されています。
図 4. アプリケーションの実行
実行時のフットプリントを削減するためのさらなる対策が、WebSphere Application Server V7 に付属する Java SE 6 実装でも提供されています。IBM の Java SE 5 実装で導入された共用クラス・キャッシュは改良され、キャッシュの永続性が保持されるようになりました。その結果、サーバー上のすべての WebSphere プロセスを再起動しても、キャッシュが存続するようになりました。WebSphere Application Server インスタンスを 1 つしか実行していないアプリケーション開発者なら、共用クラスのキャッシュの内容をアプリケーション・サーバーの起動時に再読み込みし、それらを個別に、あるいはインテリジェント・プロビジョニングと組み合わせて、使用することができます。これにより、アプリケーション・サーバーの起動が大幅に高速化します。
IBM の Java SE 6 のもう 1 つの改良点は、64 ビット WebSphere Application Server JVM における参照の圧縮 (ポインター圧縮) の使用です。参照の圧縮を使用すれば、64 ビット JVM のプロセス・フットプリントを従来の 32 ビット JVM から大幅に削減することができます。IBM の Java SE 6 実装以前は、64 ビット・ヒープのサイズが同等の 32 ビット・ヒープの 1.7 ～ 2 倍になることが珍しくありませんでした。
-
管理エージェント
フレキシブル・マネジメント機能を備え、大規模なデプロイメント環境を管理する際のコストをいくつかの方法で削減できることも、WAS V7での機能拡張の 1 つです。WebSphere Application Server (Base) V6.1 のランタイム・モデルを、V7 で提供されるフレキシブル・マネジメントと比較すれば、この新機能について最もよくわかります。V6.1 では、管理ランタイムは WebSphere Application Server でホストされており、管理コンソールはアプリケーション・サーバー上で実行されます。アプリケーション・サーバーに対して wsadmin スクリプトを実行すると、アプリケーション・サーバーのプロセスごとに管理オーバーヘッドが生じてしまいます。また、アプリケーション・サーバーの複数の「Base」プロファイルを管理する機能はなく、図 5 に示すように、それぞれを別々に管理しなければなりません。
図 5. 複数のBaseプロファイル
フレキシブル・マネジメントでは管理コンポーネントの大半がアプリケーション・サーバーのランタイムから切り離されるため、この図は塗り替えられます。個々のアプリケーション・サーバーが管理ポイントになるという状況がなくなるのです。そしてそれを実現するのが、WebSphere Application Server (Base) のための独立した管理プロセス、すなわち図 6 の管理エージェントです。
図 6. 管理エージェント
管理機能をアプリケーション・サーバーから管理エージェントに移せば、果たして処理能力は上がるのでしょうか。その答えは、管理エージェントは 1 台のマシン上にある複数の WebSphere Application Server (Base) インスタンスを管理することができるという事実にあります (図 7 を参照してください)。管理エージェントを使用すれば、アプリケーション・サーバーのインスタンス数が増加しても、アプリケーション・サーバーごとに管理するためのフットプリントを重複して持つ必要がありません。しかも、管理エージェントは 1 台のマシン上にあるアプリケーション・サーバーの全インスタンスを管理できるため、個々の管理ポートをアプリケーション・サーバーごとにすべて管理するのではなく、管理エージェント用のリモート管理ポート・セットが 1 つで済みます。
管理エージェントを利用する場合は、以下に注意してください。
- 管理エージェントは、同一マシン上に置かれたアプリケーション・サーバーのみを管理できます。
- 管理エージェントは複数のアプリケーション・サーバーを管理できますが、それぞれのアプリケーション・サーバーは個別に管理されます。つまり、管理エージェントにログインし、サーバー 1 の構成を変更してログアウトしたら、今度はサーバー 2 の構成を変更するためにログインする、といった具合です。
- 管理エージェントは、これらのアプリケーション・サーバー (およびそのアプリケーション) に対する管理のみを提供し、クラスタリングやフェイルオーバーには対応しません。クラスタリングやフェイルオーバーを実行し、アプリケーションを集中管理するには、今後も WebSphere Application Server Network Deployment が必要となります。
図 7. 管理エージェントによる複数アプリケーション・サーバーの管理
-
ジョブ・マネージャー
WebSphere Application Server Network Deployment V7 (以後 Network Deployment) に備わっているフレキシブル・マネジメントには、ジョブ・マネージャーという機能もあります。管理エージェントの場合と同様に、ジョブ・マネージャーが機能する仕組みを最も的確に説明するには、V6.1 のランタイム・モデルを見直してみましょう。図 8 にこれを示します。
図 8. V6.1 のランタイム・モデル
Network Deployment では、以下のコンポーネント同士は密接に結合しています。
- アプリケーション・サーバーとノード・エージェントの間
- ノード・エージェントとデプロイメント・マネージャーとの間
ランタイム・コンポーネントが互いに近い場所に存在しない場合、このような密結合は管理ランタイムの拡張性に影響を及ぼします。例えば、中央拠点にあるデプロイメント・マネージャーから、離れた支店に散在するノードを管理するという場合がこれにあたります。冗長性のある低遅延の大容量ネットワークが中央拠点と支店の間に存在するという最高の状況においても、広域ネットワーク (WAN) はローカル・エリア・ネットワーク (LAN) ほど信頼できない、あるいはどちらにもしばしば障害が発生するという単純な理由から、問題が生じる可能性は捨て切れません。
Network Deployment のジョブ・マネージャーは、疎結合による管理アーキテクチャーを採用することで、現在の管理アーキテクチャーの制限を解決します。複数のリモート・エンドポイント (ノード・エージェント) を同期的に制御するのではなく、複数のノード間で非同期的なジョブ管理を行う機能を提供することによって、複数エンドポイントにわたる管理をコーディネートします。この管理モデルはリモート・エンドポイント (WebSphere Application Server (Base) の管理エージェント、あるいは Network Deployment のデプロイメント・マネージャー) に管理ジョブを任せることによって成立します。この管理エージェントまたはデプロイメント・マネージャーがジョブの実際の実行役となり、構成の更新やアプリケーションの起動/停止など、さまざまな管理作業を行います。
図 9 はジョブ・マネージャーが提供する管理モデルです。ここで重要なのは、ジョブ・マネージャーはデプロイメント・マネージャーの代わりではなく、1 つ以上 (通常は複数) のNetwork Deployment デプロイメント・マネージャーをリモート管理するオプションだということです。先に示した、複数のリモート・ノードを 1 つのデプロイメント・マネージャーから管理しようとしている例を思い出してみましょう。ジョブ・マネージャーを使用することによって各支店が独自の Network Deployment セルに変換され、そのそれぞれでデプロイメント・マネージャーがローカルに稼働することになります。そしてジョブ・マネージャーは、個々のリモート・セルをリモート管理することができます。
図 9. ジョブ・マネージャーの管理モデル
この新機能によって、図 10 に示すような、多数のより高度な配備・管理トポロジーが可能になります。
図 10. 高度なトポロジー
ここでも、ジョブ・マネージャーは Network Deployment セルやデプロイメント・マネージャーの代わりにはなっていません。表 1 では、ジョブ・マネージャーとデプロイメント・マネージャーの機能を詳しく比較しています。ご覧のとおり、Network Deployment が提供するランタイム機能とフレキシブル・マネジメントが提供する管理機能の間には、重なる部分がほとんどありません。別の言い方をすれば、フレキシブル・マネジメントは、Network Deployment によって提供されるようなエンタープライズ対応の実行時サービス品質を提供することはできません。フレキシブル・マネジメントはむしろ、WebSphere Application Server V7 と WebSphere Application Server Network Deployment V7 の 2 つの管理機能を拡張するものです。
| アプリケーション・サーバー管理機能 | デプロイメント・マネージャー | ジョブ・マネージャー |
|---|
| リモート管理 | あり | あり |
| コンソールからのきめ細かい管理 | あり | なし |
| 管理プロセス停止時の管理 (ローカル接続) | あり | なし |
| クラスタリング：ワークロード管理 | あり | なし |
| クラスタリング：フェイルオーバー | あり | なし |
| プラグイン・ベースの、HTTP リクエストのルーティング | あり | なし |
| データ複製 (メモリー・ベースのセッション複製) | あり | なし |
| 構成バックアップ/リストアの集中化 | あり | なし |
| サーバー・パフォーマンスのモニタリング | あり | なし |
| 管理機能のスケジューリング | なし | あり |
-
Web サービス
V7 に新規搭載された重要なシステム管理機能は、先に述べたプログラミング・モデルの改良に加えて、Web サービスの分野にも存在します。Web サービス・ポリシー・セットは WebSphere Application Server V7 によって提供されるメカニズムであり、デプロイ済みの Web サービスに適用するさまざまなサービス品質(QoS)ポリシーを一元的に定義するためのものです。ポリシー・セットには次の 2 種類があります。
- アプリケーション・ポリシー・セット：WSDL ファイルで定義されるビジネス・オペレーションのように、ビジネス関連のアサーションに使用されます。
- システム・ポリシー・セット：QoS ポリシーを適用する仕様で定義されているメッセージのように、ビジネス関連以外のシステム・メッセージに使用されます。WS-Trust で定義されているセキュリティー・トークン (RST) メッセージや、WS-Reliable Messaging メタデータで定義されるシーケンス・メッセージの作成などがその例です。
ポリシー・セットを使用すると、個々のポリシーを定義して各 Web サービスに個別に適用する代わりに、該当するすべての Web サービス・アプリケーションにポリシーを一括適用し、特定タイプの Web サービスに均一のサービス品質(QoS)を持たせることができます。これに関連し、WebSphere Service Registry and Repository は既存のアソシエーションに加えて WebSphere Application Server V7 の JAX-WS ポリシー・セットを探し、それらをポリシーのアタッチメントとして提供します。以下に示すように、デフォルトのポリシー・セットが多数用意されています。
- LTPA WSSecurity Default
- Kerberos V5 HTTPS default
- SSL WSTransaction
- Username SecureConversation
- Username WSSecurity default
- WS-Addressing default
- WSHTTPS default
- WS-I RSP ND
- WS-ReliableMessaging persistent.
さらに、必要に応じてポリシー・セットをカスタマイズ/修正することも可能です。
-
メッセージング
WebSphere Application Server V7 では、Web サービスだけでなく関連する SOA コンポーネント、すなわちメッセージングも改良されています。クラスター・バス・メンバーや外部バス接続を構成するためのSystem Integration Bus (SIBus)の新しい管理ウィザードが提供され、また、SIBus 許可やWebSphere MQ JCA リソース・アダプター構成、アプリケーションの SIBus リソース使用状況検査のための新しいパネルが提供されています。
また V7 には、WebSphere MQ JMS JCA 1.5 リソース・アダプターのほか、関連する新しいパネルや管理コマンドも含まれています。JCA 1.5 リソース・アダプターが用意されているということは、WebSphere MQ からのメッセージを消費するメッセージ・ドリブンBean が、リスナー・ポートの代わりにアクティベーション・スペックを使用できるようになったということです。
さらに、アクティベーション・スペックの管理、つまり停止、開始、メッセージ再試行の制限 (ポイズン・メッセージのフィルタリング) も、WebSphere Application Server V7 での改良点です。
-
集中インストール
Network Deployment では、デプロイメント・マネージャーからリモート・ノードへの集中インストールを実行する機能も追加されます。これにより、デプロイメント・マネージャーへのインストールを 1 回行えば、それがインストール・パッケージとしてデプロイメント・マネージャーから一連のエンドポイントにプッシュされるようになります。このエンドポイントは Network Deployment セルに含まれないノード (この場合は Network Deployment をインストール可能) か、フィックス・パックが必要な既存 Network Deployment ノードのいずれかです。
-
ビジネス・レベル・アプリケーション
WebSphere Application Server V7 のさらなる新機能として、J2EE™ を超える「アプリケーション」の概念、すなわちビジネス・レベル・アプリケーション (BLA) があります。これは J2EE によって提供されてきた「管理」の概念を新たに拡張したもので、次のようなアプリケーションで価値を発揮します。
- 複数のパッケージで構成されている
- 追加のライブラリーや、Java EE 以外の成果物が含まれている
- 異機種混合 (WebSphere および非 WebSphere) のランタイム環境で稼働する成果物が含まれている
- アプリケーションに他のアプリケーションが含まれているなど、再帰的に定義されている
図 11 に示すように、BLA は本来、Java EE などの成果物を 1 つのアプリケーション定義の下で管理するための「グループ化」の概念です。BLA は、プロキシー・サーバー、Web サーバー、WebSphere Application Server Community Edition など、ターゲットとなる WebSphere Application Server デプロイメントのランタイム環境を超えて拡大することが可能です。さらに BLA は、インストール、配布、アクティブ化、モニタリング、更新、削除など、アプリケーションの全ライフ・サイクルを管理することができます。
図 11. ビジネス・レベル・アプリケーション
-
セキュリティー
セキュリティーの管理および監査も、WebSphere Application Server V7 で改良された主な新機能です。最も顕著な機能拡張は、1 つの WebSphere Application Server セルの中に複数のセキュリティー・ドメインを作成できるようになったことでしょう。セキュリティー・ドメインはそれぞれ独自のユーザー集団 (およびその基礎となるリポジトリー) を持つことができます。また、アプリケーション・ドメインは管理ドメインから分離可能です。アプリケーション・サーバー・レベルの現在のセキュリティー構成オプションに加えて、各ドメインがそれぞれ独立したユーザー集団を持てるだけでなく、各ドメインを例えば JAAS ログイン構成、TAI、認証プロバイダー、JCA 認証データ、監査といった別々のセキュリティー構成でカスタマイズすることも可能です。ドメインの範囲は固定ではなく、セル、クラスター、ノード、ノード・グループ、アプリケーション・サーバー・グループなど多岐にわたります。その結果、アプリケーションは図 12 に示すように、個別のユーザー集団とセキュリティー構成を持つようになります。
図 12. 新しいアプリケーション・セキュリティー
さらに V7 では、WebSphere Application Server V6.1 で導入されたきめ細かい管理セキュリティー（fine-grained管理セキュリティー）機能 (V6.1では wsadmin に限られていた機能) が拡張され、管理コンソールも含まれるようになりました。そのため、管理ロールを特定のコンポーネント (セルの管理セキュリティー・ドメイン内のクラスター、ノード、アプリケーション・サーバー、アプリケーションなど) に制限できるようになります。
-
監査
もう 1 つのセキュリティー強化機能として、WebSphere Application Server の管理アクションのセキュリティー監査レコードを生成するオプションがあります。セキュリティー構成の変更、鍵および証明書の管理、アクセス制御ポリシーの変更、バスなどのシステム・リソースの管理などがこのアクションにあたります。この機能により、管理ユーザーは構成やランタイムの変更についての説明責任を果たせるようになります。
さらに、監査レコード/構成の検討と制御が新しい監査ロールに委ねられるため、管理ユーザー権限を分離することが可能になります。例えば、管理者は監査ポリシーの変更と監査レコードの閲覧ができず、監査担当者は WebSphere の構成や実行時の状態を変更できない、といった具合です。図 13 は、新しい監査システムの出力を例示したものです。
図 13. 監査の出力
-
Kerberos
WebSphere Application Server V7 は、さまざまなシングル・サインオン環境で使用することができる Kerberos 認証をサポートしています。V7 の Kerberos サポートは V6.1 の SPNEGO TAI サポートを基にして拡張されたもので、Kerberos 認証をサポートしている他のアプリケーション (IBM DB2®、.NET® など) との相互運用性を高め、ID 伝搬機能を拡張することができます。
WebSphere Application Server V7 には、この新リリースでサポートされている標準を活用するうえで役立つ、アプリケーション開発のための 2 つのツールが含まれています。
IBM WebSphere Application Server V7 はランタイムを劇的に改良したメジャー・リリースであるだけでなく、アプリケーションを開発してデプロイするためのシンプルで使いやすい方法を提供します。この記事では、それらの改良を可能にしたさまざまな新機能および機能強化について、概要をご紹介しました。
