Comments
Transcript
WebSphere Application Server V5 アーキテクチャー
WebSphere Application Server V5 アーキテクチャー 目次 １．サーバー・アーキテクチャー ...................................................... 3 ２．セル、ノードとサーバー ............................................................ 7 ３．サーバー ............................................................................... 9 ４．コンテナ .............................................................................. 13 ５．アプリケーション・サーバー・サービス ........................................ 16 ６．ビジネス・プロセス・エンジン .................................................... 26 ７．仮想ホスト............................................................................ 28 ８．セッション管理 ...................................................................... 29 ９．Web サービス ....................................................................... 32 １０．セキュリティー..................................................................... 38 １１．リソース・プロバイダー .......................................................... 46 １２．管理 ................................................................................. 54 １３．アプリケーションのフロー ...................................................... 59 １４．アプリケーションの開発とデプロイ........................................... 61 2 １．サーバー・アーキテクチャー WebSphere Application Server ファミリー製品は、基本的に同じアーキテクチャーで構成されていま す。最も下位バージョンにあたる Express 版でも同じことがいえます。Base 版は Express 版より上位 にあたり、その上が Network Deployment 版になります。そして、最上位バージョンが Enterprise 版 になっています。 Express 構成 Express 版と Base 版がサポートできるのはシングル・サーバー環境です。Express 版と Base 版では、 複数のアプリケーション･サーバーを構成したとしても、集中管理やワークロード管理の機能は使用 できません。各アプリケーション･サーバーは単体としての実行環境となります。Base 版の一部機能 を省いた製品が Express 版にあたります。この 2 製品にはいくらかの違いがありますが、一番の違い は、Express 版では EJB コンテナとメッセージングをサポートしてないことです。 Node Application Server HTTP サーバー Web コンテナ SOAP (Web サービス エンジン JCA サービス Name Server(JNDI) Security server Studio Site Developer 図1 IBM Agent Controller WebSphere Application Server – Express 3 Config リポジトリ (XML files) Admin service Admin UI Application (EAR) 組み込み HTTP server application WebSphere Plug-in Admin Web ブラウザ クライアント Application データベース Base 構成 Express 版の上位製品が Base 版になります。Express 版には対応していない、EJB コンテナ、組み 込みメッセージング、JCA リソース･アダプター･サポートといった機能を備えていますが、集中管理 サポートと負荷分散機能は含まれていません。 図 2 に Base 版のランタイム･アーキテクチャーの概要を示します。 Node Application Server Web ブラウザ クライアント HTTP サーバー Web コンテナ EJB コンテナ Scripting client JCA サービス Client コンテナ Java クライアント Config リポジトリ (XML files) Admin service Admin UI Application (EAR) 組み込み HTTP server application SOAP (Web サービス) エンジン Admin WebSphere Plug-in Application データベース Name Server(JNDI) Security server JMS Server 図2 IBM WebSphere Application Server Network Deployment 構成 Network Deployment 版には、集中管理と負荷分散機能があります。Network Deployment 環境は、 1 台あるいは複数の Base 版から構成されており、デプロイメント･マネージャーがインストールされて います。Base 版のアプリケーション･サーバーはセルに統合され、デプロイメント･マネージャーで管 理されます。また、Network Deployment 版には、Web サービス・プライベート UDDI レジストリと Web サービス・ゲートウェイ機能も提供されています。 4 Cell Admin UI Deployment Manager Admin Service Admin application Scripting client Name Service(NDI) Master リポジトリ (file) Node Node Agent Admin Service Application Server UDDI registry Enbedded HTTP server (ear) HTTP サーバー WebSphere Plug-in Config リポジトリ (files) SOAP (Web サービス) エンジン Web コンテナ Web ブラウザ クライアント Session データベース EJB コンテナ JCA services Web サービス ゲートウェイ Admin service Java クライアント Application (EAR) Client コンテナ Application データベース Name Server(JNDI) Security server JMS Server 図3 IBM WebSphere Application Server Network Deployment Enterprise 構成 Enterprise 版は、基本となる WebSphere Application Server とデプロイメント･マネージャーの他に、 様々なプログラミング・モデル拡張(PME)が提供されています。これらの拡張機能により、より効率 的なプログラム開発、ハイエンドな業務アプリケーションの実装を可能にしています。これらの拡張 機能をサポートするために、Enterprise パッケージには、アプリケーション・サーバーや、ランタイム 環境をサポートするための管理コンソール・フィーチャーにビジネス・プロセス・コンテナが追加され ています。 5 Node Node Agent Application Server Web ブラウザ クライアント HTTP サーバー Web container Admin service EJB コンテナ Application Java クライアント Container Client コンテナ Config リポジトリ (file) Business Process Admin Admin UI Business Process Web サービス エンジン 組み込み HTTP server application WebSphere Plug-in Supporting データベース JCA サービス Scripting client Name Server(JNDI) Security server Application server services PME modules 組み込み JMS server 図4 WebSphere Application Server V5 Enterprise アーキテクチャー 6 Supporting データベース ２．セル、ノードとサーバー WebSphere Application Server は、構成にかかわらずセルとノードとサーバーのコンセプトに基づい て作られています。Network Deployment 版と Enterprise 版を構成するのでなければ、セルとノード に関しては重要な働きはしません。 サーバー 実際のコードを処理するものがサーバーになります。構成によって様々な種類のサーバーが存在 し、各サーバーは、それぞれの JVM で稼動します。 f アプリケーション・サーバー： アプリケーション･サーバーは、すべての構成の中で主要なランタイム･コンポーネントであり、 実際にアプリケーションが実行される場所に相当します。すべての WebSphere Application Server 構成は、1 個または複数個のアプリケーション･サーバーを持つことができます。 Express 版と Base 版の構成では、それぞれのアプリケーション･サーバーは、別々の実体とし て機能し、アプリケーション･サーバー間で、負荷分散機能と集中管理機能を使用できませ ん。 Network Deployment 版の構成は、複数のアプリケーション･サーバーを持つことができ、デ プロイメント･マネージャーから集中管理することができます。さらに、アプリケーション・サー バーをクラスター化して負荷分散機能を実現することができます。 f JMS サーバー： Base 版と Network Deployment 版と Enterprise 版の構成は、メッセージングをサポートする組 み込み JMS サーバーを提供しています。Base 版の構成では、アプリケーション･サーバーに JMS サーバー機能が組み込まれています。Network Deployment 版と Enterprise 版の構成で は、個々の JVM 上で JMS サーバーが稼動します。1 ノードに 1 つの JMS サーバーが存在し ます。 ノード(ノード・エージェント) ノードとは、共通の構成と制御を共有する WebSphere-managed server プロセスの論理的なグルー プです。ノードは、一般的に WebSphere Application Server が物理的にインストールされたサーバ ー本体を指します。WebSphere Application Server Express 版と Base 版の構成では、1 ノードだけ になります。 WebSphere Application Server のより高度な構成になっていくと、1 台の共通の管理サーバーから 7 複数ノードを構成する概念とノード間の負荷分散が採用されます。これらの集中管理の構成では、 個々のノードは管理プロセスを管理するためにデプロイメント･マネージャーとともに稼動するノー ド・エージェントがあります。 セル セルとは、一つのの管理ドメイン内のノードをグループ化したものです。Base 版と Express 版の構成 では、セルには 1 つのノードがあります。そのノードは、複数サーバーを持つこともありますが、それ ぞれのサーバーの構成ファイルは個々に保存されます。 Network Deployment 版と Enterprise 版の構成では、1 つのセルは複数のノードで構成でき、すべ てのノードは、一つの場所で管理できます。セル内の全ノードにある構成ファイルとアプリケーショ ン･ファイルは、セル･マスター構成リポジトリーに集められます。この集中化されたリポジトリーは、 デプロイメント･マネージャーで管理され、それぞれのノードで保持されるローカル・コピーと同期が 取られます。 8 ３．サーバー WebSphere Application Server はホスト・アプリケーションとして必要とされる様々な機能を提供して います。アプリケーション・サーバーはユーザーが作成したアプリケーションを実行します。このサ ーバーはシングル・サーバーとして稼動したり、クラスターのメンバーとして稼動することもあります。 JMS サーバーは非同期メッセージングを提供しています。 表1 WebSphere Application Server V5.0.2 機能サポート状況 アプリケーション・サーバー JMS サーバー アプリケーション・サーバー・ クラスタリング Express Base ND Enterprise ○ ○ ○ ○ ○ ○ ○ ○ × ○（アプリケーション・ サーバーに統合） × × アプリケーション・サーバー アプリケーションサーバーはアプリケーションの実行環境を提供します。このサーバーは特定の Java アプリケーション・コンポーネントの実行を可能にする専用のコンテナやサービスを提供してい ます。 各アプリケーション・サーバーはサーバー自体が持つ Java バーチャル・マシン（JVM）上で稼動しま す。server1 と呼ばれるアプリケーション・サーバーは、インストールの後、自動的に利用できるよう になります。アプリケーション・サーバーは追加することはできますが、Network Deployment（ND）版 もしくは Enterprise 版を使用しない場合は、それぞれが独立した構成になり、負荷分散する機能は ありません。 JMS サーバー メッセージングは下記の JMS プロバイダーを通じて使用する場合のみ、サポートされます。 f WebSphere JMS プロバイダー（組み込み） f WebSphere MQ JMS プロバイダー f 一般 JMS プロバイダー WebSphere MQ JMS プロバイダーや一般 JMS プロバイダーを使用する場合、JMS 機能は他製品に より提供されます。 9 組み込み WebSphere JMS プロバイダーは Express 版を除くすべての WebSphere Application Server のエディションに含まれます。WebSphere JMS プロバイダーによって提供される統合されたメ ッセージング機能には、point-to-point と publish/subscribe のドメイン体系を持つ message-driven beans とトランザクション管理サービスとの統合サポートが含まれています。 組み込み WebSphere JMS プロバイダーの機能は JMS サーバーによって実装されています。Base 版では、JMS サーバーはアプリケーション・サーバーと同じ JVM 上で稼動します。構成上、それは アプリケーション・サーバーの一部になっています。 Network Deployment 版と Enterprise 版では、JMS サーバーはアプリケーション・サーバーから切り 離され、別の JVM 上で稼動します。このエディションでは、JMS サーバーはアプリケーション・サー バーから独立しています。 クラスター Network Deployment 版と Enterprise 版は、分散処理を行なうアプリケーション・サーバーのクラスタ リングをオプションとして提供します。クラスターとはロジカルに負荷分散を行なうためのアプリケー ション・サーバー・プロセスです。 クラスターに含まれるアプリケーション・サーバーは、クラスター・メンバーと呼ばれ、配置されている アプリケーション・コンポーネントはすべて同一でなくてはなりません。クラスター・メンバーはアプリ ケーションを稼動させるための設定以外は、構成情報を共有する必要はありません。 例えば、同じクラスターの別メンバーが小規模なノートパソコン上で稼動している一方で、もう１つの クラスター・メンバーは大規模なマルチプロセッサーのマシン上で稼動しているかもしれません。こ れらの２つのクラスター・メンバーでは、割り当てられたアプリケーション・コンポーネントを除くサー バー構成の設定はかなり異なっています。しかし、その構成範囲内では、アプリケーション・コンポ ーネントは同一です。 このクラスター・メンバーはシングル・ノード上（垂直クラスター）、複数ノード上（水平クラスター）、も しくは、これらの２つと組み合わせた形で割り当てられます。 アプリケーション管理 アプリケーションのインストール、アップデート、または、アンインストールをする時には、クラスター 内で分散されたすべてのメンバーに対して自動的にアップデートが行なわれます。 10 ワークロード管理 クラスター・メンバーであるアプリケーション・サーバーの Web コンテナは、アプリケーション・サーバ ーやサーブレットのために自動的にワークロード管理ができます。サーブレット・リクエストのルーテ ィングは Web サーバー・プラグインとクラスタリングされたアプリケーション・サーバーとの間で HTTP か HTTPS プロトコルを用いて行なわれます。 図5 プラグイン（Web コンテナ）ワークロード管理 このルーティングはクラスター・メンバーに関係する重み付けに基づいています。すべてのクラスタ ー・メンバーが同一の重み付けをされているときは、アフィニティーが設定されている場合を除き、 プラグインはすべてのクラスター・メンバーに均等にリクエストを送ります。重み付けが０∼２０の範囲 であれば、プラグインはより高い重み付けのクラスター・メンバーへリクエストをルーティングします。 下記の公式を用いてルーティングの優先順位を決定します。 Server１へのルーティング ＝ weight1 /（weight1 + weight2 + ．．．+ weightｎ） （クラスター・メンバーがｎ台ある場合です） Web サーバー・プラグインは、クラスター・メンバーが使用できないとき、一時的に別のメンバーにル ーティングします。 EJB コンテナのワークロード管理は、別々のアプリケーション・サーバー上に Web コンテナと EJB コ ンテナが構成されている場合に実行することができます。EJB コンテナをもつ複数のアプリケーショ ン・サーバーは、クラスタリングでき、EJB コンテナ間で EJB リクエストの分散ができます。 11 図6 EJB ワークロード管理 上記の構成の場合、EJB クライアントからのリクエストはサーバーに割り当てられた重み付けを基に、 ラウンドロビン方式を用いることによって、ルーティングを行なうことができます。EJB クライアントとは、 Web コンテナの内部で稼動しているサーブレット、RMI/IIOP を使用したスタンドアロンの Java プロ グラム、もしくは他の EJB のことです。 重み付けラウンドロビンのポリシーは、クラスター・メンバーの重み付けの設定に基づいて割り振り が決められます。例えば、すべてのクラスター・メンバーが同じ重み付けの場合は、すべてのサー バーに対して同じ回数分リクエストが送られます。サーバーごとに重み付けが異なる場合の割り振 りのメカニズムは、重み付けがより高いサーバーへ優先的にリクエストが割り振られます。クラスタ ー・メンバーに割り当てられた重み付けを基に、ポリシーはより良い割り振りを決定します。優先的 なルーティングとして、クライアントが存在するノードにリクエストを送ることができます。この場合、そ のノード上にはただ一つのクラスター･メンバーが（重み付けラウンドロビン・メソッドを利用して）選 択されることになります。リモート・ノード上のクラスター・メンバーは、ローカル・ノードが利用できな い時のみ選択できます。 12 ４．コンテナ J2EE 1.3 の仕様では、アプリケーションの実行環境のサポートを提供するため、コンテナの概念を 定義しています。WebSphere Application Server には 2 つのコンテナがあります。 f Web コンテナ - HTTP リクエスト、サーブレット、JSP を処理します f EJB コンテナ - EJB を処理します さらに、クライアント・マシン上で動作するアプリケーション・クライアント・コンテナがあります。 表２ WebSphere Application Server V5.0.2 コンテナ・サポート Express Base ND Enterprise Web コンテナ ○ ○ ○ ○ EJB コンテナ × ○ ○ ○ × ○ ○ ○ Application Client コンテナ Web コンテナ Web コンテナはサーブレットと JSP ファイルの他に、サーバー側に存在するファイルを処理します。 個々のアプリケーションの実行環境には、変更可能な１つの論理 Web コンテナがありますが、新し く Web コンテナを作成したり削除することはできません。 f サーブレット処理： サーブレットを処理する際、Web コンテナはリクエスト・オブジェクトとレス ポンス・オブジェクトを作成した後、サーブレットの service メソッドを呼び出します。サーブレッ トをアンロードするとき、Web コンテナは、destroy メソッドを呼び出します。その後、JVM ガー ベジ・コレクションを実行します。 f 組み込み HTTP サーバー： Web コンテナは、外部の Web サーバー・プラグインや Web ブ ラウザーから HTTP(S)リクエストを処理するために、組み込み HTTP サーバーを実行します。 組み込み Web サーバーは、IBM HTTP Server に基づいた製品です。クライアントのリクエス トの処理を組み込み Web サーバーで行なうことは、テストや開発に役立ちます。Express 版 の構成の場合は、実運用に役立ちます。より高度な構成では、Web コンテナに対するフロン ト・エンドとして、外部の Web サーバーと Web サーバー・プラグインを使用することは、実運用 環境として適しています。 f セッション管理： サーブレット API 仕様の中で記述されている javax.servlet.http.HttpSession インターフェイスがサポートされています。 13 f Web サービス・エンジン： Web サービスは J2EE アプリケーションと連携して、API のセットと して提供されます。Web サービス・エンジンは SOAP をサポートします。 Web サーバー・プラグイン Web コンテナは組み込み HTTP サーバーを持っていますが、通常は外部の Web サーバーがクラ イアントのリクエストを処理します。Web サーバーは動的コンテンツではない HTML ページでリクエ ストを受け付けます。しかし、リクエストが動的コンテンツ（JSP/サーブレット）の場合は、WebSphere Application Server に転送することになります。 この処理を行なうメカニズムは、Web サーバー・プラグインの形で提供されています。プラグインは Web サーバー上にインストールしますが、WebSphere Application Server のパッケージに含まれて います。WebSphere Application Server で構成された XML 構成ファイルは、Web サーバー・プラグ インのディレクトリーにコピーされます。プラグインは構成ファイルを使って、リクエストが Web サーバ ー、または、アプリケーション・サーバーのどちらで処理するべきかを決定します。アプリケーション サーバーがリクエストを受け取った際は、アプリケーションサーバーの中で適当な Web コンテナに 転送されます。プラグインはリクエストを送信するためのプロトコルとして、HTTP あるいは HTTPS を 使用します。 EJB コンテナ EJB コンテナはインストールされたエンタープライズ Bean をデプロイし、管理するために必要なラン タイムサービスを提供します。セッション Bean およびエンティティーBean の両方のリクエストを処理 することが可能です。アプリケーション・サーバーにインストールされた Enterprise Beans（パッケー ジ化された EJB モジュール）は、直接サーバーと通信しません。その代わり、EJB コンテナは EJB と サーバー間にインターフェイスを提供します。コンテナとサーバーの両方は、Bean の実行環境を提 供します。 コンテナはスレッド・サポートとトランザクション・サポートを含む多くの low-level サービスを提供して います。管理上の見地から、コンテナは、データの保存と取り出しを管理します。単一の EJB コンテ ナは、1 つ以上の EJB JAR ファイルを扱うことができます。 クライアント・アプリケーション・コンテナ クライアント・アプリケーション・コンテナは、クライアント・マシン上でインストールされたコンポーネン ト毎にそれぞれ存在します。インストールされたコンポーネントを使用して、クライアントは EJB 互換 の J2EE 環境で、アプリケーションを実行することができます。クライアント・コンテナの実行環境と一 緒にクライアント・アプリケーションを起動するために使用されるコマンド・ライン実行可能ファイル 14 (launchClient)があります。 15 ５．アプリケーション・サーバー・サービス アプリケーション・サーバーはコンテナに加えて、他のサービスも提供しています。 表３ WebSphere Application Server V5.0.2 サービス Express Base ND Enterprise JCA サービス ○ ○ ○ ○ トランザクション・サービス × ○ ○ ○ 動的キャッシュ・サービス × ○ ○ ○ メッセージ・リスナー・サービス × ○ ○ ○ ORB サービス × ○ ○ ○ Admin サービス(JMX) ○ ○ ○ ○ 診断トレース・サービス ○ ○ ○ ○ デバッグ・サービス ○ ○ ○ ○ ネーム・サービス(JNDI) ○ ○ ○ ○ × ○ ○ ○ ○ ○ ○ × × ○ パフォーマンス・モニターインター フェース(PMI)・サービス セキュリティ・サービス(JAAS と JAAS であるが Java2 セキュリティ) J2EE ではない ビジネス・プロセス・エンジン × 1. JDBC サポートの提供を含みますが、構成はできません。 JCA サービス WebSphere Application Server のエンタープライズ情報システム(EIS)に対するアクセスは、J2EE コ ネクション・アーキテクチャーに基づいています。また、J2C と呼ばれることもあります。エンタープラ イズ・アプリケーションと EIS 間の接続は、アプリケーション・サーバーに接続された EIS 提供のリソ ース・アダプターを通して行なわれます。そのアーキテクチャーには、アプリケーション・サーバーと EIS 間に存在する接続管理、トランザクション管理とセキュリティ・コントラクトが指定されています。 アプリケーション・サーバーの接続マネージャーは、接続をプールし管理します。JCA 仕様で定義 されたリソース・アダプターと JDBC 2.0 拡張仕様で定義されたデータソースを通して得られる接続 を管理できます。 Express 版の構成では、リソース・アダプターの追加はサポートしていません。JCA サポートには、 16 JDBC リソースに対する接続の処理が含まれています。その接続は WebSphere Application Server により提供されるリソース・アダプターを通して処理されます。 トランザクション・サービス WebSphere アプリケーションはトランザクションを使用して、リソースに対する複数の更新をアトミック 単位 (個別の作業単位) として調整できますが、すべての更新が永続的であるか、永続的な更新 が行われないかのいずれかになります。トランザクションは、アプリケーション、またはそれがデプロ イされるコンテナーによって、開始、終了します。 WebSphere Application Server は、XAResource インターフェースを介してリソース・マネージャーの 調整をサポートするトランザクション・マネージャーであり、また、その他の OTS 1.2 準拠トランザク ション・マネージャー (例えば、J2EE 1.3 アプリケーション・サーバー) とともに、分散グローバル・ト ランザクションの中で稼動するトランザクション・マネージャーであるといえます。 WebSphere アプリケーションは、分散トランザクションの調整が必要でない場合には、そのローカ ル・トランザクション・サポートを介して、データベース、JMS キューおよび JCA コネクターと対話する ように構成することもできます。 アプリケーションがトランザクションを使用する方法は、以下のように、アプリケーション・コンポーネ ントのタイプによって異なります。 f セッション Bean は、コンテナ管理トランザクション (CMT: Container-Managed Transactions この場合、Bean はコンテナにトランザクションの管理を代行させる) または Bean 管理トラン ザクション (BMT: Bean-Managed Transactions この場合、Bean は自らトランザクションを管 理する) のいずれかを使用できます。 f エンティティ Bean は、コンテナ管理トランザクションを使用します。 f Web コンポーネント (サーブレット) は、Bean 管理トランザクションを使用します。 WebSphere Application Server は、3 つの主要なコンポーネントでトランザクションを処理します。 f トランザクション・マネージャー。 リカバリー可能な XAResource の登録をサポートし、これ ら各リソースが、トランザクションの終了時、またはアプリケーション・サーバーの障害発生時 の再始動後に、確実に一貫性のある結果を出すようにします。 f J2EE アプリケーションを実行するコンテナー。 コンテナーは、アプリケーションがトランザク ションのリソース・マネージャー (例えばデータベース) に対する更新を実行するとき、アプリ ケーションに代わって XAResource の登録を管理します。コンテナーは、オプションで、コン テナー管理トランザクション用に構成された Enterprise Bean のトランザクション境界を制御 17 できます。 f Bean 管理エンタープライズ Bean およびサーブレットに使用可能なアプリケーション・プログラ ミング・インターフェース (UserTransaction)。 これにより、上記のアプリケーション・コンポー ネントは、自身のトランザクション境界を制御できるようになります。 動的キャッシング 動的キャッシュ・サービスはサーブレット、コマンドおよび Java Server Pages (JSP)ファイルの出力の ためのキャッシングであり、パフォーマンスを改善します。動的キャッシュはアプリケーション・サー バーの Java 仮想マシン(JVM) 内で稼動し、キャッシュ可能なオブジェクトに対する呼び出しをイン ターセプトします。例えば、サーブレットの service() メソッドやコマンドの execute() メソッドを通じ て呼び出しをインターセプトし、動的キャッシュへオブジェクトの出力を格納したり、そこからオブジ ェクトのコンテンツを提供したりします。 J2EE アプリケーションは、read-write の割合が高く、データの流れのわずかな遅延は黙認できるの で、動的キャッシュによって、サーバーのレスポンス・タイム、スループットやスケーラビリティの向上 をもたらします。 次のキャッシング・フィーチャーは、WebSphere Application Server で使用できます。 f キャッシュの複製 クラスター・メンバー間のキャッシュの複製は、WebSphere 内部の複製サービスを使用して行 なわれます。データの生成は 1 回で、生成したデータをクラスター内の他のサーバーにコピ ー、つまり複製しますので、実行時間とリソースを節約することができます。 f キャッシュ・ディスク・オフロード デフォルトでは、キャッシュ・エントリーの数が、指定された WebSphere サーバーの構成の限 度に達すると、新しいエントリーをキャッシュ・サービスに入れるためにキャッシュ・エントリー の除去が行われます。動的キャッシュには、ディスク・オフロードという名前の代替フィーチャ ーがあります。このフィーチャーは、今後アクセスされることを想定して、除去されたキャッシ ュ・エントリーをディスクにコピーします。 f Edge Side Includes キャッシング Web サーバー・プラグインには、内蔵の ESI プロセッサーがあります。ESI プロセッサーは、よ り高いヒット率を提供するフラグメントのような全体のページをキャッシュできます。ESI プロセ ッサーにより実装されたキャッシュは、メモリ・キャッシュで、ディスク・キャッシュではありませ ん。したがって、キャッシュ・エントリーは、Web サーバーが再起動したときには保存されませ ん。 f 外部キャッシュ 18 動的キャッシュは、IBM Edge Server、分散プラットフォームの高速応答キャッシュ・アクセラレ ーター (FRCA) キャッシュ用 IBM HTTP Server、および分散プラットフォーム・プラグインの ESI Fragment Processor 用 WebSphere HTTP Server などのアプリケーション・サーバーの 外側でキャッシュを制御することができます。外部キャッシュ・グループを定義すると、動的キ ャッシュは外部キャッシュ可能なキャッシュ・エントリーをこれらのグループと突き合わせ、キャ ッシュ・エントリーと無効化をこれらのグループに対してプッシュします。これにより、 WebSphere Application Server は、アプリケーション・サーバー上の動的コンテンツを管理す ることができます。これで、コンテンツをアプリケーション・サーバーではなく外部キャッシュか ら提供できるようになり、パフォーマンスが改善されます。 メッセージ・リスナー・サービス メッセージ・リスナー・サービスは JMS プロバイダーの JMS 機能の拡張です。それは、一つかそれ以 上の JMS リスナーを制御、モニターするリスナー管理を提供します。個々のリスナーはデプロイされ たメッセージ・ドリブン bean に代わって JMS 宛先をモニターします。 オブジェクト・リクエスト・ブローカー(ORB)・サービス オブジェクト・リクエスト・ブローカー (ORB) は、 Internet InterORB Protocol (IIOP) を使用して、ク ライアントとサーバー間の対話を管理します。 ORB によって、クライアントはネットワーク分散環境 でサーバーに対してリクエストを行ない、応答を受け取ることができます。 ORB は、クライアントがネットワーク内のオブジェクトを探し出し、そのオブジェクトに対して操作を 呼び出すためのフレームワークを提供します。その場合、リモート・オブジェクトについては、場所を 意識する必要がなく、クライアントと同じ実行プロセス内にあるかのように扱うことができます。クライ アントは、スタブと呼ばれるローカル・オブジェクトに対する操作を呼び出します。その後、スタブは 要求を目的のリモート・オブジェクトに転送し、リモート・オブジェクト上で操作が実行されて、結果が クライアントに戻されます。 クライアント・サイドの ORB の役割は、操作と必須パラメーターを含む IIOP 要求を作成し、ネットワ ークに要求を送信することです。サーバー・サイドの ORB は、IIOP 要求を受信し、ターゲット・オブ ジェクトを探し出し、要求された操作を起動し、結果をクライアントに戻します。クライアント・サイドの ORB は、戻された結果を整理して、その結果をスタブに渡します。続いて、操作がローカルに実行 された場合と同様に、結果はクライアント・アプリケーションに戻されます。 WebSphere Application Server は、製品のコンポーネント間の通信のように、クライアント・アプリケ 19 ーションとサーバー・アプリケーション間の通信を管理するために ORB を使用します。 ネーム・サービス 個々のアプリケーション・サーバーは、Java Naming and Directory Interface(JNDI)ネーム・スペース を提供するネーム・サービスを提供します。そのサービスはアプリケーション・サーバーによって提 供されるリソースを登録するために使用されます。WebSphere Application Server V5 の JNDI 実装 は、Common Object Request Broker Architecture (CORBA)のネーム・サービス(CosNaming)に基 づいています。 JNDI はネーミングのためのクライアント・サイドのアクセスを提供し、アプリケーション開発者によっ て使用されるプログラミング・モデルを提供します。CosNaming はサーバー・サイドの実装と実際に ネームスペースが保存される場所を提供します。本来、JNDI は CosNaming に保存されたネーム・ スペースのクライアント・サイド・ラッパーを提供し、クライアントの代わりに CosNaming とやり取りをし ます。 ネーミング・アーキテクチャーは、WebSphere Application Server アプリケーションのクライアントが、 Enterprise Java Beans (EJB) ホームなどの、アプリケーションに関連したオブジェクトへの参照を取 得するために使用されます。 これらのオブジェクトは、ほとんどが、ネーム・スペース と呼ばれる階 層構造の中にバインドされます。ネーム・スペース構造は、名前バインディング のセットから構成さ れ、それぞれが特定のコンテキストに関連した名前と、その名前にバインドされたオブジェクトで構 成されています。ネーム・スペースは、ネーム・サーバー を介してアクセスおよび操作することがで きます。 次は、WebSphere Application Server V5 ネーム・スペースのフィーチャーです f ネーム・スペースの分散 スケーラビリティーを向上させるため、セルのスペースがさまざまなサーバー間で分散されて います。各サーバーにはネーム・サーバーがあります。前リリース（V4）では、管理ドメイン全 体でネーム・サーバーは 1 つしかありませんでした。 V5 以前の WebSphere Application Server では、すべてのサーバーが同じデフォルトの初期 コンテキストを共用し、そのすべてが同じ初期コンテキストに関連してバインドされていました。 WebSphere Application Server V5 では、サーバーのデフォルトの初期コンテキストは、その サーバー・ルートになっています。 EJB ホームおよびリソースなどのシステム生成物は、関 連付けられたサーバーのサーバー・ルートにバインドされます。 f 一時区画および永続区画 ネーム・スペースは、一時域と永続域に区分されます。サーバー・ルートは一時域です。 20 EJB ホームおよびリソースなどのシステムにバインドされた生成物は、サーバー・ルートの下 にバインドされます。セル・スコープの永続バインディングに使用できるセル永続ルート、およ びオブジェクトへのノード・スコープのバインディングに使用できるノード永続ルートがありま す f システム・ネーム・スペース構造 セル全体のネーム・スペースは、セル内のすべてのサーバー間で統合されています。各サ ーバー・プロセスには、ネーム・サーバーがあります。すべてのネーム・サーバーは、セル・ネ ーム・スペースの同じ論理ビューを提供します。ネーム・スペースのさまざまなサーバー・ル ートと永続区画は、システム・ネーム・スペースという手段により相互に接続されます。システ ム・ネーム・スペース構造を使用して、セルのネーム・スペース内の任意のコンテキストをす べて探索することができます。 f 構成済みバインディング 構成用のグラフィカル・インターフェースおよびスクリプト・インターフェースを使用して、ネー ム・スペース内のさまざまなルート・コンテキスト内のバインディングを構成できます。これらの バインディングは読み取り専用であり、サーバーの始動時にシステムによりバインドされます 。 f CORBA Interoperable Naming Service (INS) オブジェクト URL のサポート WebSphere Application Server V5 では、Common Object Request Broker Architecture (CORBA) オブジェクト URL (corbaloc および corbname) が、Java Naming and Directory Interface (JNDI) プロバイダー URL およびルックアップ名としてサポートされています。 図７は、ネーミング・アーキテクチャーとそのコンポーネントを総括したものです。 21 図７ ネーミング・トポロジー PMI サービス WebSphere Application Server は、Performance Monitoring Infrastructure (PMI) を使用してランタ イムおよびアプリケーションに関するデータを収集します。このインフラストラクチャーは、JSR-077 仕様と互換性があり、拡張されています。 PMI はクライアント/サーバー・アーキテクチャーを使用しています。サーバーは、種々の WebSphere Application Server のコンポーネントからパフォーマンス・データを収集し、メモリに保存 します。このデータはサーブレット応答時間やデータベース接続プール使用率のようなカウンター から構成されています。そのデータは Web クライアント、Java クライアントと JMX クライアントを使用 して検索できます。WebSphere Application Server は、パフォーマンス・データを表示し、モニター する Java クライアントである Tivoli Performance Viewer を同梱しています。 IBM WebSphere Application Server は、リクエストが製品のコンポーネントを介して伝達される際に、 タイミングを指定してデータ収集を行なうこともできます。PMI リクエスト・メトリックスにより、Web サ ーバー、Web コンテナ、エンタープライズ Bean コンテナ、およびデータベースといった主要なコン ポーネントで消費される時間をログに記録します。これらのデータ・ポイントは、ログに記録され、 22 Tivoli モニター・ツールが使用するアプリケーション応答時間 (ARM) エージェントに書き込むこと ができます。 PMI サービスは管理コンソールを使用して、アプリケーション・サーバーやノード・エージェントのた めに利用できます。収集できるデータのタイプとレベルは、管理コンソール（または、wsadmin）や Tivoli Performance Viewer を通して制御できます。 セキュリティ・サービス それぞれのアプリケーション・サーバーの JVM は、認証と権限の機能を提供する構成リポジトリの中 に保持されるセキュリティ設定を使用するセキュリティ・サービスを提供します。 管理サービス 管理サービスはそれぞれのサーバーの JVM 内で稼動します。BASE 版の構成では、管理サービス はアプリケーション・サーバーの中で稼動します。ネットワーク・デプロイメントとエンタープライズ構 成では、次のように管理サービスを提供します。 f デプロイメント・マネージャー f ノード・エージェント f アプリケーション・サーバー f JMS サーバー 管理サービスはサーバーとそのコンポーネントのための構成データを操作するために必要な機能 を提供しています。その構成はサーバーのファイル・システムのリポジトリに保存されます。 管理サービスにはセキュリティ制御とフィルタ機能があります。次の管理ロールを使用するユーザ ーやグループを確認するため、違ったレベルの管理を提供します。 f 管理者 f モニター f コンフィギュレーター f オペレーター エンタープライズ・サービス WebSphere Application Server のアーキテクチャーは、新たなアプリケーション・サーバー・サービス が容易に開発でき、既存のサーバー・アーキテクチャーに組み込まれることができるように設計され ています。プログラミング・モデルの拡張は、ベースのアプリケーション・サーバーにインストールさ 23 れたサービスの実装の拡張です。 ここで、疑問が湧いてきます。 WebSphere エンタープライズ版で提供されるサービスは、どうすれば使用できますか？ Web コンテナー、EJB コンテナー、組み込み HTTP サーバーのようなアプリケーション・サーバーに よって提供されるベースのサービスについて考えてください。これらのサービスは特定の API（例え ば、サーブレット API、EJB API）を使用することでアクセスされるか、あるいは、サービスがデプロイ されたコードとコンテンツ（たとえば、HTML ファイル）と直接やり取りをするかです。 WebSphere エンタープライズ版のサービスは、同じ方法で稼動します。図 8 はエンタープライズ・ア プリケーションがエンタープライズ・サービスにどのようにアクセスするかをまとめたものです。 図8 アプリケーション・サーバー・サービスの使用 いくつかのサービスには、提供された API でアクセスできます。たとえば、スケジューラー・サービス、 国際化対応(I18N)サービスと作業域サービスです。Last Participant サポートのようなサービスは、 裏方として稼動し、デプロイメント・ディスクリプターやその記述子の拡張部分を使用します。動的照 会サービスのような他のサービスは、他のアプリケーションへのサービスに対するアクセスを提供す る特別なエンタープライズ・アプリケーションを必要とします。 次の表は拡張のリストとそれらに対する提供されたアクセスのメソッドです。 表４ WebSphere エンタープライズの PME アクセス 24 拡張 Process Choreographer 拡張メッセージング 非同期 Bean デプロイメント・ディスク API アクセス リプタ 特殊な EAR ○（アプリケーション自 ○（クライアント） 体が特殊な EAR） ○（Studio のウィザード で提供） ○ アプリケーション・プロ ファイル/アクセス・イン ○ テント Business Rule Beans ○ ○ 動的照会 ○ ○ 始動 Bean ○ スケジューラー・サービス ○ ActivitySession ○ Last Participant サポ ○ ート オブジェクト・プール ○ 作業域 ○ 国際化(I18N)対応サ ービス CORBA サポート ○ ○ 25 ６．ビジネス・プロセス・エンジン 表５ WebSphere Application server ビジネス・プロセス・エンジン・サポート ビジネス・プロセ ス・エンジン Express Base ND Enterprize × × × ○ Enterprise 版の構成では、短時間、長時間のビジネス・プロセスの処理をサポートする 「ビジネス・ プロセス・エンジン」 と呼ばれるエンジンを使用します。このエンジンは、実際は、特殊なエンター プライズ・アプリケーションであり、アプリケーション・サーバーのコンテナではなく、「ビジネス・プロ セス・コンテナー」 とも呼ばれることがあります。 管理プロセスはユーザーからの詳細情報を隠蔽するので、実際には、個別のコンテナのように稼 動します。 WebSphere Studio Integrated 版で開発されたビジネス・プロセス・アプリケーションは、エンタープラ イズ・アプリケーションとしてデプロイされることがあります。エンタープライズ管理プロセスはこれら のアプリケーションが、ビジネス・プロセス・コンテナにデプロイされることを保証しています。 ビジネス・プロセス・コンテナー・アプリケーションは、そのアプリケーションが開始するときにロードさ れる最初のエンタープライズ・アプリケーションです。クラスローダーは他のアプリケーションがロー ドされる前に、他のエンタープライズ・アプリケーション・モジュールを察知してビジネス・プロセス・ア プリケーションをロードします。 ビジネス・プロセス・アプリケーションは、通常３つのモジュールをもっています。 f プロセス・フローを実装する EJB モジュール f プロセスに対するユーザー・インターフェースを提供する Web クライアント f アプリケーションに実装されたフロー記述を含んだフロー・アーカイブ・ファイル（.far）。このフ ロー記述は、.fdml フォーマットで保存されます。このモジュールは、WebSphere Studio により 自動的に生成され、パッケージ・ファイルとしてルートの EAR モジュール下に保存されます。 ビジネス・プロセス・エンジンは、プロセス・テンプレート、インスタンスや状態を永続化するためにデ ータベースを必要とします。データベースはデータソースとして登録され、WebSphere でサポートさ れるデータベース・タイプである必要があります。 ビジネス・プロセス・コンテナの複数のインスタンスは、シングル・ノードまたはクラスターの分散環境 26 で並列に稼動します。そのインスタンスは、IIOP リクエストのための WebSphere Application Server のクラスタリング環境と JMS ベースのリクエストのための WebSphere MQ のクラスタリング環境で利用 できます。ビジネス・プロセス・データベースは集中ステート・リポジトリとして使用することができま す。 27 ７．仮想ホスト 仮想ホストは 1 台のマシンをあたかも複数台のマシンが存在するかのように構成することです。これ により、物理的に 1 台のマシンで個々に構成され管理されたいくらかのアプリケーションをサポート することができます。これは特定のノードに関連したことではありません。各仮想ホストには、論理的 な名前と、１つまたは複数の DNS エイリアスのリストがあります。DNS エイリアスとは TCP/IP ホスト名 とポート番号の組み合わせで、クライアントからサーブレットがリクエストされるときに使われます （例：ホスト名:80）。サーブレットがリクエストされると、そのリクエストにマッチする仮想ホストを探し、 その仮想ホストにサーブレットを処理させるため、リクエスト中のサーバー名とポート番号は仮想ホ スト内のすべてのエイリアスのリストと照合されます。もし、一致するものが見つからないときは、ブラ ウザーに 404 エラーを返します。 IBM WebSphere Application Server は、２つのデフォルトの仮想ホストを提供しています。 f default_host ほとんどのアプリケーションにアクセスするために使用されます。Express 版を除くすべての エディションには、default_host へのリクエストはポート番号８０、９４４３、９０８０が設定されてい ます。Express 版では、default_host のポート番号として８０、７４４３、７０８０が設定されていま す。 例 http://localhost:80/servlet/snoop http://localhost:9080/servlet/snoop f admin_host WebSphere Application Server V5 での管理コンソールにアクセスするための仮想ホストです。 他のアプリケーションはこの仮想ホストを通してのアクセスはできません。Express 版を除くす べてのエディションでは、admin_host へのリクエストはポート番号９０９０、９０４３が設定されて います。Express 版では default_host のポート番号として７０９０、７０４３が設定されています。 28 ８．セッション管理 ユーザーは多くの Web アプリケーションの中で、データを動的に収集します。つまり、ユーザーが 訪れたページに関しては、ユーザーは一連の選択の流れに沿ってサイトを移動しています。ユー ザーが次に行こうとする場所、ユーザーが次に開こうとする（次に選択する）ページのように、アプリ ケーションが表示するページは、そのユーザーがそのサイトで以前に開いたページに依存してい ます。このユーザーのデータを維持するために、アプリケーションは、そのデータを「セッション」に 保存します。 WebSphere はセッションを追跡するために、３つのアプローチをサポートしています。 f SSL(Secure Sockets Layer) SSL セッション情報は、HTTP セッション ID を追跡するために使用されます f Cookies アプリケーション・サーバーのセッション・サポートは、個々のユーザーに対してユニークな ID を割り振ります。そして、この ID を、Cookie を使用してユーザーのブラウザに返します。セッ ション管理 Cookie のデフォルトの名前は、JSESSIONID です。セッション管理の最も一般的な 方法として、Cookie を使用します。 f URL 再書き込み セッション・データは、ローカル・メモリ・キャッシュに保存され、外部のデータベースに保存さ れ、またはメモリ上に保存され、かつ複数アプリケーション・サーバー間で複製できます。 表６はそれぞれの WebSphere Application Server 構成でセッション・サポートを表示したものです。 表６ WebSphere Application Server V5.0.2 セッション管理サポート Express Base ND Enterprise Cookies ○ ○ ○ ○ URL 再書き込み ○ ○ ○ ○ SSL ○ ○ ○ ○ メモリキャッシュ ○ ○ ○ ○ × ○ ○ ○ × × ○ ○ データベース使用 セッション管理 Memory-to-Memory 複製 サーブレット 2.3 の仕様は、Web アプリケーション・レベルでセッションのスコープを定義しています。 29 セッション情報にアクセスできるのは、単一の Web アプリケーションのみです。 しかし、情報を共有する複数の Web アプリケーションのためには、論理的な判断を要することが何 度もあります。例えば、ユーザー名のように。WebSphere V5.0 は、エンタープライズ・アプリケーショ ン内にセッション情報を Web アプリケーション間で共有することができる IBM 拡張をサポートしてい ます。このオプションはアプリケーション・デプロイメント・ディスクリプターの拡張として提供されてい ます。このオプションはアプリケーション・アセンブリ時に登録されます。 セッション・パーシスタンス 多くの Web アプリケーションは、最もシンプルなセッション管理として、メモリ上に保存するローカ ル・セッション・キャッシュを採用しています。ローカル・セッション・キャッシュはセッション情報を最 初に作成したローカル・マシン（WebSphere Application Server）上のメモリに保持します。ローカル なセッション管理は、クラスター化された他のマシンに存在するユーザーのセッション情報を共有し ません。Web クライアントからのアクセスを、セッション情報を保持している WebSphere Application Server が再び処理を行なえば、その Web クライアントだけがセッション情報を取得することができま す。 最も重要なことは、ローカルなセッション管理は永続的にセッション情報を保持することができない ということです。サーバーの障害が原因で、今まで保持していたセッション情報を無くしてしまうこと があります。 WebSphere はデフォルトでセッション・オブジェクトをメモリ上に保存します。しかし、WebSphere Base 版、Network Deployment 版と Enterprise 版には、管理者が永続的なセッション管理を可能に するオプション設定があります。このことは、WebSpere でセッション・オブジェクトを永続的に保存で きることを示しています。クラスター環境下でのセッション管理として、WebSphere の計画的な shutdown や障害時に別サーバー経由でサービスを続行させる事が可能です。セッション・パーシ スタンスには、2 種類のオプションがあります。 f データベース 複数サーバー環境で、セッション情報をデータベースに書き込むことによって、永続的な保 存が可能になります。特定のアプリケーションが稼動している複数アプリケーション・サーバ ーは、セッション状態を保持するために、このデータベース情報を共有する必要があります。 f メモリー間複製 WebSphere はデータベースを使用しないで、セッション情報をアプリケーション・サーバー間 で共有することが可能です。この方法を使用して、セッション・パーシスタンスのためのデー タベースと同じ機能を提供し、アプリケーション・サーバーのメモリに保存します。２つのトポロ ジー・オプションが提供されています。 30 Peer-to-Peer トポロジー： 個々のアプリケーション・サーバーは、セッション情報をそれぞれのサーバーのメモリに保存します。 あるクラスター・メンバー上で生成されたセッション情報は、他のクラスター・メンバーにも複製されま す。結果として、全クラスター・メンバーが、同じセッション情報のコピーを持ち合うことになります。 Client/Server トポロジー： アプリケーション・サーバーは、複製クライアントまたはサーバーのどちらかの機能を持ちます。サ ーバーの機能を持つと、セッション情報をサーバー上のメモリに保存し、クライアントにセッション情 報を提供します。セッション情報を保管専用サーバーにのみ複製しておくことになります。クライア ント・アプリケーション・サーバーは、複製サーバーにセッション情報を送信した後、サーバーからセ ッションを読み込みます。 内部のメッセージング・システムは、組み込み WebSphere JMS プロバイダー、または、JMS サーバ ーと関係がありません。必要なコードは WebSphere Application Server ライブラリーのコアの一部と して提供されています。 31 ９．Web サービス Web サービスはネットワークを介して記述、公開、配置、および実行をすることができる内蔵タイプ のモジュラー・アプリケーションです。 WebSphere Application server は Web サービスのプロバイダ ーとしての役割りの他に、リクエスターとしての役割をもっています。プロバイダーとしては、クライア ントによってユーザーに対して公開される Web サービスを提供します。リクエスターとしては、他の ロケーションから Web サービスを組み込むアプリケーションを提供します。 WebSphere Application Server は SOAP ベースの Web サービスのホスティングと呼び出しをサポー トします。 表７ WebSphere Application Server V5.0.2 サーバー・サポート Express Base ND Enterprise ベース Web サービス・サポート ○ ○ ○ ○ プライベート UDDI レジストリ × × ○ ○ Web サービス・ゲートウェイ × × ○ ○ エンタープライズ Web サービス ○ ○ ○ ○ JCA Web サービス × × × ○ Web サービス国際化 × × × ○ Web サービス・サポートには以下のものがあります。 f Web Service Description Language (WSDL) は、サービスをカタログ化し、記述する XML ベ ースの記述言語です。WSDL では Web サービスのインターフェース(パラメーターと結果)、バ インディング(SOAP、EJB)と実装の配置を記述します。 f Universal Discovery Description and Integration (UDDI)は、グローバルでプラットフォーム独 立のオープン・フレームワークにより、企業間で相互に必要なビジネスを発見し、それを定義 し、グローバル・ディレクトリの中で情報を共有できるようになっています。 f Simple Object Access Protocol (SOAP)は、集中化されていない分散環境で情報を交換でき る軽量プロトコルです。 f eXtensible Markup Language (XML)は、情報を交換するための共通言語を提供します。 f Web Services Invocation Framework(WSIF)は、Web サービス呼び出しのためのバインディン グに依存しないメカニズムを提供するサービス指向のアプリケーションのためのランタイム・ア ーキテクチャーです。WSIF は Web サービスとして、J2EE コネクター・アーキテクチャー（JCA ）を通して接続されるバックエンド・システムの隠蔽を容易に行なうことができます。 32 f JAX-RPC(JSR １０１)は、Java プラットホーム上で、コアとなるプログラミング・モデルと Web サ ービスの開発とデプロイのバインディングを提供します。それは、XML ベースの RPC 用 Java API であり、Web サービス・プロバイダーとして JavaBeans のみをサポートしています。 f エンタープライズ Web サービス(JSR １０９): これは、JSR １０１に EJB と XML デプロイメント・ ディスクリプターを加えたものです。 f WS-Security： この仕様は、統一性と機密性を提供するために、セキュアな Web サービスを 構築するときに使用される SOAP の標準セットの拡張仕様をカバーしています。WS-Security は、PKI と Kerberos を含む他のセキュリティ・モジュールに対してオープンな設計になってい ます。それには、セキュリティ・トークンの伝播、メッセージの完全性とメッセージの機密性が 含まれます。この仕様は、IBM、マイクロソフトとベリサインにより提案されました。将来、この 仕様は IBM のセキュリティ・トークンと暗号化文書と同様に、SOAP セキュリティ拡張（ SOAP-SEC）、マイクロソフトの WS-Security と WS-License をもつ IBM とマイクロソフトからの 既存の Web サービス・セキュリティの仕様を置き換えることになるでしょう。 エンタープライズ・サービス(JCA Web サービス) エンタープライズ・サービスは、プラットホーム-中立および言語-中立の環境の中でアプリケーショ ンにインターネット上のアクセスを提供します。エンタープライズ・サービスは、エンタープライズ情 報システム(EIS)とメッセージ・キューに対するアクセスを提供し、インターネット外のクライアント/サ ーバー環境で使用されます。エンタープライズ・サービスは、多様なプラットフォームおよび多様な フォーマットでアプリケーションやデータにアクセスします。 エンタープライズ・サービスは、共通のサービス・インターフェースでソフトウェア・コンポーネントをラ ップします。ソフトウェア・コンポーネントは、典型的に、EIS にとっての Java クラス、EJB あるいは JCA リソース・アダプターです。サービス用語では、このソフトウェア・コンポーネントは、実装として知ら れています。エンタープライズ・サービスは、主にサービスとしての実装を外の世界で使用できるよ うに WSDL と WSIF を使用しています。 WebSphere Studio Integration版を使用して、Javaコネクター・アーキテクチャー(JCA)を使用する CICSとIMSトランザクションをWebサービスに変更することができます。 Web サービス・クライアント(リクエスター) Web サービスを呼び出すアプリケーションは、Web サービス・クライアントまたは Web サービス・リク エスターとして知られています。Web サービス・クライアントとして使われるアプリケーションは、他の エンタープライズ・アプリケーションのように、WebSphere Application Server にデプロイされます。 Web サービス・クライアントが稼動するために、特別な追加の構成やソフトウェアは必要ありません。 Web サービス・クライアントは、スタンドアローン・アプリケーションとしても機能します。Web サービ 33 ス・クライアントは、Web サービスを呼び出すために Web サービス・サーバーにバインドします。その バインディングは、Web サービスに対して WSDL に基づいて生成されるサービス・プロキシ（すなわ ち、スタブ）を使用することで行なわれます。サービス・プロキシには、Web サービスを呼び出すた めに必要な情報がすべてあります。また、ビジネス・サービスにアクセスするクライアントによってロ ーカルに使用されることがあります。そのバインディングは、WSIF を使用して動的に行なわれること があります。 Web サービス・プロバイダー Web サービスとして使用されるアプリケーションは、他のエンタープライズ・アプリケーションのように WebSphere Application Server にデプロイされます。Web サービスは Web モジュール、または EJB モジュールに含まれます。UDDI レジストリに対して Web サービスを公開することは、誰かがそれを 探し求めることができることです。Web サービスを、WebSphere Studio Application Developer 版、 Integration 版、Enterprise Developer 版の構成で提供される Web サービス・エクスプローラーを使 用して、UDDI レジストリに公開することができます。アプリケーションをデプロイ用にパッケージ化す るために、WebSphere Studio V5 を使用すると、Web サービス・クライアントが機能するために必要と なる追加の構成やソフトウェアは必要ではなくなります。SOAP サーブレットは自動的に追加され、 SOAP 管理ツールは Web モジュールの中にあります。もしそうでないとしたら、EAR ファイルの中で SOAP サービスを可能にするために、WebSphere の bin ディレクトリの中の soapearenabler.bat を使 用する必要があります。 エンタープライズ Web サービス JSR １０９仕様要求に基づいたエンタープライズ Web サービスは、一般的な J2EE サーバー内の Web サービスの実装とデプロイと同じように、ランタイム・アーキテクチャーを定義している J2EE 環 境で、JAX-RPC を使用できるようにしています。その仕様には、JSR ６７、９３、１０１と将来の Web サ ービスの標準に関連した JSR に基づいた Java の中で、Web サービスの実装のためのプログラミン グ・モデルとアーキテクチャーを定義しています。 以下のサイトにJSRのリストがあります。 http://www.jcp.org/en/jsr/all IBM WebSphere UDDI レジストリ WebSphere Application Server V５は、UDDI 仕様の V２.０を実装するプライベート UDDI レジストリ を提供しています。これにより、その企業は社内にある Web サービス・ブローカーを実行し、社外へ ブローカー・サービスを提供できます。UDDI レジストリは、１つのアプリケーション・サーバー(または クラスター)上で、管理者によって Web アプリケーションとしてインストールされます。DB２データベ ースを使用して、レジストリ・データを保管します。テスト環境では、Cloudscape を使用することがで 34 きます。問い合わせと公開のためのレジストリには３つのインターフェースがあります。 f UDDI SOAP API f UDDI EJB クライアント・インターフェース f UDDI ユーザー・コンソール。この Web ベースの GUI インターフェースは、UDDI エントリーに ついての公開と問い合わせに使用されますが、UDDI API 機能のサブセットも提供していま す。 UDDI レジストリのセキュリティは、WebSphere のセキュリティを使用して処理されます。IBM WebSphere UDDI レジストリとともに、セキュアなアクセスをサポートするために、HTTP と SSL を使 用する WebSphere を構成する必要があります。 Web サービス・ゲートウェイ Web サービス・ゲートウェイにより、インターネット、イントラネットを問わず社内外の Web サービスを 利用できるようになります。 ゲートウェイはデプロイと呼び出しに対して、WSDL（Web services Definition Language）と WSIF(Web Services Invocation Framework)に基づいて作られています。 Web サービス・ゲートウェイのおもな機能は、他の Web サービスに対してゲートウェイによって提供 される新しいサービスに既存の WSDL で定義された Web サービスをマップすることです。ゲートウ ェイには、プロキシの役割もあります。外部のサービスは、ゲートウェイに取り込まれ、内部のプロキ シ・サービスとして、企業で利用できます。同じように、内部のサービスはゲートウェイに取り込まれ、 外部のプロキシ・サービスとして利用できます。これらのサービスは、また、必要で適切な UDDI レ ジストリに公開されます。Web サービス・ゲートウェイは、管理者によって Web アプリケーションとして インストールされます。 Ｗｅｂサービスを外部の世界に広める 外部の利用者が企業内部のサービスを使用できるように、ゲートウェイは既存のサービス用の WSDL ファイルを受け取り、外部のリクエスターと共有できる新しい WSDL ファイルを生成します。 WSDL で記述されたインターフェースは、サービス・クライアントのための公式なエンド・ポイントであ るものとまったく同じです（しかし、サービスのエンド・ポイントはゲートウェイに対して変化します）。 特定のユーザーや特定のサービスの手法に対するアクセスを制限するために、特別なセキュリティ 制約を適用することができます。このシナリオは、図 9 に示します。 35 図9 Web サービス・ゲートウェイ Web サービスの取り込み 外部サービスを取り込んで、内部サービスとして利用できます。これにより、内部サービスのリクエス ターはそのサービスがゲートウェイ上で稼動していれば、それを呼び込むことができます。 また、新しい WSDL は同じインターフェースを示すゲートウェイによって生成されます。ゲートウェイ は直ちにオリジナルな WSDL で指定される実際の実装に対するすべてのリクエストを転送します。 もちろん、あらゆるクライアントは伝統的な方法で外部の Web サービスにアクセスできます。しかし、 中間に別の層としてゲートウェイを追加して、それをサービス実装業者が変更した場合、クライアン トは何の変更も必要なくアクセスができます。このシナリオは、図 9 のイラストによく似ています。違い としては、クライアントがイントラネットの中に存在し、Web サービスの実装がインターネット上のサイ トに位置付けられていることです。 チャネル管理 あるサービスに対するリクエストは、一つのプロトコルで行なわれることがありますが、そのサービス は、変換機能によって、他のいくつかのプロトコルで呼出される可能性があります。内部サービスは JMS 上の SOAP で利用できますが、HTTP 上の SOAP を利用して呼出されるべきです。ゲートウェ イがターゲットとなる Web サービスを呼出すアウトバウンド・チャネルは、ゲートウェイに取り込まれた WSDL の中でのバインディングにより、暗黙に定義され、明確に構成さることはありません。取り込ま れた WSDL バインディングの中で定義されたものに対して、違うインバウンド・チャネルを使用する 36 ことで、プロトコルを切り替えることができます。 フィルター管理 Web サービスのために、１つかそれ以上のフィルターを開発して使用することができます。いくつか の特定のタスクは、Web サービスへ（または、から）の入力（または、出力）メッセージを使用して行 なわれます。独自のフィルターを作ることはできますが、標準のフィルターもあります。 37 １０．セキュリティー IBM WebSphere Application Server のセキュリティー機能は、OS や Java が提供するセキュリティー 機能の上位層として提供されます。 f WebSphere の重要な構成情報ファイルは OS のセキュリティー機能によって保護されます。 また、ユーザー認証の際に、OS のユーザー・レジストリーを使用することも可能です。 f WebSphere と WebSphere が提供するセキュリティー関連のクラスは JVM（Java 仮想マシン） の下で稼動します。この JVM が Java 標準セキュリティーを提供します。 f Java 2 セキュリティー API は、コードが存在する場所と誰が署名したのかという情報に基づ いてアクセス制御を強化する方法を提供します。Java 2 セキュリティーは、ファイルやソケット やプロパティーといったシステム資源に対するアクセスを保護します。Java 2 セキュリティー は WebSphere の「グローバル・セキュリティー」の設定画面から有効化または無効化すること ができます。グローバル・セキュリティーを有効化した場合、デフォルトでは自動的に Java 2 セキュリティーも有効化されます。ただし、グローバル・セキュリティーが有効・無効に関わら ず Java 2 セキュリティーを有効化・無効化することも可能です。 Java 2 セキュリティーにおける許可チェックでは、実行中のスレッドの現行 Principal が考慮 されていません。とはいえコード・ベースと署名者ではなく Principal に基づいて許可を行ない たい場合も存在します。Java Authentication and Authorization Service(JAAS)によってこの問 題が解決します。JAAS は、Java 2 セキュリティーにおける許可チェックを、コード・ベースおよ び署名者だけでなく、Principal に対するコード・ベースまで拡張できるようにサポートする標 準 Java API です。 JAAS は Java 2 SDK v1.3 の標準拡張機能であり、Java 2 SDK v1.4 に含まれています。 JAAS のプログラミング・モデルを使用すれば、アプリケーション認証をプラグイン可能な形 で設計することができます。つまり、利用する認証技術にとらわれないアプリケーションを作 成することが可能になります。なお JAAS を利用する際、Jave 2 Security を有効にしておく必 要はありません。 f CSI (Common Secure Interoperability) プロトコルはさらに追加のセキュリティー機能を提供 します。CSI プロトコルによって CORBA 環境下での相互認証が可能になります。CSI プロトコ ルは EJB2.0 仕様とインターオペラビリティーがあり SSL を使用することも可能です。 f J2EE セキュリティーはセキュリティー・コラボレーターを使用して J2EE ベースのセキュリティ ー・ポリシーを実施し J2EE セキュリティーAPI をサポートします。API はセキュリティー・メカニ ズムにアクセスしセキュリティー・ポリシーを実装するために WebSphere アプリケーションから アクセスされます。J2EE セキュリティーは、アプリケーション開発者が定義した役割に基づき、 サーブレット/JSP といった Web リソースや EJB に対するアクセスを保護します。アプリケーシ ョンをディプロイする際に、ユーザーやグループがそれらの役割に割り当てられます。 38 f IBM Java Secure Socket Extension (JSSE)は WebSphere Application Server で使用されてい るセキュアー・ソケット・レイヤー(SSL)の実装です。JSSE は Java パッケージのセットで成り立っ ており、セキュアーなインターネット通信を可能にします。JSSE は SSL と TLS(トランスポート・ レイヤー・セキュリティー)プロトコルを Java で実装したもので、データ暗号化・サーバー認証・ メッセージ一貫性・クライアント認証の機能を含んでいます。 WebSphere Application Server V5 セキュリティーは、上述したレイヤーの上に成り立っており、これ らのレイヤーの機能を強化します。WebSphere Application Server V5 セキュリティーは、Web と EJB の両リソースについて統一された方法でセキュリティー・ポリシーを実装しています。 WebSphere Application Server の各エディションが提供するセキュリティー機能の比較を表 8 に示 します。 表 8 WebSphere Application Server V5.0.2 セキュリティー・サポート Express Base ND Enterprise Java 2 NO YES YES YES J2EE (役割マッピ YES YES YES YES JAAS YES YES YES YES CSIv2 NO YES YES YES 認証メカニズム LTPA, SWAM LTPA, SWAP LTPA LTPA ユーザー・レジス ローカル OS, ローカル OS, ローカル OS, ローカル OS, トリー LDAP, カスタム・ LDAP, カスタム・ LDAP, カスタム・ LDAP, カスタム・ レジストリー レジストリー レジストリー レジストリー ング) 図 10 は WebSphere Application Server V5.0 のセキュリティー・アーキテクチャーを示しています。 要件や利用可能な技術に応じてモジュールを交換可能であるという柔軟性がある点がこのアーキ テクチャーの利点となっています。 39 NT/UNIX ﾕｰｻ ﾞｰ ﾚｼﾞｽﾄﾘｰ ｶｽﾀﾑ ﾕｰｻ ﾞｰ ﾚｼﾞｽﾄﾘｰ LDAP ﾕｰｻ ﾞｰ ﾚｼﾞｽﾄﾘｰ ﾌﾟ ﾗｸﾞｲﾝ 可能 な ﾕｰｻ ﾞｰ・ﾚｼﾞｽ ﾄﾘｰ SW AM LTP A ﾌﾟ ﾗｸﾞｲﾝ 可能 な 認証 他ﾍﾞﾝﾀﾞｰ の ORB WebSphere Application Server CSIv2 CSIv2 J AAS Tivoli Acces s Manager ﾌﾟ ﾗｸﾞｲﾝ 可能 な 許可 z/OS IBM 図 10 IBM WebSphere V5 拡張可能セキュリティー・アーキテクチャー ユーザー・レジストリー ユーザー・レジストリーはプラグインが可能な仕組みになっているので、認証や許可で使用するユ ーザーID とパスワードは様々なデータベースに保管しておくことができます。その方法には以下の ３つがあります。 f ローカル OS のユーザー・レジストリー この場合、WebSphere Application Server は OS のユーザーとパスワードを認証に使用しま す。 f LDAP ユーザー・レジストリー この LDAP ユーザー・レジストリーは大規模な Web システムに最も適した方法として推奨され ています。市場にでている LDAP サーバーのほとんどは、WebSphere Application Server と セキュアな通信ができるだけのセキュリティー・メカニズムを備えています。システム管理者は、 豊富なサーチ・パラメータをセットすることにより LDAP サーバーを WebSphere Application Server に適合させることが可能です。 f カスタム・ユーザー・レジストリー この方法により、独自の実装が施されたユーザー・レジストリーを WebSphere Application 40 Server のユーザー・レジストリーとして利用することが可能になります。WebSphere Application Server には UserRegistry という名前の Java インターフェースを提供しています 。この Java インターフェースを実装する形で、独自ユーザー・レジストリーにアクセスする Java クラスを開発する必要があります。ユーザー・レジストリーがリレーショナル・データベースや フラット・ファイルなどであっても、この Java インターフェースを使用しておけば WebSphere Application Server からアクセスが可能になります。 なお、一時点でアクティブにできるユーザー・レジストリーは一つだけです。 認証 認証とは、与えられたコンテキストの中でクライアントが有効かどうかを立証するプロセスのことです。 ここでいうクライアントとは、ユーザーの場合もありますし、マシンまたはアプリケーションの場合もあ ります。プラグイン可能な認証メカニズムにより、WebSphere Application Server にユーザーを認証 させるのか、外部の認証メカニズムから送られてくる信任状を受け取るのかを選択することができま す。 WebSphere Application Server の認証メカニズムは、認証を行う際、ユーザー・レジストリーと密接 に連携します。認証メカニズムの責任は信任状を作成することです。信任状とは、認証されたユー ザーを表す WebSphere Application Server 内での内部表現です。ただし、すべての信任状が同じ 形で作成されるわけではありません。どの認証メカニズムを採用するかによって信任状が持つ機能 は異なります。 WebSphere Application Server は複数の認証メカニズムを提供していますが、アクティブな認証メ カニズムとして構成できるのは一時点で一つだけです。アクティブな認証メカニズムは、WebSphere Application Server のグローバル・セキュリティーを設定する際に選択します。 WebSphere Application Server は認証メカニズムとして、SWAM (Simple WebSphere Authentication Mechanism) と LTPA (Lightweight Third Party Authentication) の２つを提供してい ます。これら２つのメカニズムは分散セキュリティー機能の面で異なるものになっています。 f SWAM (Simple WebSphere Authentication Mechanism) SWAM は、単純な非分散の単一アプリケーション・サーバー・タイプのランタイム環境向けの ものです。この単一のアプリケーション・サーバーの制約事項は、 SWAM が転送可能な 信 任状をサポートしていないことによるものです。アプリケーション・サーバー・プロセス 1 内の サーブレットまたは Enterprise Bean が、別のアプリケーション・サーバー・プロセス 2 で動 41 作中の Enterprise Bean 上のリモート・メソッドを呼び出す場合、プロセス 1 内の呼び出し 元識別の ID はサーバー・プロセス 2 に伝送されません。非認証信任状が伝送されること になり、これは、 EJB メソッドで構成されているセキュリティー許可によっては、許可障害の 原因となる場合があります。 SWAM は、単一のアプリケーション・サーバー・プロセス用であるため、シングル・サインオン (SSO) はサポートされていません。 SWAM 認証メカニズムは、単純な環境、ソフトウェア開発環境、または分散されたセキュリテ ィー・ソリューションが必要でないその他の環境に適しています。 SWAM はセッション ID に依存しており、LTPA ほどセキュアではありません。したがって SWAM を使用する際は SSL と共に使用することが推奨されます。 f LTPA (Lightweight Third Party Authentication) LTPA は、分散環境と複数アプリケーション・サーバーおよびマシンの環境を対象としていま す。これは、転送可能な信任状およびシングル・サインオン (SSO) をサポートしています。 LTPA は、分散環境のセキュリティーを暗号化によりサポートすることができます。これにより、 LTPA は、認証関連のデータを暗号化し、ディジタル署名して安全に伝送し、後で署名を暗 号化解除して検査することができます。 LTPA を使用する場合、ユーザー・レジストリーとしては、LDAP や Windows ドメインのレジスト リーなどのように集中管理されたリポジトリーを使用しなければなりません。 許可 プラグイン可能な許可インターフェースにり、WebSphere アプケーションにおいて異なる許可メカニ ズムを使用することが可能です。現行バージョンでは JAAS がサポートされており、Tivoli Access Manager は外部の許可システムとなります。 WebSphere Application Server の標準許可メカニズムは、J2EE セキュリティー仕様と Java Authentication and Authorization Services (JAAS)に基づいています。 f J2EE セキュリティー・アーキテクチャーでは、アプリケーション内で誰がコードを実行できるの かを指定する、というセキュリティー・ポリシーを採用しています。コードの署名、署名者 ID、ソ ース・サーバーといったコード特性によってコードの実行許可が与えられるかどうかが決まり ます。 f JAAS では上記のアプローチをさらに拡張し、役割ベースのアクセス制御が加わっています。 コードの実行許可は、コード特性だけでなく誰がそれを実行しようとしているのかによって決 まります。JAAS プログラミング・モデルにより開発者はアプリケーションの認証をプラグイン可 能な形で開発することができます。これによりアプリケーションを基盤となる認証技術から独 立させることが可能です。 42 認証された個々のユーザーに対して Subject が１つ作られます。Subject には、そのユーザーを識 別するために Principal のセットが含まれます。 セキュリティー・コンポーネント 図 11 に WebSphere におけるアプリケーション・セキュリティーに関連するコンポーネントの概要を示 します。 AppServer1 Webコンテナ WebServer HTTP(S) ｾｷｭﾘﾃｨｰ ﾌﾟﾗｸﾞｲﾝ AppServer2 ｾｷｭﾘﾃｨｰ・ｺﾗﾎﾞﾚｰﾀｰ authenticate() mapCredential() ﾕｰｻﾞｰID/ﾊﾟｽﾜｰﾄﾞ or ｸﾗｲｱﾝﾄ証明書 ﾘｸｴｽﾄ ｾｷｭﾘﾃｨｰ・ﾄｰｸﾝ or Density Assertion CSIv2 EJBコンテナ ｾｷｭﾘﾃｨｰ・ｺﾗﾎﾞﾚｰﾀｰ ｾｷｭﾘﾃｨｰ・ｻｰﾊﾞｰ ｾｷｭﾘﾃｨｰ・ｻｰﾊﾞｰ EJBコンテナ JAAS ｸﾗｲｱﾝﾄ validate() CSIv2 ｾｷｭﾘﾃｨｰ・ｺﾗﾎﾞﾚｰﾀｰ JAAS ｻﾌﾞｼﾞｪｸﾄ 保護ﾄﾞﾒｲﾝ ﾕｰｻﾞｰ ﾚｼﾞｽﾄﾘｰ ｾｷｭﾘﾃｨｰ・ ﾏﾈｰｼﾞｬｰ/ Policy ｱｸｾｽ・ Permissions ｺﾝﾄﾛｰﾗ ﾉｰﾄﾞ・ｴｰｼﾞｪﾝﾄ ｾｷｭﾘﾃｨｰ・ｻｰﾊﾞｰ Java2ﾌﾟﾗｯﾄﾌｫｰﾑ 図 11 WebSphere アプリケーション・セキュリティー・コンポーネント セキュリティー・サーバー セキュリティー・サーバーは WebSphere Application Server のコンポーネントの一つで、個々のアプ リケーション・サーバー・プロセスの中で稼動します。もし１つのノード内でアプリケーション・サーバ ーのインスタンスが複数稼動している場合、１つのノード内に複数のセキュリティー・サーバーが存 在することになります。セキュリティー・サーバーの責任は、認証を管理すること、許可エンジンやユ ーザー・レジストリーと協調することです。 セキュリティー・コラボレーター セキュリティー・コラボレーターは、ディプロイメント・ディスクリプターで指定されたセキュリティー制 43 約を実行する責任をもったアプリケーション・サーバーのプロセスです。認証や許可のアクションが 必要な時は毎回セキュリティー・サーバーとコミュニケーションします。以下の２つのセキュリティー・ コラボレーターが存在します。 f Web セキュリティー・コラボレーター Web セキュリティー・コラボレーターは Web コンテナに存在し、以下のサービスをアプリケー ションに提供します。 認証のチェック ディプロイメント・ディスクリプターに指定された制約に基づいた許可 セキュリティー・トーレス情報のロギング f EJB セキュリティー・コラボレーター EJB セキュリティー・コラボレーターは EJB コンテナに存在します。EJB セキュリティー・コラボ レーターは、EJB に対する Java クライアントのリクエストを認証するために CSIv2 と SAS を使 用します。EJB セキュリティー・コラボレーターはセキュリティー・サーバーと協調して以下の 機能を実行します。 指定されたセキュリティー制約に基づいた許可のチェック ローカル・ユーザー・レジストリーとのコミュニケーションのサポート セキュリティー・トーレス情報のロギング リモート Bean に対する要求があった場合、CSIv2 を使用して外部の ORB とコミュニケー ションする セキュリティー・フロー 以下に一般的なセキュリティー・フローの概要を示します。 Web ブラウザー・コミュニケーション Web ブラウザーがアプリケーション・サーバーにリクエストを送った場合のセキュリティーの観点から みたコンポーネント間のやり取りのステップを以下に示します。 1. Web ユーザーは WebSphere Application Server によって保護された Web リソースをリクエスト します。 2. Web サーバーはリクエストを受け取り、要求されたリソースがアプケーション・サーバー上に存 在することを認識し、WebSphere プラグインを通じてリクエストをアプリケーション・サーバーに転 送します。 3. WebSphere プラグインはユーザー信任状を Web セキュリティー・コラボレーターに渡し、Web セ キュリティー・コラボレーターがユーザー認証を実施します。 4. 認証が成功すると Web リクエストが Web コンテナに届きます。Web セキュリティー・コラボレータ ーはユーザー信任状とディプロイメント・ディスクリプターに指定されたセキュリティー情報を許 可チェックのためにセキュリティー・サーバーに渡します。 5. 後続のリクエストについては、ユーザーが何を要求しているのかに応じて Web セキュリティー・ 44 コラボレーターまたは EJB セキュリティー・コラボレーターが許可チェックを行います。ユーザー 信任状は既に確立しているセキュリティー・コンテキストから取り出されます。 管理タスク 管理タスクは管理コンソール、もしくは wsadmin ツールで実行されます。以下に管理タスクのがどの ように実行されるのかを示します。 1. 管理クライアントはサーバー側 ORB と JMX MBean にアクセスするリクエストを生成します。 JMX MBean は管理リソースを表しています。 2. JMX MBean は認証のためにセキュリティー・サーバーにアクセスします。JMX MBean は専用 の役割を持っており、認証や許可チェックのためにユーザー・レジストリーにアクセスすることは ありません。 Java クライアント・コミュニケーション Java クライントと WebSphere アプリケーションとのやり取りを以下に示します。 1. Java クライアントはサーバー側 ORB にアクセスするリクエストを生成します。 2. CSIv2 または IBM SAS インターセプターが ORB に成り代わってサーバー側での認証を行い、 セキュリティー・コンテキストをセットします。 3. サーバー側 ORB はリクエストを EJB コンテナに渡します。 4. EJB コンテナは、リクエストをアクセス保護された EJB メソッドに送った後に、リクエストを EJB セ キュリティー・コラボレーターに渡します。 5. EJB セキュリティー・コラボレーターは.ear ファイルからディプロイメント・ディスクリプターを読み 取り、セキュリティー・コンテキストからユーザー信任状を取り出します。 6. 信任状とセキュリティー情報がセキュリティー・サーバーに渡されます。セキュリティー・サーバ ーはユーザー・アクセス権をチェックし、その情報を EJB セキュリティー・コラボレーターに戻し ます。 7. セキュリティー・サーバーから応答を受け取った後に、EJB セキュリティー・コラボレーターは要 求されたリソースに対するアクセスをユーザーに対して許可または否認します。 45 １１．リソース・プロバイダー リソース・プロバイダーでは、J2EE アプリケーションの稼動に必要なリソースを定義します。表９には、 WebSphere Application Server の構成でサポートしているリソース・プロバイダーの一覧を示しま す。 表９ WebSphere Application Server V5.0.2 リソース・プロバイダーのサポート一覧 Expreｓｓ Base ND Enterprise JDBC ○ ○ ○ ○ JavaMail ○ ○ ○ ○ JMS プロバイダー × ○ ○ ○ リソース環境プロバイダー × ○ ○ ○ URL プロバイダー × ○ ○ ○ リソース・アダプター × ○ ○ ○ JDBC リソース データソースはリレーショナル・データベースのような実世界のデータソースのことを表わします。デ ータソース・オブジェクトが JNDI ネーミング・サービスに登録されているとき、アプリケーションはサ ービスに名前を付け、それを検索することができます。そして、そのデータソースを使用して、デー タベースに接続することができます。 データソースについての情報や、データソース名、そのデータソースが存在するサーバーやポート 番号などのようなデータソースをどのように設定するかの情報は、DataSource オブジェクト上のプロ パティー・フォームの中に保存されます。これにより、ベンダー独自の名前を含むドライバー名をハ ード・コーディングしなくてすむので、アプリケーションをより汎用性の高いものにできます。また、こ れにより、コードの保守がより簡単になります。例えば、データソースを異なるサーバーへ移動した 場合でも、処理に必要なことは、データソースの中の関連したプロパティの更新ですみます。つまり、 データソースの再設定をする必要はあリますが、プログラムの変更は必要ないということです。 いったんデータソースがアプリケーション・サーバーの JNDI ネーム・スペースに登録されれば、アプ リケーション・プログラマーは、JNDI ネーム・スペースに示されるデータソースに接続するために JNDI ネームスペースを使用することができます。 コネクションは、通常コネクション・プールにあります。つまり、一度アプリケーションが接続を終了す 46 ると、コネクションを切断しないでコネクション・プールに戻します。 データ・ソース・クラスと JDBC ドライバーは、データベース・ベンダーによって実装されます。JDBC プロバイダーを構成することによって、データソースやデータベース・ドライバーを実装するために 使用される一連のクラスに関する情報を提供します。つまり、DataSource オブジェクト用の環境設 定を提供します。 WebSphere Application Server V5 には、接続がどのように処理されるかによって、２つのタイプのデ ータソースがあります。 f WebSphere V4 データソース f WebSphere V5 データソース WebSphere Version 4 データソース WebSphere V4 はコネクション・プーリングや JDBC へのアクセスを行なう JDBC コネクション・マネー ジャーを提供します。このサポートは J2EE 1.2 アプリケーション用のサポートを提供する WebSphere Application Server V5 に含まれています。あるアプリケーションが V4 のデータソースを選択すると したら、そのアプリケーションは WebSphere V4 と同じ接続をしたことになります。 図 14 Version４でのコネクション・プーリング WebSphere Version ５ データソース WebSphere Application Server V5 では、コネクション・プーリングは JCA コネクション・マネージャー と関連のリソース・アダプターの２つパートに分けて提供されています。 47 図 13 J2EE コネクター・アーキテクチャのリソース・アダプター JCA コネクション・マネージャーはコネクション・プーリング、ローカル・トランザクションとセキュリティ ーのサポートを提供しています。関連のリソース・アダプターは BMP、JDBC アプリケーションと CMP bean がデータベースにアクセスできるように JDBC ラッパーと JCA CCI 実装の両方を提供します。 JavaMail JavaMail API は、Java ベースのメール・クライアント・アプリケーションを構築するためのプラットフ ォームとプロトコルに依存しないフレームワークを提供します。これらの API が関係するプロトコル 上で稼働するメール・サーバーと対話する場合は、サービス・プロバイダー (WebSphere Application Server ではプロトコル・プロバイダー) が必要になります。 JavaMail プロバイダーはプロトコル・プロバイダー・コレクションをカプセル化します。WebSphere Application Server は３つのプロトコル（SMTP、IMAP、POP3）を提供するビルトインのメールプロバ イダーを持ってます。これらのプロトコル・プロバイダーは標準でインストールされており、ほとんど のアプリケーションにとっては十分なものです。 f SMTP メールを送信するために最も使用されている転送プロトコルです。JavaMail アプリケーション は SMTP サーバーに接続し、SMTP プロトコル・プロバイダーを使用することによってメールを 48 送信することができます。 f POP3 メール受信のための標準プロトコルです。 f IMAP メール受信のための POP3 の代替プロトコルです。 他のプロトコルを使用するためには、それらのプロトコルのための適当なサービス・プロバイダーを インストールする必要があります。 その上、JavaMail は、Multipurpose Internet Mail Extensions（MIME）、Uniform Resource Locator （URL）やファイル添付のようなプレーン・テキストではない複雑なデータタイプを取り扱うための基 礎的なフレームワークとして、JavaBeans Activation Framework（JAF）を必要とします。 JavaMail API、JAF、サービス・プロバイダーとそのプロトコルは、次のような Sun ライセンス・パッケー ジを使用する WebSphere Application Server の一部として出荷されます。 f mail.jar： JavaMail API と SMTP、IMAP、POP3 サービス・プロバイダーを含みます。 f activation.jar： JavaBeans Activation Framework を含みます。 f Application Server - Express： JavaMail V1.2 と JAF V1.0 をサポートします。 JCA リソース・アダプター J2EE コネクター・アーキテクチャー（JCA）は、J2EE プラットフォームを異機種のエンタープライズ情 報システム（EIS）へ接続するための標準的なアーキテクチャーを定義しています。例えば ERP、メイ ンフレーム・トランザクション処理 (TP)、データベース・システム、および Java プログラミング言語で 書かれていないアプリケーションがこれにあたります。 JCA リソース・アダプターは EIS ベンダーやその他のサード・パーティー・ベンダーから供給されるシ ステム・レベルのソフトウェア・ドライバーです。これは J2EE コンポーネント（アプリケーション・サーバ ーやアプリケーション・クライアント）と EIS 間の接続を提供します。 リソース・アダプターを使用するために、リソース・アダプター・コードのインストールとコネクション・フ ァクトリーの作成が必要です。 １つのリソース・アダプター（WebSphere Relational Resource Adapter）は、リレーショナル・データベ ースにアクセスするデータを処理するために、事前に定義されています。このリソース・アダプター は動的にデータベースにアクセスする JDBC コールを通してデータ・アクセスを提供します。これは、 49 コネクション・プーリング、ローカル・トランザクションおよびセキュリティ・サポートを提供します。 WebSphere パーシスタンス・マネージャーは、コンテナ管理パーシスタンス (CMP) Bean 用のデ ータをアクセスするためにこのアダプターを使用します。 URL プロバイダー java.net.URLStreamHandler と java.net.URLConnection クラスを拡張することによって、URL プロバ イダーは、HTTP といった特定の URL プロトコルのための機能を実装しています。これによりアプリ ケーションと特定のプロトコルによって供給される URL リソースの間の通信を可能にします。 Default URL Provider という名前の URL プロバイダーはデフォルトで WebSphere の構成に含まれ ています。このプロバイダーは、IBM JDK によって提供される URL サポートを利用します。HTTP 、 FTP やファイルのような Java 2 Standard Edition 1.3.1 に基づいたプロトコルを持つ URL リソース は、デフォルトの URL プロバイダーを使用することができます。 JDK によってサポートされていない他のプロトコルを実装する URL プロバイダーにプラグインするこ ともできます。 JMS プロバイダー WebSphere で提供される JMS 機能には、３つのタイプの JMS プロバイダーがあります。 f WebSphere JMS プロバイダー（組み込みメッセージング） f WebSphere MQ JMS プロバイダー f 一般 JMS プロバイダー １ノードに１つ以上の JMS プロバイダーがあります。すなわち、１つのノード上で WebSphere JMS プ ロバイダー、WebSphere MQ JMS プロバイダー、一般 JMS プロバイダーのうち、どのような組合せ （またはすべて）でも同時に構成できます。 JMS サーバー・プロセス（組み込み WebSphere JMS Provider）は、１ノードに１つのみです。しかし、 同じマシン上に WebSphere JMS プロバイダーと WebSphere MQ を同時にインストールすることは可 能です。この場合、JMS クライアント・クラス（MA88）と MQ トランスポート・コード（binaries）の１コピー のみになります。このため、両者はバージョンとパッチ・レベルを同じにしておく必要があります。 それぞれ異なる JMS プロバイダーの構成のために、WebSphere 管理ツールが提供されています。 表１０はサポートを要約したものです。 50 表１０ JMS プロバイダーのための WebSphere 管理サポート WebSphere WebSphere JMS MQ Provider JMS Provider ×※ ×※ Initial context factory、URLプロバイダー メッセージング・システム・オブジェクト ○ × （queues/topics） JMS管理オブジェクト （JMSコネクション・ファクトリー、 ○ ○ JMSディスティネーション） ※この設定はWebSphere管理コンソールでは現れません 一般 JMS Provider ○ × × WebSphere JMS プロバイダー（組み込みメッセージング） 組み込みメッセージングは WebSphere Application Server のインストール・オプションとして提供さ れています。組み込みメッセージングは point-to-point と publish/subscribe 機能を提供していま す。 WebSphere JMS プロバイダーと呼ばれるこのサポートは下記 IBM 製品から構成されています。 f WebSphere MQ f WebSphere MQ MA88 SupportPac™ − JMS クライアント・クラス f publish/subscribe サービスを提供する WebSphere Event Broker の early-release これらはそれぞれ単体で稼動する製品と比べると、機能が限られています。 WebSphere JMS プロバイダーは J2EE 1.3 仕様をサポートしています。 f JMS 1.0.2 仕様のサポート f JMS サーバー1.0 実装の提供 f J2EE1.3 compliance テストをすべてクリアしています。 WebSphere JMS プロバイダーは下記をサポートしていません。 f JMS API で定義されていない API f WebSphere MQ キュー・マネージャーとの相互運用 セキュリティーは、WebSphere 管理ツールを使用して構成されるユーザーとグループのアクセス権 とともに WebSphere セキュリティー・システムと統合されています。 JMS サーバーはブローカーを提供したり、外部の WebSphere MQ のキューやトピックの作成、管理 と削除を含めた WebSphere MQ プロセスを管理します。 51 すべての JMS クライアント・アクセスは、WebSphere MQ クライアント（TCP/IP）モードを用いて実行 されます。 WebSphere MQ JMS プロバイダー WebSphere Application Server V5 では JMS プロバイダーとして WebSphere MQ をサポートしてい ます。この製品は WebSphere MQ がキュー・ベースのメッセージング・システムを提供している間は、 JMS クライアント・クラスと管理インターフェースを提供する WebSphere 製品と密接に統合されてい ます。 一般 JMS プロバイダー WebSphere Application Server V5 は、JMS1.0.2 仕様の ASF コンポーネントを実装する場合と同じ 期間、一般 JMS プロバイダーをサポートします。一般 JMS プロバイダーの JMS リソースは WebSphere 管理ツールを使用して構成することはできません。 リソース環境プロバイダー java:comp/env 環境は、JNDI ネーム・スペース・オブジェクトとローカル・アプリケーション環境オブ ジェクトを lookup できる単一のメカニズムを提供します。WebSphere Application Server はデフォル トで多くのローカル環境エントリーを提供しています。 J2EE 1.3 仕様では、アプリケーションの標準的なデプロイメント・ディスクリプターで定義された <resource-env-ref>エントリーを使用したカスタム（デフォルトではない）環境エントリーを定義する ために、あるメカニズムも提供しています。J2EE 仕様では、次の項目によって、アプリケーションか らのリソース環境エントリーの定義を分けています。 リソース環境エントリーをカプセル化する別々の管理オブジェクトを定義するメカニズムを提供する ために、アプリケーション・サーバーを必要とします。管理オブジェクトはアプリケーション・サーバー のローカル・ネーム・スペース（java:comp/env）の JNDI 経由でアクセスすることができます。 管理オブジェクトの JNDI ルックアップ・ネームと<resource-env-ref>内に戻されるオブジェクト・タイ プを指定します。 WebSphere Application Server は、次のような管理オブジェクトを提供することによって、 <resource-env-ref>のメカニズムをサポートします。 f リソース環境プロバイダー referenceable、リソース環境エントリーの管理オブジェクトと必要とされるカスタム・プロパティ ーをグループ化する管理オブジェクトを定義します。 52 f Referenceable Java インターフェースを実装するためのオブジェクト・インスタンスを返すファクトリー・クラスの クラス名を定義します。 f リソース環境エントリー バインディング・ターゲット（JNDI 名）、ファクトリー・クラスとリソース環境エントリーの return の オブジェクト・タイプを定義します。 53 １２．管理 IBM WebSphere Application Server V5 は JMX フレームワークを基盤とする新しい管理モデルを提 供します。JMX はハードウェアと Java ベースのソフトウェア・リソースを１つにまとめて分散環境に提 供します。また、JMX は既存のプロトコル（例えば SNMP）を JMX 自体の管理構造の中に統合する ためにマッピング・フレームワークを提供します。 各アプリケーション・サーバーは、管理サービスを備えています。管理サービスとは、サーバーとコ ンポーネントの構成データを操作するために必要な機能を提供します。構成情報はリポジトリーに 保存されます。リポジトリーは、サーバーのファイル・システムに保存された XML のファイル・セット になっています。 管理ツール 表 11 に WebSphere Application Server が提供する管理ツールを示します。 表 11 WebSphere Application Server V5.0.2 管理ツール Express Base ND Enterprise 管理コンソール ○ ○ ○ ○ コマンド ○ ○ ○ ○ Wsadmin 含みますが、推 ○ ○ ○ 奨しません。 管理コンソール 管理コンソールは構成と操作機能を提供する Web ブラウザ・ベースのインターフェースです。管理 コンソールはアプリケーション・サーバーにインストールされているエンタープライズ・アプリケーショ ン(adminconsole.ear)で実装されます。管理者は、Web ブラウザ・クライアントを使用してアプリケー ションに接続します。 異なる管理者ロールを割り当てられたユーザーは、このインターフェイスを利用してアプリケーショ ンサーバー、コンポーネントとサービスを管理することができます。管理コンソール自体がアプリケ ーションですので、管理コンソールを使用する前にサーバーとアプリケーションの両方を開始して おく必要があります。 Express 版と Base 版の構成では、adminiconsole アプリケーションが server1 上にインストールされ 54 ています。新規にサーバーを追加した場合、server1 上の管理コンソール・アプリケーションを使用 して構成することはできますが、いかなるランタイム機能も持ちません。それぞれの server 上に adminconsole.ear アプリケーションをインストールすれば、サーバーは完全な管理機能を持つこと になります。 Network Deployment 版と Enterprise 版では、adminconsole アプリケーションはインストールされて いて、デプロイメント・マネージャー上で稼動します。セルにノードを追加すると、adminconsole アプ リケーションはノードから削除され、構成ファイルはデプロイメント・マネージャーによってマスター・ セル・リポジトリにまとめられます。 コマンド WebSphere Application Server は、管理機能のサブセットを実行できるように<server_install>/bin デ ィレクトリの中に一連のコマンドを提供しています。 例えば、startServer コマンドを使用すると、アプリケーション・サーバーが起動します。 wsadmin スクリプト wsadmin スクリプトはコマンドライン・インターフェースを利用した管理形態です。Web ベースの管理 アプリケーションを超えた柔軟性があります。wsadmin を使用すれば素早く管理できるだけでなく、 スクリプトを使用する複数のアプリケーション・サーバーと複数のノードの管理を自動化することがで きます。 このツールは、Bean Scripting Framework (BSF) を使用します。BSF は WebSphere Application Server インストール・システムを構成および制御するさまざまなスクリプト言語をサポートしていま す。 wsadmin スクリプトはすべての WebSphere Application Server 構成に含まれますが、高度なスキルを 持ったユーザー向けです。wsadmin を使用する場合、アプリケーション・サーバー・アーキテクチャ ーとスクリプトをよく知っている必要があります。 構成リポジトリー 構成リポジトリーは個々のコンポーネントの構成ドキュメントのコピーを保持しています。WebSphere Application Server V5 以前のバージョンでは、構成情報をリレーショナル・データベースに保存して いましたが、V5 では、すべての構成情報は XML ファイルに保存されます。アプリケーション・サー バーの管理サービスは、構成を確認した後、稼動中に矛盾がないことを確認します。 55 集中管理 Network Deployment 版と Enterprise 版は、集中的に複数サーバーとノードを管理することが可能 です。集中管理にデプロイメント・マネージャーを使用して、更新された構成情報をそれぞれのノー ドに存在するノード・エージェントに配布します。そして、ノード・エージェントはノードに存在するサ ーバーに構成情報を維持する役割をします。 表 12 WebSphere Application Server V5.0.2 集中管理サポート デプロイメントマ ネージャー ノードエージェン ト Express Base ND Enterprise × × ○ ○ × × ○ ○ 管理プロセス WebSphere 製品のコンポーネントであるすべてのオペレーティング・システムのプロセスは、 「managed servers」 または 「managed processes」 と呼ばれます。JMX サポートはすべての managed processes に組み込まれています。これらのプロセスは管理コマンドを受信し、プロセス内 の管理リソースの状態に関する管理情報を出力することが可能です。 WebSphere は以下の managed server/processes を提供します： f デプロイメント・マネージャー すべての構成情報へのアクセスとセルの制御をするために、シングル・ポイントを提供します。 デプロイメント・マネージャーは、システム内の各ノード上のノード・エージェント・プロセスと通 信を行ないます。 f ノード・エージェント ノード上のすべての WebSphere managed processes を集めて制御します。１ノードに 1 ノード ・エージェントが存在します。 f アプリケーション・サーバー J2EE アプリケーションを提供する Managed server です。 f JMS サーバー ノードに組み込みメッセージング・サービスを提供する Managed server です。1 ノードに 1JMS サーバーが存在します。デフォルト構成では、JMS サーバーの機能はアプリケーション・サー バー・プロセス内で提供されます。 56 デプロイメント・マネージャー デプロイメント・マネージャーのプロセスは、セル内のすべての要素を集中管理することができ、 Web ベースの管理コンソール・アプリケーションを提供します。セル内のいくつかの managed 管理 リソースにアクセスするために必要な管理ツールは、通常は集中管理を実現するデプロイメント・マ ネージャーに接続します。 デプロイメント・マネージャーは、それぞれのノード上のリポジトリー（構成とアプリケーション・バイナ リー）の内容を管理し、ノード上のノード・エージェント・プロセスと通信することによってこれを管理 します。 デプロイメント・マネージャーを使用することで、水平クラスター、垂直クラスターと分散アプリケーシ ョンの管理と構成が容易になります。アプリケーション・サーバーがノードに管理されるように、１つ かそれ以上のノードはセルに管理されます。 ノード・エージェント ノード・エージェントは管理プロセスの一つで、機能を供給しているアプリケーションの中には含ま れません。ノード・エージェントは下記のような重要な管理機能を提供します。 f ファイル転送サービス f 構成情報の同期化 f パフォーマンス・モニター ノード・エージェントは次のような項目と通信することで、ノード上のすべての managed processes を 集めて管理します。 f 構成情報の同期を取り、管理オペレーションを調整するデプロイメント・マネージャー f 各サーバーの(start/stop)を管理し、構成情報やアプリケーション・バイナリーを更新するた めのアプリケーション・サーバー 各ノード上に１つのノード・エージェントのみを定義（そして実行）できます。Express 版と Base 版の インストレーションには、ノード・エージェントはありません。 マスター構成リポジトリー Network Deployment 版と Enterprise 版にはマスター構成リポジトリーがあり、そこにデプロイメント・ マネージャーによって、すべてのセルの構成データが保存されます。各ノードの構成リポジトリーは マスターリポジトリーのサブセットと同期をとります。ノード・リポジトリーは、アプリケーション・サーバ ーからのアクセスは読み取り専用で、セル・マスター構成リポジトリーから更新要求が出された場合、 57 デプロイメント・マネージャーのみがノード・リポジトリーの更新を行うことができます。 58 １３．アプリケーションのフロー 図 14 はアプリケーション・データベースにアクセスするために、JDBC (サーブレットから)、あるいは、 EJB のどちらかを使用する Web ブラウザー・クライアントのための標準的なアプリケーション・フロー を示しています。 図 14 アプリケーション・フロー １．Web クライアントがブラウザー (入力ページ)から、URL をリクエストします。 ２．そのリクエストはインターネット上の Web サーバーにルートされます。 ３．Web サーバーは直接 WebSphere プラグインにリクエストを渡します。すべてのリクエストは最初 に WebSphere プラグインを通ります。 ４．WebSphere プラグインは URL をテストし、仮想ホスト情報に基づいたトラフィックを受け付けるホ スト名のエイリアスのリストを確認し、リクエストを処理するサーバーを選択します。 ５．ストリームが作られます。ストリームは Web コンテナーに対する接続です。それは多くのリクエスト に対して接続 (ストリーム) を保持します。Web コンテナーはリクエストを受け取り、URL に基づい てリクエストを適当なサーブレットにディスパッチします。 ６．サーブレット・クラスがロードされない場合、動的クラス・ローダーがサーブレットをロードします (サーブレット、 init()、次に doGet()、doPost())。 ７．JNDI は、サーブレットが必要とするデータソースや EJB をルックアップするために使われます。 ８．データソースが指定されるか、または、EJB がリクエストされるかにより、JNDI はサーブレットに指 59 示を与えます。 ａ．データソースの場合、データベースと接続するため、接続プールから接続を獲得します。 ｂ．EJB コンテナと接続する場合、EJB がリクエストされた時点で EJB をインスタンス化します。 ９．リクエストされた EJB は、SQL トランザクションを呼出した場合、データソースをルックアップする ために JNDI へ戻ります。 １０．SQL ステートメントが実行され、検索されたデータが戻されます。 ａ．サーブレットへ ｂ．EJB へ １１．EJB の場合、データ Bean が作られ、JSP へ渡されます。 １２．サーブレットはデータを JSP へ送ります。 １３．JSP は WebSphere プラグインを通して、Web サーバーへ戻される HTML を生成します。 １４．Web サーバーは出力ページ(出力 output)をブラウザーへ送ります。 60 １４．アプリケーションの開発とデプロイ 図 15 開発とデプロイ アプリケーション設計 Rational Rose または、Rational XDE のようなデザイン・ツールは、Unified Modeling Language (UML) を使用したアプリケーションをモデル化するために使用されます。モデリングの出力は、一 般的に、ユース・ケース・シナリオ、クラス・ダイアグラムとモデルに基づいて生成されるスターター・ コードから構成されます。 アプリケーション開発 アプリケーション開発はエンタープライズ・アプリケーションを作成するために、WebSphere Studio (または、互換性のある IDE) を使用して行ないます。エンタープライズ・アプリケーションを作成す るための WebSphere Application Server 構成として、最も役に立つ WebSphere Studio の構成を使 用してください。 Rational Rose、サンプル・アプリケーションと既存の本番用アプリケーションのように、すでに生成さ れたコードを取り込んで始めることも、ゼロから始めることもできます。 WebSphere Studio は、多くのツールを持ち、素早く開始できるようになっています。WebSphere Studio は、CVS や Rational ClearCase をサポートしていますので、複数の開発者がソース・コードの シングル・マスター・コピーを共有できます。 61 開発フェーズの間、コンポーネント・テストは組み込みの WebSphere Application Server テスト環境 を使用して行なうことができます。WebSphere Studio には、テスト環境とリモート・サーバー上でサー バーを作成して管理することができるサーバー・ツールがあります。アプリケーションは WebSphere Studio を使用したサーバー上で実行するとき、デプロイメント用に EAR ファイルに自動的にパッケ ージングされます。 アプリケーションのパッケージ化 J2EE 1.3 アプリケーションは１つまたはそれ以上のアプリケーション・サーバーにデプロイされる Enterprise Application Archives (EAR) ファイルにパッケージングされます。J2EE 1.3 アプリケーシ ョンは、表 13 に示されるモジュールの一部かまたはすべてに含まれまれています。 表 13 J2EE 1.3 アプリケーション・モジュール モジュール ファイル名 内容 Web モジュール <module>.war サーブレット、JSP ファイル、関連コード EJB モジュール <module>.jar エンタープライズ beans と関連コード アプリケーション・クライア <module>.jar アプリケーション・クライアント・コード <module>.rar アプリケーションが Enterprise Information ント・モジュール リソース・アダプター・モジ ュール System(EIS)に接続するために使用するライブラ リ・実装コード このパッケージングは、デプロイメント用のアプリケーションをエクスポートするとき、WebSphere Studio の中で自動的に行なわれます。他の IDE を使用している場合のために、WebSphere Application Server では、アプリケーションのパッケージング用に Application Assembly Tool (AAT) を提供しています。 アプリケーションのデプロイ アプリケーションは管理コンソール、または、wsadmin スクリプティング・インターフェースを使用して アプリケーション・サーバー上でデプロイできます。アプリケーションはシングル・サーバー、または、 クラスター上にデプロイできます。クラスター構成の場合は、クラスター内のそれぞれのアプリケー ション・サーバー上にインストールされます。 アプリケーションのインストールは次のようになります。 f 実際のリソース参照のバインディング。たとえば、データソースは実際のデータベースにバイ 62 ンドされている必要があります。 f EJB ホーム・オブジェクトのための JNDI 名の定義 f エンティティ beans のためのデータソース・エントリーの指定 f 実際の EJB JNDI 名に対する EJB 参照のバインディング f 仮想ホストに対する Web モジュールのマッピング f メッセージ・ドリブン beans のためのリスナー・ポートの指定 f アプリケーション・サーバーに対するアプリケーション・モジュールのマッピング f ユーザー、または、グループに対するセキュリティ・ロールのマッピング 新しいアプリケーションがデプロイされた後、Web サーバー・プラグイン構成ファイルを再構成し、 Web サーバーにコピーする必要があります。 63