Document 1026186

3 サーバー管理・基本設定 ......................................................................................................... 3
3-1 管理コンソール ..................................................................................................................... 3
3-1-1 起動手順 ........................................................................................................................... 4
3-1-2 ログイン･ユーザー ............................................................................................................ 5
3-1-2-1 ログインの競合 .............................................................................................................. 5
3-1-2-2 前の変更を回復............................................................................................................. 6
3-1-3 使用方法および説明 ........................................................................................................ 7
3-1-3-1 起動画面 ........................................................................................................................ 7
3-1-3-2 メニュー .......................................................................................................................... 8
3-1-3-3 管理コンソールの使用例 ............................................................................................ 15
3-2 サーバー管理 ..................................................................................................................... 16
3-2-1 デプロイメント・マネージャーの管理............................................................................... 16
3-2-1-1 デプロイメント・マネージャーの起動 ........................................................................... 16
3-2-1-2 デプロイメント・マネージャーの停止 ........................................................................... 18
3-2-1-3 デプロイメント・マネージャーの使用ポートの確認 ..................................................... 20
3-2-2 ジョブ・マネージャーの管理 ............................................................................................ 23
3-2-2-1 ジョブ・マネージャーの起動......................................................................................... 23
3-2-2-2 ジョブ・マネージャーの停止......................................................................................... 23
3-2-2-3 ジョブ・マネージャーの使用ポートの確認 .................................................................. 24
3-2-2-4 管理対象ノードを登録 ................................................................................................. 26
3-2-2-5 管理コンソールを利用したノードの確認..................................................................... 28
3-2-2-6 ジョブの登録 ................................................................................................................ 30
3-2-2-7 ジョブの実行結果の確認 ............................................................................................ 33
3-2-3 管理エージェントの管理.................................................................................................. 35
3-2-3-1 管理エージェントの起動 .............................................................................................. 35
3-2-3-2 管理エージェントの停止 .............................................................................................. 35
3-2-3-3 管理対象ノー ドを登録（CUI） .................................................................................... 36
3-2-3-4 管理エージェント・管理コンソール .............................................................................. 37
3-2-3-5 管理エージェントの使用ポートの確認........................................................................ 39
3-2-4 ノード・エージェントの管理 .............................................................................................. 40
3-2-4-1 ノード・エージェントの起動 .......................................................................................... 40
3-2-4-2 ノード・エージェントの停止 .......................................................................................... 42
3-2-4-3 ノード・エージェントの使用ポートの確認 .................................................................... 43
3-2-5 アプリケーション・サーバーの管理................................................................................. 44
3-2-5-1 アプリケーション・サーバーの起動 ............................................................................. 44
3-2-5-2 アプリケーション・サーバーの停止 ............................................................................. 46
3-2-5-3 アプリケーション・サーバーの作成 ............................................................................. 50
3-2-5-4 アプリケーション・サーバーの削除 ............................................................................. 53
3-2-5-5 アプリケーション・サーバーの設定 ............................................................................. 55
3-2-6 クラスターの管理............................................................................................................. 57
3-2-6-1 クラスターの起動 ......................................................................................................... 58
3-2-6-2 クラスターの停止 ......................................................................................................... 60
3-2-6-3 クラスターの作成 ......................................................................................................... 62
3-2-7 Web サーバーの管理...................................................................................................... 66
3-2-7-1 Web サーバーのローカル構成 ................................................................................... 67
-1-
3-2-7-2 IBM HTTP Server のリモート Web サーバー構成.................................................... 67
3-2-7-3 IBM HTTP Server を使用した Web サーバー構成例............................................... 68
3-2-7-4 IBM HTTP Server 以外のリモート Web サーバー構成............................................ 71
3-3 仮想ホスト ........................................................................................................................... 72
3-3-1 仮想ホスト作成................................................................................................................ 74
3-4 データベース接続設定 ....................................................................................................... 77
3-4-1 データベース接続の概説................................................................................................ 77
3-4-1-1 データベース接続設定のキーワード .......................................................................... 78
3-4-2 JDBC ドライバー.............................................................................................................. 79
3-4-3 JDBC プロバイダー設定 ................................................................................................. 80
3-4-3-1 JDBC プロバイダーの有効範囲の設定...................................................................... 80
3-4-3-2 JDBC プロバイダー作成.............................................................................................. 82
3-4-4 J2C 認証データ設定........................................................................................................ 85
3-4-5 データ・ソース設定 .......................................................................................................... 87
3-4-5-1 データ・ソースの種類................................................................................................... 87
3-4-5-2 データ・ソース作成....................................................................................................... 87
3-4-6 テスト接続........................................................................................................................ 91
3-4-7 UNIX、Linux 環境での設定 ............................................................................................ 93
3-4-7-1 setupCmdLine.sh の編集........................................................................................... 93
3-4-8 接続プール ...................................................................................................................... 94
3-4-8-1 接続プールの管理....................................................................................................... 94
3-4-8-2 接続プールの設定値の変更....................................................................................... 96
3-5 セッション管理..................................................................................................................... 98
3-5-1 セッション ......................................................................................................................... 98
3-5-2 セッション・トラッキングの種類........................................................................................ 99
3-5-3 セッション・マネージャー................................................................................................ 103
3-5-4 セッション・パーシスタンス設定 .................................................................................... 103
3-5-4-1 DB によるセッション・パーシスタンス ........................................................................ 104
3-5-4-2 メモリー間複製........................................................................................................... 108
3-5-4-3 チューニング・パラメーター設定................................................................................ 114
3-6 トランザクション・サービス ................................................................................................ 116
3-6-1 トランザクション属性 ..................................................................................................... 116
3-6-2 デプロイメント記述子への設定..................................................................................... 116
3-6-3 トランザクション・サービス設定..................................................................................... 119
-2-
3 サーバー管理・基本設定
この章では、プロセスの起動・停止方法などのサーバー管理と仮想ホスト、データベース接続、セッシ
ョン管理、トランザクション・サービスなどの基本設定について説明します。
3-1 管理コンソール
管理コンソールは WAS を管理するためのグラフィカルな Web ブラウザベースのツールです。管理コ
ンソール用のアプリケーションは、EAR ファイル（isclite.ear）の形式で用意されています。ただしシステ
ム・アプリケーションですので、管理コンソール上には表示されず、また設定変更を行うこともできませ
ん。
管理サーバー下の全トポロジーについて定義／参照を含むすべての操作が可能です。
Web ブラウザベースのため、サポートされるブラウザが導入されていれさえすれば、特に制約なくリモー
ト環境からも管理可能です。ブラウザを起動して、URL［http://<host_name>:9060/ibm/console］でアクセ
ス可能です。SSL を利用する場合のポート番号は 9043 です。ここで、<host_name>は、WAS Base を使
用している場合は、WAS Base を導入したサーバーのホスト名で、WAS ND を使用している場合は、デ
プロイメント・マネージャーが稼動するホスト名になります。
なお、以後表示する画面例は、主に WAS ND 構成の管理コンソール画面を用いています。
WAS V7.0 から従来の管理コンソールに加え、ジョブ・マネージャー上の管理コンソール、管理エー
ジェント上の管理コンソールも追加されました。これらの管理コンソールについては、「3-2サーバー管
理」で説明します。
-3-
3-1-1 起動手順
管理コンソールの起動手順を説明します。
1). 前提として、以下のサーバー・プロセスが起動していることが必要です。
WAS Base 構成の場合は、アプリケーション・サーバー(デフォルトは server1)
WAS ND 構成の場合は、デプロイメント・マネージャー(dmgr)
2). Web ブラウザを起動し、管理コンソール用ポート(デフォルトは 9060)を以下のように URL 指定し
ます。
http://<host_name>:9060/ibm/console
SSL を設定し HTTPS 通信を行っている場合は、ポート 9043 で接続します。
https://<host_name>:9043/ibm/console
また、Windows 環境ではスタートから起動することも可能です。スタート・メニューから下記の項
目を選択します。
［スタート］→［プログラム］→［IBM WebSphere］→［Application Server Network
Deployment V7.0］→［プロファイル］→［<DM_Profile_name>］→［管理コンソール］
3). 管理コンソールが起動するとログイン画面が表示されますので、任意のユーザーID を指定しま
す。グローバル・セキュリティーを設定してない場合には、このユーザーID は構成情報の変更内
容のトラッキングを行うために使用されます。作業中の情報は、<DM_Profile_root>/wstemp/<
各ユーザーのユニークな ID>/workspace 以下に保存されます。
図 3-1 管理コンソール：ログイン画面
-4-
3-1-2 ログイン･ユーザー
管理コンソールは作業中の情報をユーザーごとにテンポラリー・ワーク・スペースに保存します。ログイ
ン画面で入力されたユーザーID は、セキュリティーを設定していない場合、構成データに対するユーザ
ー特有の変更をトラッキングする目的でのみ使用されます。このため次回ログイン時に、以下の「ログイ
ンの競合」、「前の変更を回復」のようなメッセージが出力されることがあります。
3-1-2-1 ログインの競合
同一ユーザーID での複数ログインは不可能です。既に使用されているユーザーID でログインしようと
すると競合が発生し、以下のメッセージが表示されるので、いずれかを選択してください。下記メッセー
ジは、ログアウトせずに(前のセッションが残った状態で)、再ログインする場合にも表示されます。
図 3-2 ログインの競合
-5-
3-1-2-2 前の変更を回復
セッション・タイムアウトや変更内容を保存する前にブラウザを閉じてしまった場合などのそれまでの設
定内容をリカバリーするために、再度ログインを行うとき以下のメッセージが表示されます。
図 3-3 前のセッションで行なわれた変更の回復
［マスター構成での作業］を選んだ場合には、最後に保存された構成情報が有効になり、保存を行わ
なかった変更内容は破棄されます。［前のセッションで行われた変更をリカバリーする］を選んだ場合に
は、変更項目の内容を確認してリカバリーすることが可能です。
-6-
3-1-3 使用方法および説明
ここでは、管理コンソールの画面と各メニューについて説明します。
3-1-3-1 起動画面
ログイン後表示される管理コンソールのインターフェースは以下の通りです。
バナー
メッセージ
ヘルプ・エリア
ナビゲーシ
ョン・ツリー
ワーク・スペース
図 3-4 管理コンソールのインターフェース
•
バナー
バナーにより、コンソールのログアウト、WAS 製品情報とサポートページへのアクセスおよびヘルプが
提供されます。「コンソール ID」に任意の文字を表示することができます。ブラウザ・ウィンドウにも同じ文
字が表示されます。複数の管理コンソールを使い分ける際、利用すると便利です。
•
ナビゲーション・ツリー
コンソールの左側にあるナビゲーション・ツリーは、 WAS 管理セル内でコンポーネントを作成および
管理するために使用する、コンソール・ページへのリンクを提供します。
ツリー・フォルダーまたはアイテムの横にある正符号 (+) をクリックすると、フォルダーまたはアイテムの
ツリーが展開されます。負符号 (-) をクリックすると、フォルダーまたはアイテムのツリーが縮小されま
す。ツリー・ビューでアイテムをクリックすると、展開と縮小の状態が切り替わります。
•
ワーク・スペース
コンソールの右側のワーク・スペースには、サーバーやリソースなどの構成オブジェクトの作成と管理
に使用するページがあります。さまざまなタイプの構成済みオブジェクトを表示するには、ナビゲーショ
ン・ツリー内のリンクをクリックします。ワーク・スペース内で、構成済みオブジェクトの構成、ランタイムの
-7-
状態、およびオプションを表示するには、その構成オブジェクトをクリックします。ワーク・スペースの「ホ
ーム」ページを表示するには、ナビゲーション・ツリーの「ようこそ」をクリックします。このページには、
WAS 製品の使用に 関する情報へのリンクと製品情報として WAS のバージョンがビルド番号レベルで
表示されます。
•
メッセージ
構成情報の変更などが行なわれた場合などに、ワーク・スペースの上部にメッセージが適宜表示され
ます。
•
ヘルプ・エリア
コンソールの右側にあるヘルプ・エリアでは、管理コンソールの各画面についてのヘルプ情報につい
て表示されるほか、コマンド・アシスタンス機能による Jython ベースの管理コマンドを表示する画面を呼
び出すことができます。コマンド・アシスタンスについては「第 2 部 第 1 章 システム運用」を参照くださ
い。
3-1-3-2 メニュー
ナビゲーション・ツリーには、１３個の大メニューが表示されます。ツリーを使用するには、主なトピック
を展開し、展開したリストから項目を選択して、管理タスクを実行するページを表示します。以下各メニュ
ーについての概要と、それぞれのメニューの中での設定項目について一覧表示をします。
表 3-1 管理コンソール： メニュー一覧
メニュー
ガイド付きアクティビティー
サーバー
アプリケーション
サービス
リソース
セキュリティー
環境
システム管理
ユーザーおよびグループ
モニターおよびチューニング
トラブルシューティング
サービス統合
概要
グローバル・セキュリティーの使用可能化、Web サーバーによるアプリケ
ーション・サーバーへの要求送付、データベースへの接続方法がガイ
ド付きで設定できます。
アプリケーション・サーバー、クラスター、汎用サーバー、Web サーバ
ー、およびコア・グループを構成します。
アプリケーションをサーバーにインストールし、インストールしたアプリケ
ーションを管理します。
サービス・プロバイダー、サービス・クライアントの表示やポリシー・セット
およびトラスト・サービスの作成、変更を行います。
データベース接続や JMS キュー接続などのリソースを構成して、管理
セルに存在するリソースに関する情報を表示します。
アプリケーションおよびサーバーを保護するために使用するセキュリテ
ィーを構成します。
仮想ホスト、WebSphere 変数、およびその他のコンポーネントを構成し
ます。
コンソール設定を構成し、デプロイメント・マネージャーやノード・エージ
ェントなど WAS ND 製品のコンポーネントとユーザーを管理します。
ユーザー、グループ、およびそれらに紐付く管理者ロールの作成や変
更を行ないます。
アプリケーション・サーバーのパフォーマンスをモニターして調整し、パ
フォーマンス・データを分析します。
構成エラーおよび問題を検査し、ログ・ファイルを表示して、分散プラッ
トフォーム上でトレースを使用可能および使用不可を構成します。
メッセージ指向およびサービス指向のアプリケーションをインプリメントし
ます。
-8-
Web サービスに関する情報を公開し、発見します。
UDDI
各メニューの詳細項目の概要を表に示します。
【ガイド付きアクティビティー】
メニュー
内容
データベースへの接続
データベース・アクセスを構成するための一連のステップを説明す
る
Web サーバーからアプリケーショ Web サーバー・プラグインを構成し、動的コンテンツに対する要求
ン・サーバーへの要求送付
をアプリケーション・サーバーに送付する操作を説明する
クラスターの構成とアプリケーショ サーバー・クラスターを作成し、クラスター上のアプリケーションの
ンの高可用性化
可用性を高めるための一連のステップを説明する
【サーバー】
メニュー
アプリケーション・サーバー
WebSphere プロキシー・サーバー
汎用サーバー
バージョン 5 JMS サーバー
Websphere MQ サーバー
Web サーバー
クラスター
WebSphere Application Server
クラスター
プロキシ・サーバー・クラスター
汎用サーバー・クラスター
クラスター・トポロジー
Data Power
アプライアンス
ファームウェア
管理対象セット
アプライアンス・マネージャー
の設定
タスク
コア・グループ
コア・グループ設定
コア・グループ・ブリッジ設定
内容
アプリケーション・サーバーの新規作成/削除/開始/停止/強制停止
を行う
プロキシー・サーバーの新規作成/削除/開始/停止を行う
WAS が提供しているサーバー以外の、java サーバー、CORBA サ
ーバーなどを汎用サーバーとして登録し、汎用サーバーの新規作
成/削除/開始/停止を行う
JMS サーバーの開始/停止/構成プロパティーの変更を行う
Websphere MQ サーバーの新規作成/削除/開始/停止を行なう
Web サーバーの新規作成/削除/開始/停止、およびプラグインの生
成、プラグインの伝搬を行なう
クラスターの開始/停止/ripple 始動/強制停止/新規作成/削除を行う
プロキシー・クラスターの構成/削除/開始/停止を行なう
汎用サーバーのクラスターの構成/削除/開始/停止を行なう
クラスター・トポロジーに関する設定を行う
DataPower アプライアンスの追加/除去/起動を行う
アプライアンス・マネージャーにファームウェア・バージョンを追加/
削除を行う
管理対象セットは、アプライアンスのグループで、同一の共用可能
なアプライアンス設定、管理対象ドメイン、およびファームウェア・
バージョンを共用する。ここでは管理対象セットの新規作成/削除/
開始を行う
アプライアンス・マネーやジャーに関する設定を行う
タスクの状況を表示する
コア・グループの新規作成/削除を行なう
コア・グループ間の通信の構成に関する設定を行なう。
-9-
【アプリケーション】
メニュー
新規アプリケーション
エンタープライズ・アプリケーション
ビジネス･レベル・アプリケーション（WAS
V7.0 からの新機能）
アセット（WAS V7.0 からの新機能）
【サービス】
メニュー
サービス・プロバイダー
サービス・クライアント
JAX-WS および JAX-RPC セキュリティー・
ランタイム
ポリシー・セット
アプリケーション・ポリシー・セット
システム・ポリシー・セット
汎用プロバイダー･ポリシー・セットのバイ
ンディング
汎用クライアント･ポリシー・セットのバイン
ディング
トラスト・サービス
トークン・プロバイダー
ターゲット
トラスト・サービスの関連付け
セキュリティー・キャッシュ
高信頼性のメッセージングの状態
内容
新規アプリケーション(EAR/WAR/JAR)をインストールす
る
インストール済みアプリケーションに対し、開始/停止/イ
ンストール/アンインストール/更新/更新のロールアウト/フ
ァイルの除去/エクスポート/DDL のエクスポートを行う
ビジネス・レベル・アプリケーション（複数コンポーネント
をひとつの概念でまとめたもの ）を新規作成/削除/開
始/停止を行う
アセット・リポジトリーに、アセットをインポート/エクスポー
ト/アセットの更新/削除を行う
内容
JAX-WS サービス・プロバイダーおよび他のサービス・
プロバイダーを管理する
Web サ ー ビ ス ・ ク ラ イ ア ン ト を 管 理 す る 。 す べ て の
JAX-WS サービス・クライアントがリストされる
Web サービス・セキュリティーのデフォルト・バインディ
ングを管理する
アプリケーション・ポリシー・セットの新規作成/削除/コピ
ー/インポート/エクスポートを行う
システム・ポリシー・セットの新規作成/削除/コピー/イン
ポート/エクスポートを行う
汎用プロバイダー･ポリシー・セット・バインディングの新
規作成/削除/コピー/インポート/エクスポートを行う
汎用クライアント･ポリシー・セット・バインディングの新
規作成/削除/コピー/インポート/エクスポートを行う
トラスト・サービスのトークン・プロバイダーを管理する
セキュリティー・トークンの割り当て/トークンの変更/ラン
タイムの更新を行う
トラスト・サービスをシステム・ポリシーおよびバインディ
ングの関連付け設定を行う
ローカル、またはクラスター・サーバー全体のセキュリテ
ィー・キャッシュ状態を表示する
WS-ReliableMessaging ランタイム状態を表示する
- 10 -
【リソース】
メニュー
スケジューラー
オブジェクト・プール・マネージャー
JMS
JMS プロバイダー
接続ファクトリー
キュー接続ファクトリー
トピック接続ファクトリー
キュー
トピック
アクティベーション・スペック
JDBC
JDBC プロバイダー
データ・ソース
デ ー タ ・ ソ ー ス (WebSphere Application
Server V4)
リソース・アダプター
リソース・アダプター
J2C 接続ファクトリー
J2C アクティベーション・スペック
J2C 管理対象オブジェクト
非同期 Bean
タイマー・マネージャー
作業マネージャー
キャッシュ・インスタンス
オブジェクト・キャッシュ・インスタンス
サーブレット・キャッシュ・インスタンス
メール・プロバイダー
メール・プロバイダー
メール・セッション
URL
URL プロバイダー
URL
リソース環境
リソース環境プロバイダー
リソース環境エントリー
内容
スケジューラーの新規作成/削除/テーブルの検査/テー
ブルの作成/テーブルの除去を行う
オブジェクト・プール・マネージャーの新規作成/削除を
行う
JMS プロバイダーの管理を行なう
接続ファクトリーの管理を行なう
キュー接続ファクトリーの管理を行なう
トピック接続ファクトリーの管理を行なう
JMS キューの管理を行なう
JMS トピックの管理を行なう
JMS アクティベーション・スペックの管理を行なう
JDBC プロバイダーの新規作成/削除を行う
データ・ソースの構成/管理を行なう
WebSphere(R) Application Server バージョン 4 の接続
マネージャー・アーキテクチャーを使用するデータ・ソー
スの構成/管理を行なう
リソース・アダプターの構成/管理を行なう
J2C 接続ファクトリーの構成/管理を行なう
J2C アクティベーション・スペックの構成/管理を行なう
J2C 管理対象オブジェクトの構成/管理を行なう
タイマー・マネージャーの新規作成/削除を行う
作業マネージャーの新規作成/削除を行う
オブジェクト・キャッシュ・インスタンスの新規作成/削除
を行う
サーブレット・キャッシュ・インスタンスの新規作成/削除
を行う
メール・プロバイダーの構成/管理を行なう
メール・セッションの構成/管理を行なう
URL プロバイダーの構成/管理を行なう
URL の構成/管理を行なう
リソース環境プロバイダーの新規登録/削除を行なう
リソース環境エントリーの新規登録/削除を行なう
- 11 -
【セキュリティー】
メニュー
グローバル・セキュリティー
セキュリティ・ドメイン
管理許可グループ
SSL 証明書および鍵管理
セキュリティー監査
バス・セキュリティー
JAX-WS および JAX-RPC セキ
ュリティー・ランタイム
内容
管理セキュリティー・ポリシーおよびデフォルトのアプリケーション・セ
キュリティー・ポリシーの構成/管理を行う
セキュリティ・ドメインの構成/新規作成/削除行う
管理許可グループの新規作成/削除を行う
SSL 証明書および鍵の管理を行う
セキュリティー監査の設定を行う
SIBus のセキュリティー構成を行なう
Web サービス・セキュリティーのデフォルト・バインディングの構成を行
う
【環境】
メニュー
仮想ホスト
グローバル Web サーバー・プラグイン構成の
更新
WebSphere 変数
共用ライブラリー
複製ドメイン
URI グループ
ネーミング
名前空間バインディング
外部セル・バインディング
CORBA ネーミング・サービス・ユーザー
CORBA ネーミング・サービス・グループ
【システム管理】
メニュー
セル
変更をマスター・リポジトリーに保存
デプロイメント・マネージャー
ノード
ノード･エージェント
ノード・グループ
コンソール設定
コンソール ID
内容
仮想ホストの新規作成/削除を行う
セルのグローバル・プラグイン構成ファイルを作成/更
新を行なう
WebSphere 変数の新規作成/削除を行う
デプロイされたアプリケーションから共通で使用される
共有ライブラリーの設定を行う
セッション・マネージャー、動的キャッシュ・サービスお
よび Stateful Session Bean フェイルオーバー・コンポ
ーネントの複製に使用する複製ドメインの設定を行う
URI パターンのグループを作成と削除を行なう
ネーム・バインディングの新規作成/削除を行う
外部セル内のセル・ルート・ネーミング・コンテキストに
解決されるバインディングを管理する
CORBA ネーミング・サービス・ユーザーの追加/除去
を行う
CORBA ネーミング・サービス・グループの追加、除去
を行う
内容
全ノードの論理グループであるセルの設定を行う
ワーク・スペースの変更をマスター構成に保存するほか、変更
の破棄やキャンセルを行う
デプロイメント・マネージャーの構成を設定する
ノードの追加/除去/強制削除/同期化/完全な再同期/停止を実
行する
ノード・エージェントの停止/再始動、ノード配下の全サーバー
の再始動を行う
ノードの集合であるノード・グループの新規作成/削除を行う
管理コンソールのワーク・スペースのユーザー設定を行なう
コンソール ID を使用して管理コンソール・バナーに表示を行う
- 12 -
【ユーザーおよびグループ】
メニュー
内容
管理ユーザー・ロール
ユーザーに管理ロールを追加、更新または除去する
管理グループ・ロール
グループに管理ロールを追加、更新または除去する
ユーザーの管理
ユーザーの検索および管理を行なう。
グループの管理
グループの検索および管理を行なう。
【モニターおよびチューニング】
メニュー
Performance Monitoring Infrastructure(PMI)
要求メトリック
Performance Viewer
現行アクティビティー
ログの表示
【トラブルシューティング】
メニュー
ログおよびトレース
構成上の問題一覧
クラス・ローダー・ビュー
アー
構成の妥当性検査
構成エラー
構成警告
構成情報
診断プロバイダー
テスト
状態データ
構成データ
ランタイム・メッセージ
ランタイム・エラー
ランタイム警告
ランタイム情報
内容
PMI の構成とランタイム設定を行う
WAS 内のトランザクションを追跡し主要コンポーネント
の応答時間を記録する構成を行う
Tivoli Performance Viewer に対するサーバーの選択
を行い、モニターの開始、停止を行う
Tivoli Performance Viewer のログ・ファイルを選択し、
ログの表示を行う
内容
サーバー単位に、各種ログおよびトレースの設定を行なったり、内容を表示
する
管理コンソール上で設定した構成内容について、構成上の問題がある場合
には一覧表示する
アプリケーションに対して可視のクラス・ローダーを表示します。
現在の構成に存在する問題のエラー・メッセージを表示する
現在の構成に存在する問題の警告メッセージを表示する
現在の構成に存在する問題の情報メッセージを表示する
定義済み診断テストの構成/管理を行なう
サーバー・ランタイム・コンポーネントの状態データおよびサーバーについ
て収集されている状態データの管理を行なう
サーバー・ランタイム・コンポーネントの構成データの管理を行なう
サーバーから伝搬するランタイム・イベントのエラー・メッセージを表示する
サーバーから伝搬するランタイム・イベントの警告メッセージを表示する
サーバーから伝搬するランタイム・イベントの通知メッセージを表示する
- 13 -
【サービス統合】
メニュー
バス
Web services
JAX-RPC ハンドラー
内容
サービス統合バスの新規作成/削除を行う
JAX-RPC ハンドラー・リ
スト
WS-Security バインディ
ング
WS-Security 構成
要求および応答に対して起動される JAX-RPC ハンドラーの新規作成/削
除を行う
JAX-RPC ハンドラーの順序リストの新規作成/削除を行う
要求および応答の受信と返信のための WS-Security バインディングの新
規作成/削除を行う
インバウンドおよびアウトバウンド・サービスの WS-Security 構成の新規作
成/削除を行う
UDDI 参照
UDDI 参照の新規作成/削除を行う
WS-Notification(WAS V7.0 からの新機能)
サービス
Web サービスで利用するサービス統合バスの登録を行う
JAX-WS ハンドラー
Web サービス要求、応答時間の設定を行う
JAX-WS ハンドラー・リ JAX-WS ハンドラーを表示する
スト
【UDDI】
メニュー
UDDI ノード
構成エラー
構成警告
構成情報
内容
このセル内で管理できる UDDI ノードの活動化/非活動化を行う
現在の構成に存在する問題のエラー・メッセージを表示する
現在の構成に存在する問題の警告メッセージを表示する
現在の構成に存在する問題の情報メッセージを表示する
- 14 -
3-1-3-3 管理コンソールの使用例
管理コンソールの使用例として、セル内に配置されているクラスターのクラスター・メンバーのページ
を表示します。
ナビゲーション・ツリーから［サーバー］→[WebSphere Application Server クラスター]→［クラスター］
→［<Cluster_name>］→［追加プロパティ］→［クラスター・メンバー］を選択すると、ワーク・スペースにクラ
スター・メンバー・ページが表示されます。このページは個々のクラスター・メンバーの稼動状況の確認、
開始、停止、新規作成を行うことができます。
なお、管理コンソールではブラウザの［戻る］や［進む］を使用せず、ワーク・スペース上部の階層を示
すリンクやナビゲーション・ツリーをクリックし、表示を行うことが推奨されています。
図 3-5 管理コンソール： クラスター・メンバー
- 15 -
3-2 サーバー管理
この節では、WAS 環境におけるサーバー管理について説明します。WAS 環境ではプロセスとしてデ
プロイメント・マネージャー、ジョブ・マネージャー、管理エージェント、ノード・エージェント、アプリケーシ
ョン・サーバーが稼動しています。アプリケーション・サーバー以外のプロセスの総称を管理プロセスと言
いますが、ここでは管理プロセスの起動・停止方法やアプリケーション・サーバーの作成方法などについ
て説明します。
3-2-1 デプロイメント・マネージャーの管理
デプロイメント・マネージャーの起動・停止、ポート番号の確認方法を説明します。
3-2-1-1 デプロイメント・マネージャーの起動
デプロイメント・マネージャーの起動方法を以下に示します。
コマンドによる起動
<DM_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startManager.sh (bat) または # ./startServer.sh(bat) dmgr
【確認方法】
コマンド画面上に、以下のメッセージが出力されることで起動が確認できます。
ADMU3000I: サーバー dmgr が e-business 用にオープンされました。
プロセス ID は 4000 です。
上記メッセージは<DM_Profile_root>/logs/dmgr/startServer.log および SystemOut.log にもログとして出
力されます。
Windows サービスとして実行
Windows 環境では、プロファイル作成時に、デプロイメント・マネージャーを Windows サービスとして
実行することが可能です。 その場合は、関連した Windows サービスを開始し、 デプロイメント・マネ
ージャーの起動を行います。
Windows サービスに定義している場合も、コマンドからの起動は可能です。コマンド画面には
Windows サービスから起動されるメッセージが表示されます。
Windows サービスからデプロイメント・マネージャーを起動するには次ページの手順で行います。
- 16 -
1). [スタート]→［コントロールパネル］→［管理ツール］→［サービス］を開きます。
2). デ プ ロ イ メ ン ト ・ マ ネ ー ジ ャ ー の サ ー ビ ス [IBM WebSphere Application Server V7 –
DeploymentManager_Node_name]を選択し、サービスを開始するため
ボタンをクリック
します。
3). 開始中のウィンドウが表示されます。
4). ［状態］に［開始］が表示されたことを確認します。
- 17 -
スタートメニューからの起動
[ ス タ ー ト ] → 「 す べ て の プ ロ グ ラ ム ] → [IBM WebSphere] → [Application Server Network
Deployment V7.0] →[プロファイル] →[DM_Profile_name] →[デプロイメント・マネージャーの始動]
を選択します。
管理コンソールからの起動
デプロイメント・マネージャーを管理コンソールから起動することはできません。管理コンソールの利用
はデプロイメント・マネージャーが起動していることが前提です。停止はできます。
3-2-1-2 デプロイメント・マネージャーの停止
デプロイメント・マネージャーの停止方法を以下に示します。
コマンドによる停止
<DM_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場合)。
# ./stopManager.sh (bat) または # ./stopServer.sh(bat) dmgr
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
＞ADMU4000I: サーバー dmgr の停止が完了しました。
上記メッセージは<DM_Profile_root>/logs/dmgr/stopServer.log および SystemOut.log にもログとして
出力されます。
Windows サービスとして実行
デプロイメント・マネージャー・プロファイル作成時に、デプロイメント・マネージャーを Windows サー
ビスとして定義している場合は、 関連した Windows サービスを停止し、デプロイメント・マネージャー
の停止を行います。
Windows サービスに定義している場合も、コマンドからの停止は可能です。コマンド画面には Windows
サービスから停止されるメッセージが表示されます。
Windows サービスからデプロイメント・マネージャーを起動するには次ページの手順で行います。
- 18 -
1). サービスからデプロイメント・マネージャーを起動するときと同様に、Windows サービス管理画
面を開き、デプロイメント・マネージャーのサービスを選択し
ボタンをクリックします。
2). 停止中のウィンドウが表示されます。
3). ［状態］に［開始］が消え何も表示されないことを確認します。
- 19 -
スタートメニューからの停止
[スタート]→「すべてのプログラム]→[IBM WebSphere] →[Application Server Network Deployment
V7.0] →[プロファイル] →[DM_Profile_name]→[デプロイメント・マネージャーの停止] を選択しま
す。
管理コンソールからの停止
管理コンソールのナビゲーション・ツリーから、[システム管理]→[Deployment Manager]を開き、構成タ
ブの[停止]ボタンを押すことで停止します。
3-2-1-3 デプロイメント・マネージャーの使用ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートの表示および管理方
法を示します。
1). 管理コンソールから、［システム管理］→［デプロイメント・マネージャー］→［追加プロパティー］の
［ポート］を選択し、リンクの左横にある「+」を展開します。
図 3-6 デプロイメント・マネージャー： 構成画面
- 20 -
2). ポートのリンクを開くと各ポート情報の詳細を示す以下の画面が表示されます。
図 3-7 デプロイメント・マネージャー： ポート番号の確認
各項目について以下に説明します。
ポート名 ：ポートの名前を指定します。名前はすべてサーバー内で固有でなければなりま
せん。
ホスト ：クライアントがリソース (ネーミング・サービス、管理サービス、 JMS ブローカー
など) を要求するために使用する IP アドレス、ドメイン・ネーム・サフィックスの付いた
DNS ホスト名、またはサフィックスの付かない DNS ホスト名を指定します。ポートのホス
ト名は、解決可能な名前または IP アドレスです。
ポート ：クライアント要求を受け入れるようにサービスが構成されているポートを指定しま
す。ポート値は、ホスト名とともに使用します。
関連トランスポート ：指定したポートに紐づいたトランスポート設定の表示と管理を行なう
画面に遷移します。
- 21 -
3). ポート名にある［port_name］リンクをクリックすると、そのポート名に対するポートを設定するこ
とができます。
図 3-8 デプロイメント・マネージャー： ポートの設定
- 22 -
3-2-2 ジョブ・マネージャーの管理
ここでは WAS V7.0 からの新機能であるジョブ・マネージャーの管理について説明します。ジョブ・マ
ネージャーを使用すると、運用、管理などの処理をジョブとして一箇所にキューイングし、複数サーバー
に対して非同期で実行することができ、柔軟に環境を管理できます。
3-2-2-1 ジョブ・マネージャーの起動
ジョブ・マネージャーの起動方法を示します。
コマンドによる起動
<WAS_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startServer.sh(bat) jobmgr
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー jobmgr が e-business 用に開かれました。
プロセス ID は 5568 です。
上記メッセージは<JobManager_Profile_root>/logs/ jobmgr/startServer.log および
SystemOut.log にも出力されます。
Windows サービスとして実行
Windows 環境では、プロファイル作成時に、ジョブ・マネージャーを Windows サービスとして登録す
ることが可能です。 登録した場合は、Windows サービスからジョブ・マネージャーの起動を行います。
Windows サービスに定義している場合も、コマンドからの起動は可能です。コマンド画面には
Windows サービスから起動されるメッセージが表示されます。
Windows サービスからジョブ・マネージャーを起動する手順はデプロイメント・マネージャーと同じで
す 。 「3-2-1-1デ プ ロ イ メ ント ・ マ ネ ージ ャ ー の 起 動 」 を 参 照 し て く だ い 。な お 、サ ー ビ ス 名は [IBM
WebSphere Application Server V7.0 - JobManager_Node_name]です。
スタートメニューからの起動
[スタート]→「すべてのプログラム]→[IBM WebSphere] →[Application Server Network Deployment
V7.0] →[プロファイル] →[JobManager_Profile_name] →[ジョブ管理用の管理サーバーの始動] を
選択します。
3-2-2-2 ジョブ・マネージャーの停止
ジョブ・マネージャーの停止方法を以下に示します。
コマンドによる停止
<JobManager_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場
合)。
# ./stopServer.sh(bat) jobmgr
- 23 -
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
＞ADMU4000I: サーバー jobmgr の停止が完了しました。
上記メッセージは<JobManager_Profile_root>/logs/jobmgr/stopServer.log および SystemOut.log にも
ログとして出力されます。
Windows サービスとして実行
ジョブ・マネージャー・プロファイル作成時に、ジョブ・マネージャーを Windows サービスとして定義
している場合は、 関連した Windows サービスを停止し、ジョブ・マネージャーの停止を行います。
Windows サービスに定義している場合も、コマンドからの停止は可能です。コマンド画面には Windows
サービスから停止されるメッセージが表示されます。
Windows サービスからジョブ・マネージャーを停止する手順はデプロイメント・マネージャーと同じで
す 。 「3-2-1-2デ プ ロ イ メ ント ・ マ ネ ージ ャ ー の 停 止 」 を 参 照 し て く だ い 。な お 、サ ー ビ ス 名は [IBM
WebSphere Application Server V7.0 - JobManager_Node_name]です。
3-2-2-3 ジョブ・マネージャーの使用ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートの表示および管理方
法を示します。
補足：ジョブ・マネージャー管理コンソールポート（デフォルトは 9960、セキュアポート利用の場合は
9943）を URL に指定します。
http://<host_name>:9960/ibm/console
http://<host_name>:9943/ibm/console
1). ジョブ・マネージャー管理コンソールから、［システム管理］→［ジョブ・マネージャー］→［追加プロ
パティー］の［ポート］を選択し、リンクの左横にある「+」を展開します。
図 3-9
ジョブ・マネージャー： 構成画面
- 24 -
2). ポートのリンクを開くと各ポート情報の詳細を示す以下の画面が表示されます。
図 3-10 ジョブ・マネージャー： ポート番号の確認
各項目について以下に説明します。
ポート名 ：ポートの名前を指定します。名前はすべてサーバー内で固有でなければなりま
せん。
ホスト ：クライアントがリソース (ネーミング・サービス、管理サービス、 JMS ブローカー
など) を要求するために使用する IP アドレス、ドメイン・ネーム・サフィックスの付いた
DNS ホスト名、またはサフィックスの付かない DNS ホスト名を指定します。ポートのホス
ト名は、解決可能な名前または IP アドレスです。
ポート ：クライアント要求を受け入れるようにサービスが構成されているポートを指定しま
す。ポート値は、ホスト名とともに使用します。
関連トランスポート ：指定したポートに紐づいたトランスポート設定の表示と管理を行なう
画面に遷移します。
- 25 -
3). ポート名にある［port_name］リンクをクリックすると、そのポート名に対するポートを設定するこ
とができます。
図 3-11 ジョブ・マネージャー・： ポートの設定
3-2-2-4 管理対象ノードを登録
ジョブ・マネージャー管理コンソールを利用するには、ノードを対象とする設定が必要です。管理コン
ソール(通常のデプロイメント・マネージャー管理コンソール)を利用して、ノードをジョブ・マネージャーで
管理できるようにします。デプロイメント・マネージャーを登録すると、デプロイメント・マネージャー管理下
のノードを登録しなくても、ジョブ実行することが可能となります。ただし、各ノードの構成情報は持ちま
せん。構成情報に関する管理は、従来どおりデプロイメント・マネージャーで管理します。
1). デプロイメント・マネージャーで管理コンソールを起動します。
2). [システム管理]→[デプロイメント･マネージャー]→[ジョブ・マネージャー]→[追加プロパティー]の
[ジョブ・マネージャー]をクリックします。
- 26 -
3). [ジョブ・マネージャーに登録]をクリックします。
図 3-12 ジョブ・マネージャー： デプロイメント・マネージャーの登録
各項目について説明します。
管理対象ノード： デプロイメント・マネージャーのノード名を入力します。
別名： 必要に応じて、別名を入力します。
ホスト名： デプロイメント・マネージャーのホスト名を入力します。
ポート： セキュリティー設定をしている場合は WC_adminhost_secure（デフォルト 9960）
の値、セキュリティー設定をしていない場合は WC_Adminhost(デフォルト 9943)の値を入
力します。
ユーザー名： 管理セキュリティーが ON になっている場合、ユーザー名を入力します。
パスワード： 管理セキュリティーが ON になっている場合、管理ユーザーのパスワードを
入力します。
確認パスワード： パスワードを再度入力します。
- 27 -
3-2-2-5 管理コンソールを利用したノードの確認
ジョブ・マネージャー管理コンソールから管理対象ノードのリソース（アプリケーション・サーバー、クラス
ター、アプリケーション等）名の確認と起動・停止状況を確認できます。ここでは確認方法について説明
します。
1). ジョブ・マネージャー管理コンソールを起動します。
2). [ジョブ]→[ノード]をクリックします。 ジョブ・マネージャーで管理しているノード名（WAS ND の
場合はデプロイメント・マネージャー）を確認することができます。ノードが表示されていない場
合は、[検索]を展開し、[ノード名]、[ジョブ・タイプ]、[保有 ID]から検索することも可能です。
図 3-13 ジョブ・マネージャー：リソースの表示
3). [ジョブ]→[ノード・リソース]をクリックします。ジョブ・マネージャーで管理するリソース（アプリケ
ーション・サーバー、クラスター、アプリケーション等）が表示されます。
図 3-14 ジョブ・マネージャー：リソースの表示
- 28 -
4).
[リソース]から確認する対象をクリックします。そのリソースの起動・停止状況を確認します。
図 3-15 ジョブ・マネージャー：リソースの起動・停止状況
- 29 -
3-2-2-6 ジョブの登録
ジョブの登録方法を説明します。
1). ジョブ・マネージャー管理コンソールを起動し、[ジョブ]→[サブミット]をクリックします。
2). ジョブ・タイプを選択します。リストから[ジョブ・タイプ]を選択します。[オプション]でジョブの説明
を追記し、[次へ]をクリックします。
図 3-16 ジョブ・マネージャー：ステップ１ジョブ・タイプの選択
3). ジョブ・ターゲットを選択します。リストから[ノード・グループ]を選択するか[ノード名]を追記しま
す。[次へ]をクリックします。[ノード認証]にはセキュリティー設定を ON にしている場合は入力し
ます。
図 3-17 ジョブ・マネージャー：ステップ２ジョブ・ターゲットの選択
- 30 -
4). ジョブ・パラメーターを指定します。ジョブ・タイプに基づいて、パラメーターが決定します。
図 3-18 ジョブ・マネージャー：ステップ３ジョブ・パラメーターの指定
5). ジョブ・スケジューリングを指定します。
図 3-19 ジョブ・マネージャー：ステップ４ジョブ・スケジューリング
各項目について説明します。
E メール・アドレス：ジョブの状況を知らせるメール・アドレスを登録します。
最初に使用可能になるとき：ジョブの開始タイミングを指定します。即時実行または、任意
の日時を指定できます。
有効期限：ジョブの実行期限を指定します。ジョブを利用できなくなる時刻のことです。デフ
ォルトの有効期限を使用する、ジョブの有効期限の日時を指定する、またはジョブの有効
- 31 -
期限が切れるまでの時間数を指定できます。デフォルトの有効期限は、ジョブ・マネージャ
ーの構成パネルで定義されます。
ジョブのアベーラビリティー間隔：ジョブが再度実施される間隔を指定します。
6). 要約が表示されます。内容を確認し[終了]をクリックします。[ジョブ状況]が表示され、登録したジ
ョブが表示されます。
図 3-20 ジョブ・マネージャー：ステップ５要約の確認
- 32 -
3-2-2-7 ジョブの実行結果の確認
ジョブの実行結果の確認を説明します。
1). ジョブ・マネージャー管理コンソールを起動し、[ジョブ]→[状況]をクリックします。[状況要約]に
は、ジョブ結果を色で表示しています。結果が成功した場合は緑色、失敗した場合は赤色で表
示されます。
図 3-21 ジョブ管理コンソール：ジョブ状況の確認画面
2). 詳細を確認するには、確認したいジョブ ID をクリックし、[状況]をクリックします。タイム・スタンプ
ごとの状況を確認することができます。また、ジョブが失敗した場合は、[メッセージ]欄にエラー
原因が出力されます。
図 3-22 ジョブ管理コンソール：ジョブ状況の確認画面（詳細）
- 33 -
•
成功の場合の画面です。
図 3-23 ジョブ管理コンソール：個別ジョブの状況確認画面（成功の場合）
•
失敗の場合の画面です。
図 3-24 ジョブ管理コンソール：個別ジョブの状況確認画面（失敗の場合）
- 34 -
3-2-3 管理エージェントの管理
ここでは WAS V7.0 からの新機能である管理エージェントの起動・停止・ポート番号の確認方法を説
明します。管理エージェントは、複数の統合されていないアプリケーション・サーバー・ノードを単一のイ
ンターフェースによって管理します。本番環境は ND 構成であっても、開発または単体テスト環境では複
数のスタンドアローン環境で構成する場合などに使用すると、管理タスクを軽減することができます。
3-2-3-1 管理エージェントの起動
コマンドによる起動
<WAS_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startServer.sh(bat) adminagent
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
＞ADMU3000I: サーバー adminagent が e-business 用に開かれました。
プロセス ID は 3600 です。
上記メッセージは<AdminAgent_Profile_name>/logs/adminagent/startServer.log および SystemOut.log
にもログとして出力されます。
Windows サービスとして実行
管理エージェント・プロファイル作成時に、管理エージェントを Windows サービスとして定義している
場合は、 関連した Windows サービスを開始し、管理エージェントの起動を行います。
Windows サービスに定義している場合も、コマンドからの起動は可能です。コマンド画面には Windows
サービスから起動されるメッセージが表示されます。
Windows サービスから管理エージェントを開始する手順はデプロイメント・マネージャーと同じです。
「3-2-1-2デプロイメント・マネージャーの停止」を参照してくだい。なお、サービス名は[IBM WebSphere
Application Server V7.0 – AdminAgent_Node_name]です。
スタートメニューからの起動
[スタート]→「すべてのプログラム]→[IBM WebSphere] →[Application Server Network Deployment
V7.0] →[プロファイル] →[AdminAgent_Profile_name] →[管理エージェント管理サーバーの始動]
を選択します。
3-2-3-2 管理エージェントの停止
管理エージェントの停止方法を以下に示します。
コマンドによる停止
<AdminAgent_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場
合)。
# ./stopServer.sh(bat) adminagent
- 35 -
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
＞ADMU4000I: サーバーadminagent の停止が完了しました。
上記メッセージは<AdminAgent_Profile_root>/logs/adminagent/stopServer.log および SystemOut.log
にもログとして出力されます。
Windows サービスとして実行
管理エージェント・プロファイル作成時に、管理エージェントを Windows サービスとして定義している
場合は、 関連した Windows サービスを停止し、管理エージェントの停止を行います。
Windows サービスに定義している場合も、コマンドからの停止は可能です。コマンド画面には Windows
サービスから停止されるメッセージが表示されます。
Windows サービスから管理エージェントを停止する手順はデプロイメント・マネージャーと同じです。
「3-2-1-2デプロイメント・マネージャーの停止」を参照してくだい。なお、サービス名は[IBM WebSphere
Application Server V7.0 – AdminAgent_Node_name]です。
3-2-3-3 管理対象ノー ドを登録（CUI）
シングル・サーバー・ノードのプロファイルを管理エージェントに登録するには、registerNode コマンド
を使用します。ここで管理できるのは、Base/Express 環境のサーバーです。ND 環境のサーバーは管理
することができません。また、管理エージェントに登録すると、シングル・サーバー・ノードで利用していた
管理コンソールは利用できなくなります。以後の作業は管理エージェント・管理コンソールを利用しま
す。registerNode コマンドの詳細は下記の Information Center の記載を参照してください。
WAS V7.0 Information Center [registerNode コマンド」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae
/ae/ragt_registerNode.html
<AdminAgent_Profile_root>/bin 以下で、以下のコマンドを実行します(カッコ内は Windows 環境の場
合)。
# ./registerNode.sh(bat) –profilePath <AppServer_Profile_root>
【確認方法】
「正常に登録されました」という結果が返ってくることを確認します。
＃./registernode.sh -connType SOAP -port 8877 -profilePath
¥usr¥IBM¥WebSphere¥AppServer¥profiles¥AppSrv01
＞ADMU0116I: ツール情報は次のファイルに記録されています:
(省略)
＞ADMU8012I: パス usr\IBM\WebSphere\AppServer\profiles\AppSrv01 の Application Server
は正常に登録されました。
管理エージェント・管理コンソールを起動し、ノードが登録されたことを確認します。（3-2-3-4管理エー
ジェント・管理コンソール参照）
- 36 -
3-2-3-4 管理エージェント・管理コンソール
ここでは管理エージェント上の管理コンソールについて説明します。
1). 前提として、管理エージェント・プロセスが起動していることが必要です。
2). Web ブラウザを起動し、管理コンソール用ポート(デフォルトは 9060)を以下のように URL 指定し
ます。
http://<host_name>:9060/ibm/console
SSL を設定し HTTPS 通信を行っている場合は、ポート 9043 で接続します。
https://<host_name>:9043/ibm/console
また、Windows 環境ではスタートから起動することも可能です。スタートメニューから下記の項
目を選択します。
［スタート］→［プログラム］→［IBM WebSphere］→［Application Server Network
Deployment V7.0］→［プロファイル］→［<AdminAgent_Profile_name>］→［管理コンソール］
3). 管理コンソールが起動すると、[管理するノードの選択]が表示します。管理エージェントと管理対
象となったノードが表示されます。 この例では管理エージェントに関する情報を確認したいの
で、管理エージェントを選択後、[続行]ボタンをクリックします。次に、ログイン画面が表示されま
すので、任意のユーザーID を指定します。グローバル・セキュリティーを設定してない場合に
は、このユーザーID は構成情報の変更内容のトラッキングを行うために使用されます。作業中
の情報は、<AdminAgent_Profile_root>/wstemp/<各ユーザーのユニークな ID>/workspace
以下に保存されます。
図 3-25 管理エージェントの管理コンソール：起動画面
- 37 -
4). 管理コンソールの[システム管理]→[管理エージェント]を選択します。管理エージェントのプロパ
ティーを確認できます。[必要に応じてコンポーネントを開始]のチェックを入れておくと、管理エー
ジェント・コンポーネントがアプリケーションで必要とされる場合に動的に開始されます。
図 3-26 管理エージェントの管理コンソール：管理エージェントプロパティー
5). 管理コンソールの[システム管理]→[管理エージェント]→[ノード]を選択します。管理エージェント
に登録済みのノードを確認することができます。
図 3-27 管理エージェントの管理コンソール：登録済みのノード
- 38 -
3-2-3-5 管理エージェントの使用ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートの表示および管理方
法を示します。
1). ［システム管理］→［管理エージェント］をクリックします。
2). ［追加プロパティー］→［ポート］をクリックします。
図 3-28 管理エージェントの管理コンソール：ポートの確認
3). ポートの詳細画面が開きます。ポート名の［port_name］リンクをクリックすると、ポートを設定す
ることができます。
- 39 -
3-2-4 ノード・エージェントの管理
ノード・エージェントの起動・停止、ポート番号の確認方法を説明します。
3-2-4-1 ノード・エージェントの起動
ノード・エージェントの起動方法を示します。
コマンドによる起動
<WAS_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startNode.sh (bat) または # ./startServer.sh(bat) nodeagent
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー nodeagent が e-business 用にオープンされました。
プロセス ID は 7096 です。
上記メッセージは<nodeagent_Profile_name>/logs/nodeagent/startServer.log および
SystemOut.log にも出力されます。
Windows サービスとして実行
ノード・エージェントはプロファイル作成時に Windows サービス を作成することができませんが、
WASService コマンドを使用することにより、ノード・エージェント・プロセス用の Windows サービス を作
成することができます。ただし、WASService コマンドによって作成した Windows サービス は、アンイン
ストーラーによって除去できません。必要なくなった場合は作成者の責任において除去してください。
Windows サービスの除去も WASService コマンドで実行できます。
WASService コマンドの詳細については下記の Information Center の記載を参照してください。
WAS V7.0 Information Center「WASService コマンド」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae
/ae/rins_wasservice.html
ノード・エージェント の開始は[スタート]→[コントロールパネル]→[管理ツール]→[サービス]を開き、以
下のとおり行います。
1). サービスを開始するため
ボタンをクリックします。サービス名は「IBM WebSphere
Application Server V7.0 －nodeagent」です。
2). 開始中のウィンドウが表示されます。
3). ［状態］に［開始］が表示されることを確認します。
管理コンソールからの起動
ノード・エージェントについては、メニューより再始動(一旦停止し、始動する)することができます。ただ
し、管理コンソールから起動はできません。
ノード・エージェントの再起動を行うには、メニューより、[システム管理]→[ノード・エージェント]を選択
し、該当ノード・エージェントのチェックボックスにチェックをして、［再始動］を実行します。
- 40 -
図 3-29 ノード・エージェントの始動： 再始動ボタン
実行すると、以下のメッセージがコンソールに表示されます。
図 3-30 ノード･エージェント： 再始動メッセージ
ノード・エージェントは停止した後に自動的に再始動を行います。
図 3-31 ノード・エージェントの始動： 再起動確認
- 41 -
3-2-4-2 ノード・エージェントの停止
ノード・エージェントの停止方法を示します。
コマンドによる停止
<WAS_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./stopNode.sh(bat) または # ./stopServer.sh(bat) nodeagent
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー nodeagent の停止が完了しました。
上記メッセージは<nodeagent_Profile_name>/logs/nodeagent/stopServer.log および SystemOut.log にも
出力されます。
管理コンソールからの停止
管理コンソールのナビゲーション・ツリーから、[システム管理]→[ノード・エージェント]を開き、該当ノー
ド・エージェントのチェックボックスにチェックをして、［停止］を実行します。
図 3-32 ノード・エージェントの停止： 停止ボタン
停止が完了すると、以下のメッセージがコンソールに表示されます。
図 3-33 ノード・エージェントの停止： 停止メッセージ
- 42 -
3-2-4-3 ノード・エージェントの使用ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートを表示および管理し
ます。
1). ［システム管理］→［ノード・エージェント］→［nodeagent_name］をクリックします。
2). ［追加プロパティー］→［ポート］をクリックします。
図 3-34 ノード･エージェント： ポートの確認
3). ポートの詳細画面が開きます。ポート名の［port_name］リンクをクリックすると、ポートを設定す
ることができます。
- 43 -
3-2-5 アプリケーション・サーバーの管理
ここでは、アプリケーション・サーバーの起動・停止、新規作成、設定方法を説明します。
3-2-5-1 アプリケーション・サーバーの起動
WAS ND 構成の場合は、所属するノードのノード・エージェントが起動されていることが各アプリケー
ション・サーバーの起動の前提条件となります。そのため「3-2-4-1 ノード・エージェントの起動」のステッ
プが前提になります。
コマンドによる起動
<Profile_root>/bin 以下で、コマンドを実行します(カッコ内は Windows 環境の場合)。
# ./startServer.sh(bat) ApplicationServer_name
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU3000I: サーバー AMember11 が e-business 用にオープンされました。
プロセス ID は 4352 です。
上記メッセージは<AS_Profile_name>/logs/server1/startServer.log および SystemOut.log にも出力され
ます。
- 44 -
管理コンソールからの起動
WAS Base を使用の場合、管理コンソールがアプリケーション・サーバー上で実行されている時は、管
理コンソールからアプリケーション・サーバーを起動することはできません。コマンドによる起動、または
Windows サービスでの起動を使用します。管理エージェントに登録されたアプリケーション・サーバーに
ついては、管理エージェントの管理コンソールから起動できます。
1). WAS ND を 使 用 の 場 合 は 、 管 理 コ ン ソ ー ル で 、 ［ サ ー バ ー ］ → [ サ ー バ ー ・ タ イ プ ] →
［WebSphere Application Server］を選択し、起動したいアプリケーション・サーバーのチェッ
クボックスをチェックし、［開始］ボタンを押します。この操作の際、アプリケーション・サーバーの
稼動するノードのノード・エージェントが稼動している必要があります。ノード・エージェントが起動
しているか、事前に確認してください。
図3-35 アプリケーション・サーバーの起動： 開始ボタン
2). 以下のメッセージが表示され、始動が成功すると状況が開始済みマークに変わります。
図 3-36 アプリケーション・サーバーの起動：開始メッセージ
図 3-37 アプリケーション・サーバーの開始： 起動の確認
- 45 -
Windows サービスとして実行
管理コンソールから作成するアプリケーション・サーバーの Windows サービス を作成するには、
WASService コマンドを使用します。詳しくは「3-2-4-1ノード・エージェントの起動」をご参照ください。
3-2-5-2 アプリケーション・サーバーの停止
アプリケーション・サーバーの停止方法を説明します。
コマンドによる停止
<WAS_root>/bin 以下で、コマンドを実行します。
# ./stopServer.sh(.bat) ApplicationServer_name
【確認方法】
コマンド画面上に、以下のメッセージが出力されます。
ADMU4000I: サーバー AMember11 の停止が完了しました。
上記メッセージは<AS_Profile_name>/logs/server1/stopServer.log および SystemOut.log にも出力されま
す。
管理コンソールからの停止
1). メニューより、［サーバー］→[サーバー・タイプ]→［WebSphere Application Server］を選択
し、停止したいアプリケーション・サーバーのチェックボックスをチェックし、［停止］ボタンを押しま
す。
図 3-38 アプリケーション・サーバーの停止： 停止ボタン
- 46 -
2). サーバー停止を実施するかを確認する画面が表示されます。問題がなければ［OK］をクリックし
ます。なお、「このメッセージは再度表示しない」にチェックを入れるとこの確認画面は以降の停
止作業では表示されません。
図 3-39 アプリケーション・サーバーの停止： 実施の事前確認
3). サーバー状況をフィードバックする画面に遷移します。ここでは停止プロセスの詳細が出力され
ます。停止処理が正常に終了すると「<servername>は正常に停止されました。詳しくは、JVM
ログを確認してください。」というメッセージが表示されます。
図 3-40 アプリケーション・サーバーの停止： 停止メッセージ
- 47 -
強制停止
[強制停止]ボタンはいかなる状態でも即座に実行されます。そのため、現在稼動中のプロセスは、進
行中の作業を正常に処理することはできません。一方、[停止]ボタンは即座に実行されないので進行中
の作業を正常に処理し停止します。[終了]ボタンは、これらで停止できないプロセスを削除します。終了
は必ず強制停止を試行したのち使用してください。
1).
強制停止を行うには、管理コンソールで、［サーバー］→[サーバー・タイプ]→［WebSphere
Application Server］を選択し、強制停止したいアプリケーション・サーバーのチェックボックス
をチェックし、［強制停止］ボタンを押します。
図 3-41 アプリケーション･サーバーの強制停止： 強制停止ボタン
2). サーバーを即座に停止するかを確認する画面が表示されます。問題がなければ［OK］をクリッ
クします。なお、「このメッセージは再度表示しない」にチェックを入れるとこの確認画面は以降の
停止作業では表示されません。
図 3-42 アプリケーション・サーバーの強制停止： 実施の事前確認
- 48 -
3). サーバーの停止処理が終了すると以下のメッセージが表示されます。
図 3-43 アプリケーション・サーバーの強制停止： 完了メッセージ
終了
1). [ 強 制 停 止 ] が エ ラ ー と な っ た 場 合 、 メ ニ ュ ー よ り 、 ［ サ ー バ ー ］ → [ サ ー バ ー ･ タ イ プ ] →
［WebSphere Application Server］を選択し、強制的に終了したいアプリケーション・サーバ
ーのチェックボックスをチェックし、［終了］ボタンを押します。
図 3-44 アプリケーション・サーバーの終了：終了ボタン
2). サーバー・プロセス終了を確認する画面が表示されます。問題がなければ［OK］をクリックしま
す。なお、「このメッセージは再度表示しない」にチェックを入れるとこの確認画面は以降の終了
作業では表示されません。
図 3-45 アプリケーション・サーバーの終了： 実施の事前確認
- 49 -
3). サーバーの終了処理が終了すると以下のメッセージが表示されます。
図 3-46 アプリケーション・サーバーの終了： 完了メッセージ
3-2-5-3 アプリケーション・サーバーの作成
WAS の管理コンソールからアプリケーション・サーバーの作成方法を説明します。
1). 管理コンソールで[サーバー]→[サーバー・タイプ] →[WebSphere Application Serveｒ]をクリ
ックします。
図 3-47 アプリケーション・サーバーの作成： アプリケーション・サーバー・リンクの選択
2). [新規作成]ボタンをクリックします。
図 3-48 アプリケーション・サーバーの作成： 新規作成ボタン
- 50 -
3). ［サーバー名］を指定します。作成するサーバーを配置するノードを選択した後、サーバー名を
入力して[次へ]をクリックします。サーバー名はノード内で固有である必要があります。
図 3-49 アプリケーション･サーバーの作成： ノードの選択
4). サーバー・テンプレートの選択画面では、作成するアプリケーション・サーバーのテンプレートを
選択します。デフォルトのテンプレートと DeveloperServer のテンプレートが事前に用意されて
います。通常のアプリケーション・サーバーを作成する場合には[default]を選択し、［次へ］をクリ
ックします。また、事前に特定のアプリケーション・サーバーのテンプレートを作成している場合
はそのテンプレートも使用できます。サーバーのテンプレートを作成する方法の詳細は下記の
InformationCenter の記載を参照ください。
WAS V7.0 InformationCenter 「サーバー・テンプレートの作成」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/
ae/ae/trun_create_templates.html
図 3-50 アプリケーション･サーバーの作成： サーバー・テンプレートの選択
- 51 -
5). サーバー固有プロパティーの指定画面では、通常は既存のアプリケーション・サーバーと HTTP
ポートが重複しないように、チェックボックスを有効にしたまま［次へ］をクリックします。
図 3-51 アプリケーション･サーバーの作成： サーバー固有プロパティーの設定
6). 新規アプリケーション・サーバーの情報が表示されます。確認をして[終了]をクリックします。
図 3-52 アプリケーション･サーバーの作成： 新規サーバーの確認
7). サーバーを作成したことによりローカル構成が変更されたので変更をマスターに適用します。
[保存]をクリックします。保存を行わないとマスター構成情報には反映されません。
図 3-53 アプリケーション・サーバーの作成： マスター構成に保存
- 52 -
8). 新規アプリケーション・サーバーが、サーバーのリストに追加されたことを確認してください。
図 3-54 アプリケーション・サーバーの作成： 新規アプリケーション・サーバーの確認
3-2-5-4 アプリケーション・サーバーの削除
WAS の管理コンソールからアプリケーション・サーバーの削除方法を説明します。
1). 管理コンソールの[サーバー]を展開して[サーバー･タイプ]→[WebSphere Application
Server]をクリックします。
2). 削除するアプリケーション・サーバーのチェックボックスを ON にして[削除]ボタンをクリックしま
す。
図 3-55 アプリケーション・サーバーの削除： 削除ボタン
3). 確認画面が表示されますので、[OK]ボタンをクリックします。
図 3-56 アプリケーション・サーバーの削除： 削除実施の事前確認
- 53 -
4). ローカル構成が変更されたので変更をマスター構成に保存します。保存を行わないとマスター
構成情報には反映されません。
5). 新規アプリケーション・サーバーが、リストから削除されたことを[サーバー]→[サーバー･タイプ]
→[WebSphere Application Server]を開いて確認してください。
図 3-57 アプリケーション・サーバーの削除： 削除の確認
- 54 -
3-2-5-5 アプリケーション・サーバーの設定
アプリケーション・サーバーの設定の一例として、ポートの確認とモニター・ポリシーの設定を説明しま
す。
ポートの確認
プロセス内で稼働中のランタイム・コンポーネントによって使用される通信ポートを表示および管理しま
す。
1). ［ サ ー バ ー ］ → ［ サ ー バ ー ・ タ イ プ ］ → ［ WebSphere Application Server ］ →
［ApplicationServer_name］をクリックします。
2). ［通信］→［ポート］のリンクを展開します。
3). [port_name］をクリックすると、ポートを設定することができます。
モニター・ポリシー
ノード・エージェントはノード内のアプリケーション・サーバーの稼動状況をモニターしており、アプリケ
ーション・サーバーが障害で停止しているときには再起動を試みます。（管理ツールを使用して明示的
に停止させた場合は再起動を行いません）
ここではその再始動する方法を制御する設定を表示、または変更します。
1). 管理コンソールから、［サーバー］→[サーバー･タイプ]→［WebSphere Application Server］
→［ApplicationServer_name］をクリックします。 ［サーバー・インフラストラクチャー］→
［Java およびプロセス管理］→［モニター・ポリシー］をクリックします。
図 3-58 モニター・ポリシーの設定： モニター・ポリシー・リンクの選択
- 55 -
4). 下記のモニター・ポリシーの設定画面が開きます。編集が終了したら、[OK]をクリックします。
[保存]ボタンも実行してください。
図 3-59 モニター・ポリシーの設定： プロパティーの設定
ノード・エージェントのアプリケーション・サーバーに対するモニター設定では以下の設定が可能です。
•
始動の最大試行回数
ノード・エージェントがアプリケーション・サーバーの始動を試みる最大回数です。
•
Ping 間隔
ノード・エージェントが Ping によってアプリケーション・サーバーの稼動状況を確認する間隔です。
•
Ping タイムアウト
アプリケーション・サーバーの起動時に、ノード・エージェントがアプリケーション・サーバーの起動
に失敗したと判断する時間です。
•
自動再始動
アプリケーション･サーバーが異常終了した際に、ノード・エージェントがアプリケーション・サーバ
ーの再始動を試みるかどうかを設定します。
•
ノードの再始動状態
ノードが完全にシャットダウンして再始動した後の、プロセスの本来あるべき状態を指定します。
デフォルトの設定は、STOPPED でノードの再起動時に、アプリケーション・サーバーは起動しま
せん。自動的に起動するには RUNNING に設定し、ノード再始動後に、プロセスをもとの状態に
復帰させるには、PREVIOUS を設定します（再始動時に、ノードが起動していた場合は、サーバ
ーを起動します）。
- 56 -
3-2-6 クラスターの管理
管理コンソールの「サーバー・クラスター」ページ（［サーバー］→［クラスター］）ではセル内のクラスタ
ーとその稼動状況を確認することができ、クラスターに対して、開始/停止、ripple 始動、強制停止が可能
です。クラスターに対するこれらの操作はクラスター・メンバーであるすべてのアプリケーション・サーバ
ーに対しての操作となります。ripple 始動は、各クラスター・メンバーを停止した後に起動します。つまり、
再始動を行います。また、WAS V7.0 から、クラスターを開始すると、クラスター・メンバーは自動的に開
始されます。また、すべてのサーバー・コンポーネントも自動的に開始されます。すべてのコンポーネン
トを開始する必要がない場合は、自動で開始されないよう設定することも可能です。
図 3-60 サーバー・クラスター画面
「サーバー・クラスター」ページにてクラスター名をクリックし、「構成」タブの中の追加プロパティ「クラス
ター・メンバー」をクリックすると、「クラスター・メンバー」ページに移ります。この画面ではクラスター・メン
バーであるアプリケーション・サーバーの稼動状況を確認でき、メンバーごとに始動/停止の操作が可能
です。また、クラスターに新規クラスター･メンバーを追加したい場合は、［新規作成］ボタンから追加する
ことができます。
図 3-61 サーバー・クラスター： クラスター・メンバー画面
- 57 -
3-2-6-1 クラスターの起動
WAS の管理コンソールからクラスターを起動する方法を説明します。
開始
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。開始するクラスターのチェック
ボックスを ON にし、［開始］ボタンをクリックします。
図 3-62 クラスターの開始： 開始ボタン
2). 以下のメッセージが表示され、クラスターが開始されます。
図 3-63 クラスターの開始： 開始
3). 「状況」を示すアイコンをクリックし、以下のように開始済みマークになったらクラスターの開始処
理は完了です。
図 3-64 クラスターの開始： クラスター起動完了
- 58 -
ripple 始動
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。再始動するサーバーを選びチ
ェックボックスを ON にします。［ripple 始動］ボタンをクリックします。
図 3-65 クラスターの ripple 始動： ripple 始動ボタン
2). 以下のメッセージが表示され、クラスター・メンバーが順次停止した後に再始動が行なわれま
す。
図 3-66 クラスターの ripple 始動： ripple 始動開始
- 59 -
3-2-6-2 クラスターの停止
WAS の管理コンソールからクラスターを停止する方法を説明します。
停止
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。停止するクラスターを選択しチ
ェックボックスを ON にします。［停止］ボタンをクリックします。
図 3-67 クラスターの停止： 停止ボタン
2). メッセージが表示され、クラスターの停止処理が開始されます。
図 3-68 クラスターの停止： 停止処理開始メッセージ
3). 「状況」を示すアイコンをクリックし、以下のように停止済みマークになったらクラスターの停止処
理は完了です。
図 3-69 クラスターの停止： クラスター停止完了
- 60 -
強制停止
強制停止の説明については、「3-2-5-2 アプリケーション・サーバーの停止」の「強制停止」に詳細が
載っていますので、そちらをご参照ください。
1). 管理コンソールの[サーバー]を展開して[クラスター]を開きます。［強制停止］ボタンをクリックし
ます。
図 3-70 クラスターの強制停止： 強制停止ボタン
2). 以下のメッセージが表示され部分停止の状態になりしばらくして完全に停止します。
図 3-71 クラスターの強制停止： 強制停止オペレーション開始メッセージ
- 61 -
3-2-6-3 クラスターの作成
管理コンソールから新規クラスターを作成する操作は、ナビゲーション・ツリーから［サーバー］→［クラ
スター］の順に展開し、［新規作成］ボタンを押します
図 3-72 クラスターの作成： 新規作成ボタン
新規作成するためには以下に挙げる 4 つステップを実施します。
1). Step1.基本クラスター情報を設定します。
図 3-73 クラスターの作成： 基本クラスター情報の入力
基本クラスターとして以下の項目を入力します
クラスター名：新規クラスターの名前を入力します。
ローカルを優先：EJB WLM において、EJB クライアントからのリクエストが同一ノードで稼
動する EJB コンテナーに優先して割り振られるかどうかの設定です。ローカルを優先する
ことによって、パフォーマンスが向上します。
HTTP セッションのメモリー間の複製の構成：クラスター作成時にメモリー間コピーでのセッ
ション・パーシスタンスなどを構成する場合にチェックを入れます。
- 62 -
2). Step2.最初のクラスター・メンバーを作成します。新規クラスター・メンバーの設定を行います。
設定後、［適用］ボタンを押すと、新規クラスター・メンバーが追加されます。
図 3-74 クラスターの作成： 最初のクラスター・メンバーの作成
この画面における設定として以下の項目があります。
メンバー名：クラスターに追加する新規クラスター・メンバー（アプリケーション・サーバー）
の名前を入力します。
ノードの選択：サーバーを配置するノードを選択します。
ウェイト：サーバーのウェイトを指定します。
固有 HTTP ポートの生成：固有の HTTP ポートを作成するかどうかを指定します。
また、最初のクラスターメンバーをどのように生成するかを以下の項目からひとつ選択します。
「アプリケーション・サーバー・テンプレートを使用してメンバーを作成します」：
既存のアプリケーション・サーバー・テンプレートを利用して最初のクラスターメンバーを作
成します。登録済みのテンプレートから適切なものを選びます。
「既存のアプリケーション・サーバーをテンプレートとしてメンバーを作成します」：
すでに作成済みのサーバーの設定を利用して最初のクラスター・メンバーを作成します。
既存のアプリケーション・サーバーをリストから選択します。
「既存のアプリケーション・サーバーを変換してメンバーを作成します」：
すでに作成済みのサーバーを新規クラスター・メンバーとして利用します。既存のアプリケ
ーション・サーバーをリストから選択します。
「なし」：クラスター・メンバーを含まない空のクラスターを作成します。
新規クラスター・メンバーの設定を終えたら、［次へ］ボタンを押し、Step3 へ進みます。
- 63 -
3). Step3.追加クラスター・メンバーを作成します。
ここで残りのクラスター・メンバーの作成を行ないます。Step2.で作成した最初のクラスター・メンバーが保
存されていますので、これをテンプレートとして追加のクラスター・メンバーを作成します。設定項目は
Step2.と同じです（テンプレートの選択は除く）。個々のクラスター・メンバーの設定を終えたら［メンバー
の追加］をクリックします。これにより、メンバー・リスト表にクラスター・メンバーが登録されます。
残りのクラスター・メンバーの設定を終えたら、［次へ］ボタンを押し、Step4 へ進みます。
図 3-75 クラスターの作成： 追加クラスター・メンバーの作成
4). Step4.要約を表示します。
図 3-76 クラスターの作成： 要約の確認
設定内容を確認して、［終了］ボタンを押すと、クラスターが作成されます。
- 64 -
5). クラスターが追加されたことを確認してください。確認ができたら構成の保存を実施してクラスタ
ーの作成は完了です。メッセージ・ボックス内にある［保存］のリンクをクリックし変更を構成情報
に保存します。
図3-77 クラスターの作成： マスター構成に保存
6). クラスターがリストに追加されたことを確認してください。
図 3-78 クラスターの作成： クラスターの確認
- 65 -
3-2-7 Web サーバーの管理
WAS のシステムにおける Web サーバーの構成として以下の 2 つのケースに分類できます。
1). アプリケーション・サーバー（つまりは、ノード・エージェント）と Web サーバーが同一筐体に存在
するローカル Web サーバー構成
2). Web サーバーの稼動する筐体とアプリケーション・サーバー（つまりは、ノード・エージェント）が
稼動する筐体が分離しているリモート Web サーバー構成
WAS V6.1 の時と同様にセルの管理対象に Web サーバーを含めないこともできますが、この場合はプ
ラグイン構成ファイルを管理コンソールで生成することができませんので、コマンドでプラグイン構成ファ
イルを生成し、手動で適切な筐体の適切なディレクトリーに伝搬する必要があります。
また、管理コンソールから実行できる機能は、Web サーバーとして IBM HTTP Server を使用した場合
と、それ以外の Web サーバーを使用した場合で異なります。リモート構成の Web サーバーとして、IBM
HTTP Server 以外の Web サーバーを使用する場合には、手動でプラグイン構成ファイルの伝搬を行う
必要があります。各構成で管理コンソールから実行できる機能をまとめると表 3-2のようになります。
表 3-2 Web サーバーの構成の違いによる管理コンソールから実行可能な操作の違い
○
○
ローカル/IHS
以外
○
○
○
○
○
○
○
×
○
×
○
×
○
×
○
×
○
×
ローカル/IHS
プラグインの生成
プラグインの伝搬
Web サーバー稼動状
況の確認
Web サーバーの
起動・停止
Web サーバー構成
（httpd.conf）の編集
error.log と
access.log の表示
- 66 -
リモート/IHS
リモート/IHS 以外
○
○
○
×
3-2-7-1 Web サーバーのローカル構成
Web サーバーが稼動するマシンと同一ノード上で、ノード・エージェントが稼動する場合には、デプロ
イメント・マネージャーから Web サーバーの管理が可能です。ただし、Web サーバーの種類として IBM
HTTP Server を用いる場合とその他の Web サーバーを使用する場合では、管理できるレベルが異なりま
す。すべての Web サーバーにおいて、プラグイン構成ファイルの生成、編集を行うことはできますが、
Web サーバーの起動・停止・Web サーバー構成ファイルの編集は IBM HTTP Server のみ行うことができ
ます。Web サーバーが管理対象ノードとして登録されていると、Web サーバーはノード・エージェントを
介して操作され、WAS から管理が可能となります。
構成手順の詳細は下記の Information Center の記載を参照ください。
WAS V7.0 Information Center「同一マシン上の Web サーバーおよびカスタム・プロファイルの構成」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/a
e/tins_webplugins_localr.html
3-2-7-2 IBM HTTP Server のリモート Web サーバー構成
リモート Web サーバー構成において、Web サーバーが IBM HTTP Server の場合、IBM HTTP
Server の管理サーバーがデプロイメント・マネージャーと通信を行うことによって、WAS が IBM HTTP
Server を管理しています。WAS の管理下にある IBM HTTP Server は、管理コンソールから稼動状況
の確認やプラグイン構成ファイルの伝搬、Web サーバーの起動・停止が可能です。
構成手順の詳細は下記の Information Center の記載を参照ください。
WAS V7.0 Information Center「別個のマシン上での Web サーバーおよびアプリケーション・サーバー
の構成 (リモート)」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/a
e/tins_webplugins_remotesa.html
- 67 -
3-2-7-3 IBM HTTP Server を使用した Web サーバー構成例
管理コンソールから Web サーバー定義を作成する方法について Windows 環境を例に説明します。
前提として IBM HTTP Server を管理するためのノードが作成されていることとします。
1). 管理コンソールで、［システム管理］→［ノード・エージェント］を開き、管理用のノード・エージェン
トが始動していることを確認します。
2). ［サーバー］→[サーバー・タイプ]→［Web サーバー］をクリックし、［新規作成］ボタンを押しま
す。Web サーバーのノードを選択し、Web サーバー名と Web サーバーのタイプを入力します。
［次へ］ボタンを押します。ローカル Web サーバー構成ではここで選択したノードに Web サーバ
ーは配置されます。
図 3-79 Web サーバー構成： Web サーバーの配置ノードおよびタイプの選択
3). Web サーバー・テンプレートを選択します。通常はデフォルトのテンプレートを使用します。
図 3-80
Web サーバー構成： Web サーバー・テンプレートの選択
- 68 -
4). Web サーバーのプロパティーを入力します。下記の項目を入力し、［次へ］をクリックします。
図 3-81
Web サーバー構成： Web サーバーのプロパティーの入力
ポートは、Web サーバーの listen ポート番号（ 例：80 ）を入力します。IBM HTTP Server 使用の場合、
インストール・パスは必須です。Web サーバーのインストール・パス（ 例：C:¥IBM¥HTTPServer ）を入力
します。サービス名は、Windows 環境でのサービス名を入力します。このサービス名とは表示名ではな
く実際のサービス名、つまりコントロールパネルの［サービス］にリストされている IBM HTTP Server のプ
ロパティー中の全般タグの［サービス名］を指します（例：IBMHTTPServer7.0）。尚、Web サーバーの稼
動ノードが Windows 環境ではない場合には、サービス名の入力欄は表示されず、入力の必要はありま
せん。プラグインのインストール場所には、プラグインのインストール・パス（例：
C:¥IBM¥HTTPServer¥Plugins）を入力します。
図 3-82 Web サーバーのサービス名
- 69 -
5). 内容を確認し、［終了］ボタンを押します。
図 3-83 Web サーバー構成： 新規 Web サーバーの確認
6). 以上のステップで Web サーバーが作成されました。これにより［プラグインの生成］、［開始］、
［停止］が可能になります。
- 70 -
3-2-7-4 IBM HTTP Server 以外のリモート Web サーバー構成
Web サーバーが IBM HTTP Server 以外でノード・エージェントを配置しない場合、Web サーバー構成
ファイルの伝搬はデプロイメント・マネージャーの管理外となります。管理コンソールから Web サーバー
の稼動状況を確認することはできますが、プラグイン構成ファイルは Web サーバーのマシンへと手動で
コピーする必要があります。
構成手順の詳細は Web サーバーとして IBM HTTP Server を使用する場合と同様に下記の
Information Center の記載を参照ください。
WAS V7.0 Information Center「別個のマシン上での Web サーバーおよびアプリケーション・サーバー
の構成 (リモート)」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/a
e/tins_webplugins_remotesa.html
マシンB
マシンB
マシンA
マシンA
ノード
DM
Webサーバー
Plugin構成ファイル
Plugin構成ファイル
構成
リポジトリー
管理コンソール
セル
Webサーバー･ノード
＊IHS以外
プラグインの生成
手動コピーが必要
図 3-84 IBM HTTP Server 以外のリモート Web サーバー構成
1). マシン B の<Plugin_root>/bin ディレクトリー下の configure<WebServer_name>.sh（bat）スク
リプトファイルをマシン A の<WAS_root>/bin ディレクトリー下に手動でコピーして、実行します。
2). 管理コンソールから、［サーバー］→[サーバー・タイプ]→［Web サーバー］を開くと、スクリプトフ
ァイルを実行したことによって Web サーバーが作成されていることが確認できます。
3). ［プラグインの生成］ボタンを押し、プラグイン構成ファイルを更新します。ただし、プラグイン構成
ファイルの伝搬は手動で行う必要があります。
- 71 -
3-3 仮想ホスト
仮想ホストは 1 台の物理マシンを論理的に複数のホストマシン（仮想ホスト）として使用する環境を提
供しています。仮想ホストを使用することにより、異なるアプリケーションを１つのセルに統合し、かつあた
かも別のシステム上で動作しているかのような環境を構築することができます。
WAS の各ノードにある Web アプリケーションは、いずれかの仮想ホストと関連づけられ、この Web ア
プリケーション中のサーブレット、JSP ファイル、静的コンテンツの相対パスは、アプリケーションに関連付
けられる形で仮想ホストに所属しています(図 3-85)。
仮想ホストはクライアントからの要求パケットの HTTP ヘッダー中の Host:に含まれるホスト名およびポ
ート番号(指定されている場合)に対応します。Web アプリケーションは呼び出された仮想ホストに応じて
厳密に区別されます。たとえ物理的に同一のマシン上にあっても、異なる仮想ホストに所属するアプリケ
ーションを呼び出すことはできません(図 3-86)。
仮想ホスト①
www.abc.com 80
intra.abc.co.jp
www.abc.com
ノード
Webブラウザ
HTTP
サーバー
HTTP
プラグイン
HTTP
トランスポート
Web
アプリケーション
Webコンテナー
アプリケーション・サーバー
図 3-85 １ノード・１仮想ホスト
仮想ホスト②
仮想ホスト①
www.abc.com 80
intra.abc.co.jp 80
www.abc.com
ノード
Webブラウザ
HTTP
トランスポート
HTTP
サーバー
HTTP
プラグイン
Webコンテナー
Web
アプリケーション
Web
アプリケーション
アプリケーション・サーバー
図 3-86 １ノード・複数仮想ホスト
- 72 -
仮想ホストは論理名をもっており、それぞれにホストエイリアスと呼ばれる DNS エイリアスとポート番号
の組み合わせのリストを持っています。
たとえば、要求 http://localhost:80/myServlet では、localhost:80 がエイリアスに相当します。1 つの仮
想ホストに対して、複数のエイリアスを定義できます。
仮想ホストは、特定のノードに関連付けられるのでなく、セル内の環境として定義されます。同一のセ
ル内では、複数のノードで仮想ホストを共有し、アプリケーション単位で各仮想ホストと関連付けられま
す(図 3-87)。Web サーバー・プラグインでは、仮想ホストと URI の組み合わせによりアプリケーションを
識別し、それぞれにマップされたアプリケーション・サーバーにリクエストを転送します。
仮想ホスト②
仮想ホスト①
www.abc.com 80
intra.abc.co.jp 80
www.abc.com
Webブラウザ
HTTP
トランスポート
HTTP
サーバー
HTTP
プラグイン
Webコンテナー
Web
アプリケーション
Web
アプリケーション
アプリケーション・サーバー
アプリケーション・サーバー
HTTP
トランスポート
Web
アプリケーション
Webコンテナー
ノード
仮想ホスト③
store.abc.com 80
security.abc.com 443
セル
図 3-87 複数ノードと複数仮想ホスト
WAS V7.0 ではデフォルトで以下の２つの仮想ホストが定義されています。
•
default_host
そのサーバーでもつすべてのアドレスの、ポート 80, 9443, 9080 に対して定義されています。
すべてのアプリケーションで利用することができます。
•
admin_host
WAS V7.0 管理コンソール用に使用されます。他のアプリケーションからは使用できません。
ポート 9060、9043 に対して定義されています。
仮想ホストを追加する必要があるのは、例えば通常の HTTP リクエストと SSL でのリクエストでアクセス
されるリソースを分けたい場合などで、そういったときには仮想ホストを分けてリソースを配置します。しか
したいていのユーザーにとっては仮想ホストをあえて作成する必要はなく、デフォルトで提供される
default_host を使用することができます。
- 73 -
3-3-1 仮想ホスト作成
仮想ホストの作成方法を説明します。
1). ナビゲーション・ツリーから[環境]を展開して[仮想ホスト]をクリックします。
2). [新規作成]をクリックします。
図 3-88 仮想ホストの作成： 新規作成ボタン
3). 一般プロパティーの［名前］に仮想ホストの名前を入力して[適用]をクリックします。
図 3-89 仮想ホストの作成： 仮想ホスト名の設定
4). 追加プロパティーの[ホスト別名]をクリックします。
- 74 -
5). [新規作成]をクリックします。
図 3-90 ホスト別名の作成： 新規作成ボタン
6). この仮想ホストに紐付くホスト名とポート番号の組を、［ホスト名］と［ポート］を入力して[適用]を
クリックします。この仮想ホストの設定と一致するユーザーからのリクエストだけが、この仮想ホ
ストにマップされたアプリケーションで処理されます。ホスト名は任意の値を許可する * 、または
特定のホスト名を入力します。ポート番号のデフォルト値は HTTP で使用される 80 です。
図 3-91 ホスト別名の作成： 別名の設定
- 75 -
7). ホスト別名が追加されたことを確認してください。確認ができたら構成の保存を実施して仮想ホ
ストとホスト別名の作成は完了です。メッセージ・ボックス内にある［保存］のリンクをクリックし変
更を構成情報に保存します。
図 3-92 ホスト別名の作成： マスター構成へ保存
図 3-93 ホスト別名の作成： ホスト別名の確認
- 76 -
3-4 データベース接続設定
J2EE アプリケーションの中にはデータベース・アクセスがビジネスロジックの処理の中核となるものも
少なくありません。ここでは、WAS におけるデータベース・アクセスの概念と構成について解説します。
3-4-1 データベース接続の概説
J2EE アプリケーションからのデータベースへの接続の概要は下記の図のようになります。
各データベース･ベンダーが提供
するJDBCドライバーをWebSphere AS
上に設定
・JDBCドライバーのクラスパス
・データソースの実装クラス
・ネイティブ・ライブラリー・パス
WebSphere AS
JDBC
Application
JDBC
Provider
Database
DataSource
・JNDI名（jdbc/SampleDS）
・データーベース名
・データ･ソース・ヘルパーの型
・ユーザーID
・パスワード
データソースをlookupするコードの一部
try{
Context ctx = new InitialContext();
ds1 = (DataSource)initialcontext.lookup(“java:comp/env/jdbc/SampleDS”);
conn = ds.getConnection();
・・・
} catch (NamingException ne) {
ne.printStackTrace();
}
図 3-94 J2EE アプリケーションからのデータベース接続の概要図
図中のコードでは、lookup というメソッドにより、データ・ソース・オブジェクトを取得しています。使用す
るデータ・ソース名が、lookup メソッドの引数となります。この lookup メソッドの戻り値として返されたデー
タ・ソース・オブジェクトに対し、接続・切断・データ・アクセスを行います。
- 77 -
3-4-1-1 データベース接続設定のキーワード
•
JDBC ドライバー
JDBC ドライバーは JDBC の API と各データベース製品を結びつけます。JDBC ドライバーは各デー
タベース･ベンダーによって提供されています。例えば、IBM の DB2 V9.1 または V9.5 では、「DB2
Universal JDBC ドライバー（ファイル：db2jcc.jar）」などが提供されます。同じデータベース製品でも、接
続の種類（ローカル接続かネットワーク接続か）や 2 フェーズ・コミットをサポートするか否かなどにより、
いくつかの種類があります。
•
JDBC プロバイダー
JDBC ドライバーのパス、この JDBC プロバイダーの元で作成されるデータ・ソースの型、ネイティブ・ラ
イブラリー・クラス等を指定するための定義情報です。
•
データ・ソース
データベースに接続するために必要な情報(データベース名、JNDI 名、データ・ソース・ヘルパーの
型、ユーザーID、パスワード)を指定するための定義情報です。
•
JNDI とデータ・ソース
WAS V7.0 では、JDBC4.0 標準拡張 API の一部として提供されている JNDI （Java Naming and
Directory Interface）を使用することによって、システムの物理的な構成や実装に依存しない形でデータ
ベースにアクセスすることが可能となっています。
JNDI を使用したプログラム中では、データベースは「論理名」を持つ「データ・ソース」オブジェクトとし
て表現されます。Java オブジェクトとして実装された「ネーミング・サービス」に対してデータ・ソースの論
理名を指定して検索を依頼すると、現実のデータベースと紐付けされたデータ・ソース・オブジェクトが
返されます。データベースへの接続や切断もこのデータ・ソース・オブジェクトに対して行うことになりま
す。
データ・ソースの論理名とデータベースの物理名との紐付けや、データベースのアクセスに必要とな
る JDBC ドライバーの管理は、すべて WAS システムの内部で処理されます。このため、データベースの
構成に変更があった場合も WAS の設定の変更のみで対応でき、プログラムの変更は必要なくなりま
す。
•
接続プーリング
通常のアプリケーションにおいてもデータベースの接続と切断は負荷の高い処理ですが、特に Web ア
プリケーションの場合はそのシステム上の特性からデータベース接続と切断が高頻度で繰り返されるこ
とになりがちであり、ユーザーへの応答時間に与える影響も無視できません。この負荷を軽減するため
にデータベース接続を共用する機能が接続プーリングです。
接続プーリングを使用すると、プールからの接続の取得と返却の処理はデータ・ソースの内部で行わ
れるため、アプリケーション側では通常の接続／切断と同様の処理を行えばよく、特殊なコーディングは
必要ありません。
接続プーリングを使用したシステムでは、個々のユーザー・プログラム（サーブレット、EJB）がデータ
ベースの接続要求を出すと、実際にその時点でデータベースに接続を行うのではなく、すでに接続され
プールされていた接続が渡されます。データベースの切断要求時には、実際の切断処理は行われず
に、接続は接続された状態のままプールに戻される処理が行われます。これによってデータベース接続
の負荷は最初の１回のみにかかり、２回目以降のユーザーからの接続要求に対するオーバーヘッドは
わずかなものですみます。
- 78 -
3-4-2 JDBC ドライバー
JDBC ドライバーには、データベース接続形態と 2 フェーズ・コミットをサポートするか否かに応じて複数
の種類が存在します。
データベースの接続形態の違いにより、4 種類の JDBC ドライバーがあり、Type1～Type4 の JDBC ドラ
イバーと呼ばれています。各データベース･ベンダーが 1 つまたは複数の種類のドライバーを提供して
います。必ずしも全ての種類のドライバーを提供しているわけではありません。
Type1 の JDBC-ODBC ブリッジ・ドライバーは既存の ODBC ドライバーを利用してデータベース・アク
セスを行います。この JDBC ドライバーは SDK に同梱されています。しかし、Type1 のドライバーを使用
するのはデータベース･ベンダーから Type2～4 のドライバー（Java 用のドライバー）が提供されていない
場合のみであり、すでに主要なデータベース･ベンダーから各データベース用の JDBC ドライバーが提
供されているため、Type1 のドライバーを使用する必要はほとんどありません。
Type2 のネィティブ・ブリッジ・ドライバーはローカル・システムに導入されたデータベース固有のドライ
バー（ネイティブ DBMS ドライバー：DB2 の場合は DB2 クライアント）を呼び出すことにより、データベー
ス・アクセスを行います。特長としては、WAS 導入マシン側にデータベースのクライアント・ソフトウェアが
必要となります。
Type3 のネット・ドライバーはリモート・システムに導入された専用プログラム（JDBC アプレットサーバ
ー）とネットワーク接続するので、WAS 導入マシン側にはデータベース固有のドライバーを必要としませ
ん。
Type4 のダイレクト・ドライバーは、純粋な Java プログラムだけで、直接データベース・アクセスを行いま
す。Type3 および Type4 のドライバーは元来アプレットが Web サーバーからダウンロードして使用するこ
とを想定して提供されていました。
また、Type2～4 の JDBC ドライバーにおいては、それぞれ 2 フェーズ・コミットをサポートするものとしな
いものがあります。
サーブレット、EJBなどのJavaプログラム
JDBC API (java.sql , javax.sqlパッケージ)
JDBCドライバーマネージャー
Type1
JDBC-ODBC
ブリッジ・ドライバー
Type2
ネイティブ・ブリッジ
・ドライバー
ODBC
ドライバーマネージャ
ネイティブDBMS
ドライバー
（DB2ｸﾗｲｱﾝﾄ等）
Type3
ネット・ドライバー
Type4
ダイレクト・ドライバー
WebSphere AS 導入マシン側
DB導入マシン側
JDBC
アプレットサーバー
凡例
ネイティブ
ODBCドライバー
ネイティブDBMS
ドライバー
DBMS
開発者提供
SDK提供
DBベンダー提供
図 3-95 JDBC ドライバー
- 79 -
UNIX または Windows 上で稼動する DB2 の提供する JDBC のドライバーは下記表の 4 種類です。
XA と non-XA のドライバーの違いですが、XA のドライバーは 2 フェーズ・コミットをサポートし、non-XA
のドライバーは 2 フェーズ・コミットをサポートしません。プログラムで 2 フェーズ・コミットを使用する場合
は XA ドライバーを使用します。XA ドライバーを使用するアプリケーションには、トランザクション・リカバ
リーという利点があります。
2 フェーズ・コミットを使用しない場合は、パフォーマンスのよい non-XA ドライバーを使用します。
なお、DB2 Legacy CLI-based Type2 Driver は WASV7.0 からサポートされなくなりました。旧バージョ
ンからのマイグレーションの際は DB2 Universal JDBC プロバイダーへ変更することが必要です。
表 3-3 WAS がサポートする DB2 のドライバー
WAS JDBC Provider Name
DB2 Universal JDBC Driver Provider
Type
2/4
zip/jar
db2jcc.jar
DB2 Universal JDBC Driver Provider (XA)
2/4
db2jcc.jar
DB2 Using IBM JCC Driver
2
db2jcc4.jar
DB2 Using IBM JCC Driver (XA)
2
db2jcc4.jar
Implementation Class
com.ibm.db2.jcc.
DB2ConnectionPoolDataSource
com.ibm.db2.jcc.
DB2XADataSource
com.ibm.db2.jcc.
DB2ConnectionPoolDataSource
com.ibm.db2.jcc.
DB2XADataSource
3-4-3 JDBC プロバイダー設定
ここでは、JDBC プロバイダーの有効範囲の設定や作成方法を説明します。
3-4-3-1 JDBC プロバイダーの有効範囲の設定
有効範囲とは、リソースを定義するレベル(セル/ノード/クラスター/サーバー)を示します。
リソースは、セル、ノード、クラスター、サーバー(アプリケーション・サーバー)の各レベルにおいて定義
することができます。
JDBC プロバイダーを作成する前に、どの有効範囲で JDBC プロバイダーを作成するかを検討する必
要があります。
あるリソースをサーバー・レベルで定義した場合は、そのリソースは、そのサーバーからのみ使用可能
です。ノード・レベルで定義されたリソースは、そのノード上で稼動する全てのサーバーから使用すること
ができます。クラスター・レベルで定義されたリソースは、そのクラスター上で稼動する全てのサーバーか
ら使用することができます。セル・レベルで定義されているリソースは、そのセルに含まれるノード上で稼
動する全てのサーバーから使用可能になります。
また、複数のレベルで同じリソースに関する定義がなされている場合は、より広い範囲のレベルの定
義に、より限定的な範囲での定義が上書きされます。
•
アプリケーションの有効範囲はすべての有効範囲より優先されます。しかし、この有効範囲を管理
コンソールから構成することはできませんのでご注意ください。
•
サーバーの有効範囲は、ノード、セル、およびクラスターの有効範囲より優先されます。
•
ノードの有効範囲はクラスター、およびセルの有効範囲より優先されます。
•
クラスターの優先範囲はセルの有効範囲より優先されます。
- 80 -
また、リソースはさまざまなレベル(有効範囲)において作成することができますが、そのリソースのプロ
パティーは、個々のサーバー・レベルでのみ適用されます。例えば、あるデータ・ソースをセル・レベル
で定義する場合、そのセルのすべてのユーザー(サーブレット、EJB 等)が、そのデータ・ソースをルック
アップし、使用することができます。そして、このデータ・ソースの最大接続数 を 10 に設定する場合、そ
のセル内の各サーバーは 10 個の接続を使用できることになります。
管理コンソールにおいて、リソースに関する定義を行う際には、セル、ノード、クラスター、サーバーの
どのレベルにおいて、そのリソースを作成するのかを意識する必要があります。
Cell
Resource7
Node A
AppServer X
EA-1
Resource1
Resource3
AppServer Y
Node B
Cluster
Resource2
図 3-96 ND 構成
Resource6
Resource6
Resource5
AppServer Z
EA-2
Resource4
※EA＝エンタープライズ・アプリケーション
AppServer X 上で稼動するエンタープライズ・アプリケーション[EA-1]では、Resource1、Resource3、
Resource7 を使用することができます。
AppServer Z 上で稼動するエンタープライズ・アプリケーション[EA-2]では、Resource4、Resource5、
Resource6、Resource7 を使用することができます。
Resource2, Resource3、Resource6、Resource７が同一のリソースに関する定義である場合、Resource7
の定義は Resource6 の定義に上書きされ、Resource7、Resource6 の定義は Resource3 の定義に上書き
され、Resource7、Resource6、Resource3 の定義は Resoruce2 の定義に上書きされることとなります。
また、Resource7 を[EA-1]と[EA-2]とが使用することができますが、リソースのプロパティーは、サーバ
ー毎に有効であり、例えば最大接続数が 10 と設定されていた場合、ランタイムでは AppServerX におい
て 10 個、AppServerZ において 10 個、計 20 個(※)の接続が作成されることとなります。
(※AppServerY においても 10 個まで接続を作成することができますが、この図では AppServerY には
アプリケーションがインストールされていないので、接続が作成されることはありません。)
- 81 -
3-4-3-2 JDBC プロバイダー作成
JDBC プロバイダーの作成方法を説明します。
1). 管理コンソールのナビゲーション・ツリーから、[リソース] → [JDBC] → [JDBC プロバイダー]
を選択します。
2). 適切な有効範囲を選択した後、[新規作成]ボタンをクリックします。
図 3-97
JDBC プロバイダーの作成： 有効範囲の設定と新規作成ボタン
3). 新規 JDBC プロバイダー作成の画面に移ります。作成は以下の三つのステップからなります。
• ステップ１ DB2 や Oracle などのサポートされるデータベース・タイプを選択します。サポートされ
るデータベース・タイプのリストに、使用するタイプが含まれていない場合は、［ユーザー定義］を
選択します。プロバイダー・タイプ、実装タイプを選択した後 JDBC プロバイダー名を入力して
［次へ］をクリックします。
図 3-98
JDBC プロバイダーの作成： データベースタイプ、プロバイダータイプの設定
- 82 -
•
ステップ２ 必要に応じてデータベース・クラスパス情報を入力します。また、JDBC プロバイダー
の設定時に必要となる WebSpehre 変数をここで設定することも可能です。
図 3-99
•
JDBC プロバイダーの作成： データベース・クラスパス情報の設定
ステップ３ 設定項目を確認して［終了］をクリックします。
図 3-100
JDBC プロバイダーの作成： 要約の確認
- 83 -
•
JDBC プロバイダーが追加されたことを確認してください。確認ができたら構成の保存を実施して
作成は完了です。メッセージ・ボックス内にある［保存］のリンクをクリックし変更を構成情報に保存
します。
図 3-101
JDBC プロバイダーの作成： マスター構成へ保存
図 3-102
JDBC プロバイダーの作成： JDBC プロバイダーの確認
- 84 -
3-4-4 J2C 認証データ設定
Java プログラムのコーディングにおいて、getConnection( )メソッドの引数としてユーザーID/パスワード
を渡す場合には、データ・ソースの定義情報中にユーザーID/パスワードを含める必要はありません。
しかし、getConnection( )メソッドにおいて引数を渡さない場合や、WAS のアプリケーション・セキュリテ
ィー機能を採用する場合には、データ・ソース側に認証情報(ユーザーID/パスワード)を定義しておく必
要があります。WAS では、リソース接続時の認証情報の参照先として、｢J2C 認証エイリアス｣を使用しま
す。
J2C 認証エイリアスとは、あるリソースに対して接続を行うユーザーの、ユーザーID およびパスワード
を定義するためのスペースです。WAS では、あるリソースに接続する際、このエイリアス経由で、接続ユ
ーザーの情報を取得する仕組みをとっています。
リソースに接続するユーザーの ID／パスワードを指定するための｢エイリアス｣をあらかじめ作成してお
き、リソースの定義時には、認証のためのユーザー情報としてこのエイリアスを指定します。実行時、リソ
ースへの接続のための認証が発生した際は、このエイリアスに定義されているユーザーID／パスワード
が参照されます。
ここでは、J2C 認証エイリアスを作成するためのステップを説明します。
1). 管理コンソールのツリー・ビュー上で、［セキュリティー］→［管理、アプリケーション、およびインフ
ラストラクチャーの保護］をクリックします。
2). ［認証］の下の、［Java 認証・承認サービス］→［J2C 認証データ］をクリックします。
図 3-103 J2C 認証データの設定： J2C 認証データへのリンク
- 85 -
3). [新規作成]をクリックし、一般プロパティーを編集します。終了したら［OK］をクリックします。
図 3-104
J2C 認証データの設定： プロパティの編集
別名：別名の表示名。データ・ソースからエイリアスを指定する際にこのフィールド名を指定
します。
ユーザーID：データベースの接続ユーザー名
パスワード：上記ユーザーID のパスワード
説明：このエイリアスについての説明を記述します。
4). リストに新規作成した別名が追加されていることを確認したら、メッセージ内の［保存］のリンクを
クリックします。
図 3-105
J2C 認証データの設定： 保存メッセージ
- 86 -
3-4-5 データ・ソース設定
JDBC プロバイダーを作成したら、次に、バックエンド・データ・ストアにアクセスするデータ・ソースを作
成する必要があります。データ・ソースは、アプリケーションとデータベース間のトランザクションを実行す
るのに必要な、プールされた接続セットと考えてください。
3-4-5-1 データ・ソースの種類
WAS V７.0 では、V7.0 標準のデータ・ソースと、WAS V4 のデータ・ソースの二種類をサポートしてい
ます。これら 2 つのデータ・ソースでは、それぞれサポートする EJB のバージョンが異なります。
Enterprise JavaBean (EJB) 1.X 仕様または Java Servlet 2.2 仕様を使用している場合は、バージョン
4 データ・ソースが必要です。V4 のデータ・ソースが現行のバージョンでも引き続き残されている理由
は、前のバージョンの J2EE アプリケーションの移行を前提とした互換性のためです。これにより前のバ
ージョンの WAS 上で稼動させている既存 EJB がある場合には、コードの変更を最小限にとどめて再利
用することができます。
3-4-5-2 データ・ソース作成
1). 管理コンソールで、[リソース]→[JDBC] →[データ・ソース]を選択します。
2). データ・ソースの有効範囲を選択した後、［新規作成］をクリックします。
図 3-106 データ･ソースの作成： 有効範囲の設定と新規作成ボタン
- 87 -
3). 新規データ・ソース作成の画面に移ります。作成は以下の四つのステップからなります。
•
ステップ 1 基本データ・ソース情報を入力します。具体的にはデータ・ソース名と JNDI 名です。
J2C 認証データの設定を行なっていない場合は、データ・ソース作成ウィザードを中途で破棄して
認証データ設定画面に移ることもできます。
図 3-107 データ･ソースの作成： 基本データ・ソース情報の入力
•
ステップ 2 JDBC プロバイダーを選択します。ここから新規に作成することも可能です。
図 3-108 データ･ソースの作成： JDBC プロバイダーの選択
- 88 -
•
ステップ 3 データ・ソースのプデータベース特定プロパティを入力します。
まず、[データベース名]欄にこのデータ･ソースと紐づけるデータベース名を入力します。[ドライバー・タ
イプ]欄に JDBC ドライバーの Type を指定します。[サーバー名]欄は、ドライバー・タイプが 4 のときの
み指定します。データベース・サーバーの TCP/IP アドレスまたはホスト名を入力します。[ポート番号]
欄は、データベース接続で使用するポート番号を指定します。
図 3-109 データ･ソースの作成： プロパティの入力
•
ステップ 4 セキュリティー別名を構成します。
「コンポーネント管理認証別名」 ではドロップダウン・リストを使用して、既存のコンポーネント管理認証
別名を選択します。新規の別名を作成するには、リンク「グローバル J2C 認証別名」をクリックします。
リンクを利用する場合はデータ・ソース・ウィザードが終了し、管理コンソールが起動して J2C 認証デ
ータ・パネルが表示されます。J2C 認証データの新規作成方法については、「3-4-4J2C 認証データ設
定」を参照ください。
図 3-110 データ･ソースの作成： セキュリティー別名の入力
- 89 -
•
ステップ 5 要約が表示されますので、設定を確認のうえ[終了]をクリックします。
図 3-111 データ･ソースの作成： 要約の確認
- 90 -
3-4-6 テスト接続
作成した JDBC プロバイダー、データ・ソースを使用してデータベースに接続できることを確認します。
本テストの実施前に、データベースの起動が必要です。DB2 のサービスが稼動していることを確認して
ください。テスト接続は管理コンソールからボタン操作だけで行うことができます。［リソース］→［JDBC］
→［データ・ソース］→［DataSource_name］を開きます。データ・ソースを定義し保存をした後、デー
タ・ソース横のチェックボックスをチェックします。［テスト接続］ボタンをクリックします。これにより、デー
タ・ソース定義のパラメーターが正しいかどうかを確認できます。
図 3-112 テスト接続： テスト接続ボタン（データソース画面）
テスト接続が成功した場合、以下の出力メッセージが表示されます。
図 3-113 データ･ソースの作成： 接続成功メッセージ
- 91 -
なお、［リソース］→［JDBC］→［データ・ソース］にもテスト接続ボタンがあります。
図 3-114 テスト接続： テスト接続ボタン（データ・ソース一覧画面）
- 92 -
3-4-7 UNIX、Linux 環境での設定
DB2 UDB に接続するためには、DB2 独自の環境変数を設定する必要があります。
setupCmdLine.sh の編集
WAS において提供される、環境変数を設定するためのシェル［setupCmdLine.sh］に以下の行を追
加します。DB2 を使用している場合は、db2profile スクリプトを実行する必要があります。 この
setupCmdLine.sh スクリプトは、<Profile_root>/bin ディレクトリーにあり、次のように入力して呼び出しま
す。
if [ -f /home/〈db2_instance_owner〉/sqllib/db2profile ]; then
. /home/〈db2_instance_owner〉/sqllib/db2profile
fi
その他、各 DB ベンダー固有の設定については、下記の InformationCenter の記載を参照ください。
WAS V7.0 InformationCenter「ベンダー固有データ・ソースで最低限必要な設定」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/a
e/rdat_minreq.html
- 93 -
3-4-8 接続プール
アプリケーション・サーバー上で、アプリケーション間で共用が可能なデータベース接続のプールを
作成することができます。接続プールを利用すると、次回のリクエストが来た時にプールされた接続を再
利用することができるため、データベースへの接続／切断にかかるオーバーヘッドを減らすことができま
す。接続プールは、データ・ソースまたは接続ファクトリーに個々に作成され、これを利用することで、デ
ータベース接続を行う Web アプリケーションの応答時間を改善することができます。データベースの接
続を効率よく使用する上で、接続プールの各プロパティーの値を適切な値に設定することがきわめて重
要になります。
3-4-8-1 接続プールの管理
WAS では、指定された設定に従って、以下のように接続プールの管理が行われます。
ユーザー(サーブレット／EJB)からの接続要求（getConnection）に対して、
プール内に現在使用されていない接続が存在していればこれを渡します。
(要求が共用可能接続に対するものである場合、同じ共用プロパティーを持つ接続がすで
に他ユーザーにより使用されていれば、その接続を共用します。)
プール内に現在使用されていない接続がなく、かつプール内の接続が最大接続プール・サ
イズ以下であれば新規の接続を作成し、これを渡します。
(要求が共用可能接続に対するものであり、同じ共用プロパティーを持つ、すでに使用中の
共用可能接続がない場合、または、要求が共用不可能接続に対するものである場合も、
新規の接続が作成されます)
プール内に現在使用されていない接続がなく、かつプール内の接続が最大接続数に達し
ていれば、ユーザーの要求は待機させられます（最大で[接続タイムアウト]で指定された秒
数まで）。
•
ユーザーからの接続終了(close)の要求に対して、
接続をプールに戻します（この時点では切断はしません）。
(その時点で接続が共用されている場合、接続はプールに戻されません。接続がプールに
戻されるのは、接続への最後の参照がアプリケーションによって close され、トランザクショ
ンが終了した後だけです。)
トランザクション終了後、接続が閉じてプールへの接続の戻りが無視されることがありま
す。この状態は、プール内の接続の 1 つが失効したと見なされた場合に起こります。接続
は、データ・ストアへの接続に使用できなくなると、失効したと見なされます。例えば、デー
タ・ストア・サーバーがシャットダウンされると、その接続は失効したとマークされます。接続
が失効とマークされると、デフォルトの設定ではプール全体が空にされます (あるいは、失
敗した接続のみを消去するように構成を設定できます。)。
•
- 94 -
プール維持スレッドは、定期的に接続の状態をチェックし、プール内の接続数を下記のタイムアウト値に
したがって管理しています。
•
未使用タイムアウトの管理。
最小接続数以上に作られた接続オブジェクトのうち、一定時間使用されていないものに対して
行われます。一定時間使用されずにいたコネクション・オブジェクトは、｢未使用タイムアウト値｣を
過ぎると消却されます。ただし、プール内の接続が最小接続数以下となる場合、接続は保持され
ます。未使用タイムアウトを小さくしすぎると、頻繁にコネクション・オブジェクトの破棄と生成を繰
り返す可能性がありますので、ある程度の時間を確保します。
•
経過タイムアウトの管理。
｢経過タイムアウト値｣を過ぎると、最小接続数の設定値にかかわらず、すべての接続が破棄さ
れます。
Servlet/EJB
Servlet/EJB
接続タイムアウト
Servlet/EJB
Servlet/EJB
(割り当て可能な接続が無く、
アプリケーションが待ち状態に
なったまま、接続タイムアウト値
に設定した時間が経過すると、
Exceptionがスローされる)
Servlet/EJB
Servlet/EJB
接続
getConnection()
未使用タイムアウト
最大接続数
(最大接続数の値が 0
の場合は、接続は無限
に作成される)
接続
経過タイムアウト
接続
最小接続数
接続プール
接続
図 3-115 プール維持スレッドの接続管理
プール維持スレッドの実行時間の間隔は、「リープ時間｣というプロパティーに設定します。この値は、
｢未使用タイムアウト｣や｢経過タイムアウト｣の値より短く設定してください。リープ時間の間隔は、短けれ
ば短いほど｢未使用タイムアウト｣と｢経過タイムアウト｣の設定値の精度は高くなりますが、あまり間隔が短
いと、プール維持スレッドの実行回数が増え、パフォーマンスを低下させることになります。
- 95 -
3-4-8-2 接続プールの設定値の変更
接続プールの設定値の変更方法は以下のとおりです。ここでは標準のデータ・ソースについての設
定を見ていくことにします。
1). 管理コンソールで、[リソース]→[JDBC] →[データ・ソース]を選択します。
2). 追加プロパティーの [接続プール・プロパティー]を選択します。
図 3-116 接続プールの設定： 接続プール・プロパティ画面へのリンク
- 96 -
3). 一般プロパティーを必要に応じて編集します。ここでは、接続プール内のコネクションに関する設
定を行います。編集が終了したら、[OK]をクリックします。
図 3-117 接続プールの設定： 接続プールのプロパティ設定
項目
接続タイムアウト
内容
使用中の接続が最大接続数に達しているところに新規接続要求がきた
際、待機する時間
最大接続数
プールに維持できる物理接続の最大数
最小接続数
プールに維持できる物理接続の最小数
リープ時間
プール維持スレッドの実行間隔
未使用タイムアウト
未使用、またはアイドルの接続が破棄されるまでの時間の間隔
経過タイムアウト
物理接続が破棄されるまでの時間の間隔
パージ・ポリシー
不整合な接続や致命的エラーが検出された際に接続をパージする方法
で、値は「EntirePool」または「FailingConnectionOnly」が選択可能
最大接続数を 0 に設定した場合、物理接続は無制限となり接続タイムアウトを設定しても無効となりま
す。また、未使用タイムアウトを設定した場合未使用接続は最小接続数になるまで破棄されます。ただ
し、経過タイムアウトを設定している場合は未使用タイムアウトにかかわらず、経過タイムアウトを経過し
た接続が破棄されます。パフォーマンス向上の面から、未使用タイムアウト値はリープ時間より長く設定
します。プール維持スレッドを使用不可にするにはこのリープ時間に０を設定してください。
- 97 -
3-5 セッション管理
ここでは、セッションとは何か、またセッション・トラッキングにはどういったものがあるかや、セッション・パ
ーシスタンスの設定について説明します。
3-5-1 セッション
セッションとは、同じブラウザを使って、同じユーザーからサーブレットに対して出される一連の要求の
ことです。ブラウザとサーブレット間の通信は HTTP で行われますが、HTTP プロトコルはステートレスな
プロトコルですので、クライアントから Web サーバーへのリクエストがあるたびに、クライアントとサーバー
間でコネクションを確立し、リクエストに対するレスポンスが行われるとコネクションが切断されます。この
ため、通常は Web サーバーに対する複数のリクエストが同一クライアントから送信されたものであるかど
うかをサーバー側で判断することができません。そこで、同一ブラウザ、同一ユーザーからの複数のリク
エストを関連付けて管理する仕組みが必要となります。この仕組みがセッションです。Web コンテナー
内で稼働するアプリケーションは、セッションを利用して個々のユーザーを管理します。
セッションはセッション ID を利用して管理されます。セッション ID は各ユーザーを一意に識別できるよ
うに割り振られます。ユーザーから初めのリクエストが来たときに、サーバー側はレスポンスにセッション
ID をセットして返します。ユーザーは次のリクエストではそのセッション ID を一緒に送り返します。アプリ
ケーション・サーバーはユーザーからの送られたセッション ID をサーバー内に保持されているセッショ
ン・オブジェクトと照合して、ユーザーを識別します。
セッション・オブジェクトはセッション ID ごとにサーバー側で作成、保存、破棄され、その中にはユー
ザーごとの情報が格納されています。
セッション・オブジェクト
のライフサイクル
作成
最初のリクエスト
セッションID:
ABCD
セッションID
＝ABCD
セッションID
情報追加
＝ABCD
情報入力
セッションID
ユーザーA
＝ABCD
WAS
破棄
セッション終了
またはタイムアウト
図 3-118 セッションの仕組み
- 98 -
セッションID:
ABCD
ユーザーA
の情報
セッションID:
ABCD
ユーザーA
の情報
3-5-2 セッション・トラッキングの種類
ユーザーとサーバー間でセッション ID の受け渡しを行うセッション・トラッキングには、Cookie、URL 再
書き込み、SSL ID という方法があります。セッション ID のトラッキングは主に Cookie を使用して行いま
す。Cookie が使用不可能な場合(たとえば携帯電話など)に URL 再書き込み、または SSL ID を使用し
ます。なお、SSL ID は WASV7.0 から非推奨の機能となりました。既に SSL ID を使用している場合、
Cookie、URL 再書き込みを使用するよう構成変更することが可能です。
•
Cookie
Cookie とはブラウザ側でデータを保存する仕組みであり、ブラウザは HTTP リクエストを送信す
る際には毎回 Cookie も一緒に送信します。サーバーはこの Cookie にセッション ID を格納しま
す。 Cookie には「キーワード＝値」の形でデータが保存されます。複数のキーワードを設定する
ことが可能です。J2EE アプリケーションではセッション・トラッキング用のキーワードはサーブレッ
トの仕様で JSESSIONID と決められています。Cookie によるセッション・トラッキングを有効にす
るには、管 理コ ンソールで［ サ ー バ ー］→ [サ ーバ ー･ タイ プ]→［WebSphere Application
Server］→［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セッ
ション管理］を開き、「Cookie を使用可能にする」にチェックをつけ保存します。
•
URL 再書き込み
リクエストの際 URL の後にセッション ID を付加して送信する方法です。Cookie が使用できないと
きに有効な手段ですが、URL の後ろにセッション ID が見えてしまうという欠点があります。また、
Cookie を使用したアプリケーションからはアプリケーションの修正が必要です。クライアントが
Cookie を受け入れることができない場合、Cookie をセッション・トラッキング・メカニズムとして使
用できないので、かわりに使用されます。URL 再書き込みによるセッション・トラッキングを有効に
するには、管理コンソールで、［サーバー］→[サーバー･タイプ]→［WebSphere Application
Server］→［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セッ
ション管理］を開き、「URL 再書き込みを使用可能にする」にチェックをつけ保存します。
•
SSL（Secure Sockets Layer） ID
前述したとおり、WAS V7.0 から非推奨となりました。ただし、SSL ID を使用可能と設定した場
合、Cookie、URL 再書き込みよりも優先して使用されます。この方法は、SSL 情報をセッション ID
として使用します。サポートされているのは IBM HTTP Server および iPlanet Web サーバーのみ
です。アプリケーションの修正は必要ありません。SSL ID によるセッション・トラッキングを有効に
するには、管理コンソールで、［サーバー］→[サーバー･タイプ]→［WebSphere Application
Server］→［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セッ
ション管理］を開き、「SSL ID トラッキングを使用可能にする」にチェックをつけ保存します。
- 99 -
WAS のセッション管理に関する構成は、管理コンソールのセッション管理で行います。セッション管理
設定は、アプリケーション・サーバー（Web コンテナー）、エンタープライズ・アプリケーション、Web モジュ
ールの 3 つのレベルで設定できます。デフォルトでは各レベルの設定は上位レベルの設定を引き継ぎ
ます。例えば、Web コンテナー内のアプリケーションおよびその Web モジュールは各レベルで変更を加
えない限り、Web コンテナーの設定を引き継ぎます。
WebSphere Application Server
(Web コンテナー)
エンタープライズ・アプリケーション
Web モジュール
図 3-119 セッション管理設定の有効範囲
設定するレベルを選択してから、管理コンソールを使用してセッション管理画面を開きます。
アプリケーション・サーバー（Web コンテナー）を選択した場合
［ サ ー バ ー ］ → [ サ ー バ ー ･ タ イ プ ] → ［ WebSphere Application Server ］ →
［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］→［セッション管
理］
エンタープライズ・アプリケーションを選択した場合
[アプリケーション]→[WebSphere エンタープライズ・アプリケーション]→[Application_name]
→[Web モジュール・プロパティ]→[セッション管理]
Weｂモジュールを選択した場合
[アプリケーション]→[WebSphere エンタープライズ・アプリケーション]→[Application_name]
→[関連項目]→[Weｂモジュール]→[Webmodule_name]→[追加プロパティー]→[セッション
管理]
セッション管理をクリックすると次のセッション管理画面が表示されます。ここでは、セッション・トラッキン
グ・メカニズムの指定、最大セッション・カウントの設定、オーバーフローの許可、セッション・タイムアウト
のなどがあります。
- 100 -
図 3-120 セッション管理設定画面
セッション管理のオーバーライド
エンタープライズ・アプリケーションと Web モジュールのレベルの場合のみ表示されます。この
欄にチェックをつけると上位レベルの設定が上書きされ、有効になります。
セッション・トラッキング・メカニズム
SSL ID、Cookie、URL 再書き込みのうちどれを使用してセッション・トラッキングを行うか指定し
ます。デフォルトは Cookie です。複数指定も可能でその際の優先順位は、SSL ID、Cookie、
URL 再書き込みです。URL 再書き込みを選択した場合は該当するアプリケーションのコードが
URL 再書き込みに対応していることが前提です。
オーバーフローの許可
メモリー内の最大セッション・カウント
メモリー内に保持できるセッションの最大数を指定します。オーバーフローを許可している場合、
最大数を超えるとメモリー内に新たにセッションを格納する領域がとられます。この場合、無限
にセッションが作成されます。オーバーフローの許可を適用しない場合は最大数を超えてセッシ
ョンを張ろうとするとアプリケーションにエラーが返ります。ただし、これらはパーシスタンスを使
用した場合は異なる意味になるので、詳しくは Information Center をご参照ください。
WAS V7.0 Information Center「セッション管理設定」：
- 101 -
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.base.doc/
info/aes/ae/uprs_rsession_manager.html
セッション・タイムアウト
セッションが使用されなくなってから無効になるまでの時間を設定します。セッションが
タイムアウトになるとサーバーが保持セッション・オブジェクトが破棄され、メモリが解
放されます。「セッション・タイムアウト｣の項目はパフォーマンス・チューニングの観
点からも重要な項目です。
セキュリティー統合
セキュリティー統合を使用可能にするかどうかを指定します。セキュリティー統合が使用
可能な場合、セッション・マネージャーはユーザーの ID を HTTP セッションに関連付け
ます。
セッション・アクセスのシリアライズ
並行セッション・アクセスを禁止するかどうかを指定します。
- 102 -
3-5-3 セッション・マネージャー
セッション・マネージャーは Web モジュール単位、またはエンタープライズ・アプリケーション単位で設
定され、セッション情報の管理作業を行うコンポーネントです。Servler2.4 の仕様ではセッション・スコー
プは Web モジュール単位です。WAS では独自の機能としてエンタープライズ・アプリケーション単位で
のセッション情報の共有をサポートしています。ただしエンタープライズ・アプリケーション単位でのセッ
ション情報の共有を行う場合には、Web モジュール単位でのセッション・マネージャーの設定は行えませ
ん。
セッション・マネージャーの行うセッション管理作業には、セッション ID(String)とセッション・オブジェクト
(HttpSession)との紐付けやセッション・オブジェクトの外部 DB や他の JVM へのコピーなどが含まれま
す。また WAS のセキュリティー機能を使用している場合は、認証されたユーザーID とセッション ID との
間の紐付けも行います。
3-5-4 セッション・パーシスタンス設定
セッション情報を共有する機能として、データベースにセッション情報を格納して共有する「データベ
ース」とアプリケーション・サーバーにセッション情報を格納して共有する「メモリー間複製」があります。メ
モリー間複製は JVM 上に格納されているセッション情報をほかの JVM 上にコピーすることによりセッショ
ン情報を共有します。この機能は WAS ND 構成 でのみ使用可能で、WAS Base 構成では使用できま
せん。WAS Base・Express ( ND の Base プロファイルを含む) を使用したセッション・データベースはサ
ポート対象ですが、WAS Base・Express のフェイルオーバーとロードバランスは 2 台までのサポートとなり
ます。
以下の表に、セッション・パーシスタンスの有無とセッション・パーシスタンスの方法の違いによるメリッ
ト・デメリットをまとめます。また、セッション・パーシスタンスを行う場合、セッション情報をコピーするタイミ
ングの設定として、定期的にコピーを行う時間基準の設定とサーブレット・サービスの終了ごとにコピー
を行う設定を選択することが可能です。
セッション・パーシスタンスを行う場合、データをセッション DB や JVM に格納するのでセッション・オブ
ジェクトはシリアライズ可能でなければなりません。セッション・パーシスタンスを行う場合にセッション・オ
ブジェクトをシリアライズ可能にしないと”java.io.NotSerializableException”が発生します。
表 3-4 セッション・パーシスタンスの方法別機能マトリクス
セッション・パー
シスタンス設定
なしの場合
障害時セッショ
ン情報の復旧
パフォーマンス
メモリー使用量
DB の使用
セットアップ容
易性
データベース
サーブレット・サ
時間基準
ービスの終了
メモリー間の複製
サーブレット・サ
時間基準
ービスの終了
×
△
◎
△
◎
◎
○
－
○
○
必要
△
○
必要
○
△
不要
△
△
不要
－
△
△
○
○
セッション・パーシスタンスの設定は、デフォルトで使用可能になっていません。分散環境設定で分散
セッションを「データベース」または「メモリー間複製」に設定し、さらに各設定画面で必要な項目を設定
します。
- 103 -
3-5-4-1 DB によるセッション・パーシスタンス
デフォルトではセッション・データは JVM のヒープ内に格納されて管理が行なわれます。データベー
スによるセッション・パーシスタンス設定を行うことで、セッションをセッション管理用のデータベースに格
納することが可能になり、データベースによるセッション管理が行われます。セッション管理方法をデー
タベースとすると、指定先のデータベースにデータ保存用の「Sessions」というテーブルが自動的に作成
されます。
セッション・パーシスタンスを設定することにより、WAS の計画的なシャットダウン時や障害時でも、セッ
ション・オブジェクトを保持することができるため、セッション情報を他のアプリケーション・サーバーへ引
き継ぐことが可能です。セッション・パーシスタンスはこの機能を使用することでアプリケーション・サーバ
ーの障害時においても処理中のサービスを続行することを可能にするというメリットがあります。
その他、チューニング考慮点としてセッション・データベースを使用する場合も SQL 文を発行してデ
ータベースからデータを取ってくるという点では、一般的なデータ・アクセスの考慮点もチューニング・パ
ラメーターとして考える必要がでてきます。WAS の観点からすると、データ・アクセスのチューニング・パ
ラメーターで重要なのは、データ・ソースの接続数設定と preparedStatementCache の設定です。このう
ち、データ・ソースの最大・最小接続数の設定は接続の確立のオーバーヘッドがパフォーマンスに影響
を及ぼすことがありますので必要十分な接続数を確保する必要があります。preparedStatementCache サ
イズの設定に関しては、パフォーマンスの観点から見るとキャッシュの破棄が頻繁に発生していなけれ
ば基本的に変更する必要はありません。変更する場合は発行されると考えれらる SQL の数を見積もり、
それより多い数にします。
データベース・セッション・パーシスタンスのセッション管理機能を構成する手順を以下に示します。手
順内では、アプリケーション・サーバー（Web コンテナー）のレベルを選択しています。
- 104 -
1). 管理コンソールから、［サーバー］→[サーバー･タイプ]→［WebSphere Application Server］
→［ApplicationServer_name］→［Web コンテナー設定］→［Web コンテナー］を開きます。追
加プロパティーの［セッション管理］をクリックしセッション管理のワーク・スペース内の[追加プロ
パティー]→［分散環境設定］を開きます。
2). 分散セッションから［データベース］のリンクをクリックします。
図 3-121 DB によるセッション・パーシスタンス設定： 分散セッションの実現方法の指定
- 105 -
3). 「データ・ソース JNDI 名」やそれに接続するための「ユーザーID」「パスワード」などを指定し、入
力を終えたら ［OK］ボタンを押します。 以上を、セッション共有する全クラスター・メンバーに設
定します。
図 3-122 DB によるセッション・パーシスタンス設定： データベース・プロパティの設定
データ・ソースの JNDI 名
既存のデータベースを指定するデータ・ソースの JNDI 名を指定します。この JNDI 名は新規で
データ・ソースを作成した際に指定したものを使用します。
ユーザーID
データベースにアクセスするためのデータベースのユーザーID を指定します。
パスワード
データベースにアクセスするためのデータベースのパスワードを指定します。
DB2 行サイズ
データベースに DB2 を使用した場合のセッション・パーシスタンス設定に特有なパラメーターと
して、データベースのバッファ･プールの設定があります。
データベースに書き込みを行なうとき、いきなりディスクにデータを書き込むことはありません。
その前にバッファ･プールと呼ばれるメモリー上にキャッシュされ、そのあと実際にディスクへの書
き込みが行なわれます。バッファ・プールにキャッシュされている間は、外部（ここでは WAS）から
データの要求でキャッシュ・ヒットしたものは、このバッファ･プールからデータが返されるため、本
来発生するはずだったディスク I/O の時間だけパフォーマンスが向上します。
DB2 UDB において、バッファ･プールのバッファ･サイズはデフォルトで 4KB ですが、設定によ
り 8KB,16KB,32KB から選択することが可能になっています。大量のデータをデータベースに書
き込むようなケースでは適切なバッファ・プール・サイズを設定することでパフォーマンスを最適
化することが可能になります。UDB のページ・サイズの変更方法については Information
Center を参照下さい。パフォーマンスの向上は、セッション・オブジェクトの大きさに合わせて
- 106 -
DB2 側のページ・サイズを変更することで図ることが可能です。(セッション・オブジェクト大きさ)
≦ (ページ・サイズ) とすればパフォーマンスが向上します。
WAS V7.0 Information Center「DB2 セッション・データベースの表スペースおよびページ・サイ
ズの構成」：
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/inf
o/ae/ae/tprs_db2t.html
複数行スキーマを使用する
セッション・データをデータベースで管理するとき、データベースのテーブルにデータをどのよ
うに書き込むかの設定を行います。単一行スキーマでは、セッション・オブジェクトに格納されて
いる属性の数に関係なくひとつの「データ」として扱われますが、複数行スキーマは属性ごとに
分割してオブジェクトを複数の「データ」として扱います。デフォルトでは、アプリケーション・デー
タのインスタンスはデータベース表内の単一行にマップされますが、この欄にチェックをつけるこ
とによって、アプリケーション・データの各インスタンスをデータベース内の別々の行に置き、各
セッション当たりの保存データ量を増やすことができます。
下表に単一行スキーマ / 複数行スキーマを選択した時の利点･欠点についてまとめます。
表 3-5
DB によるセッション・パーシスタンス： 単一行スキーマと複数行スキーマとの比較
単一行スキーマの利点
・一度のレコードの読み・書きだけですべての値を読み･書きでき
ます。
・セッション・データによって占有されるデータベースのスペースを
小さくできます。
単一行スキーマの欠点
複数行スキーマの利点
・2MB を超えるセッション・データを扱うことができません（1 行あ
たり保存できるデータは 2MB です）。
・2MB 以上のセッション・データを扱えます（ただし、保存する各セ
ッション属性は 2MB 以内にする必要があります）。
・セッション内の属性を個別に読み・書きを行なうことができるよう
になるためデータの直列化処理を減らすことができます。
複数行スキーマの欠点
・複数行読み取りによるオーバーヘッドが単一行スキーマの場合
より大きくなります（よって、セッション・データのサイズが小さい場
合は単一行スキーマを選択）。
単一行スキーマと複数行スキーマの選択のポイントはデータの直列化処理と、DB の読み取
り･書き込み処理のどちらがシステムのパフォーマンスに影響を及ぼすかという点です。
その他にセッション・オブジェクトの大きさも選択ポイントとなります。セッション・データが２MB
を超える場合は複数行スキーマを選ばなくてはいけませんが、それ以外の場合ではどちらが最
適かはアプリケーションがどのようにセッション・オブジェクトを使用するかに依存します。以下に
例を挙げます。
全体のセッション・サイズが小さいケースでは：
単一行スキーマを選択することで DB 側の複数行処理によるパフォーマンス低下を回避できま
す。
- 107 -
セッション内の一部のデータにのみアクセスが必要なケースでは：
複数行スキーマを選択し、かつ「書き込み内容」を「更新されたデータのみ」に指定しておけば必
要なデータのみ直列化が行なわれますので、無駄な直列化処理を行なわない分パフォーマンス
の向上が期待できます。
4). チューニング・パラメーターを変更する場合は、「分散環境設定」の［カスタム・チューニング・パラ
メーター］をクリックし、設定を選択するか、設定をカスタマイズします。詳しくは、3-5-4-3 チュー
ニング・パラメーター設定）」をご参照ください。
5). ［適用］をクリックします。
6). ［保存］をクリックし変更を保存します。 次画面では［ノードと変更を同期化］にチェックがついて
いることを確認して［保存］ボタンを押します。同期化が完了のメッセージが出力されたら［OK］
ボタンを押します。
3-5-4-2 メモリー間複製
メモリー間複製は JVM 上に格納されているセッション情報を他の JVM 上にコピーすることによりセッシ
ョン情報を共有します。メモリー間複製の構成にはピアツーピアとクライアント/サーバーの２つの構成が
可能です。以下にそれぞれの構成について説明します。
メモリー間トポロジー
ピアツーピア
各々のアプリケーション・サーバーは、自身のセッション情報だけでなく、他サーバーのセッション情報
を保持します。アプリケーション・サーバーに障害が発生すると、プラグインはレプリカのあるサーバーに
リクエストを割り振る、ホット・フェイルオーバーが提供されます。
全てのサーバー
のモード設定は
「クライアントと
サーバー両方」
ApplicationServer1
ApplicationServer1
ApplicationServer1
ApplicationServer1
Localの
セッション情報
AppServer2
のセッション情報
全部の AppServerの
セッション情報
ApplicationServer2
ApplicationServer2
ApplicationServer2
ApplicationServer2
Localの
セッション情報
AppServer3
のセッション情報
全部の AppServerの
セッション情報
ApplicationServer3
ApplicationServer3
ApplicationServer3
ApplicationServer3
Localの
セッション情報
AppServer 1
のセッション情報
Replication Domain 1
( 単一レプリカ)
全部の AppServerの
セッション情報
Replication Domain 2
( ドメイン全体)
図 3-123 HTTP セッションメモリー間複製におけるピアツーピアトポロジー
- 108 -
全てのサーバー
のモード設定は
「クライアントと
サーバー両方」
ピアツーピアトポロジーは、全てのアプリケーション・サーバーのモードを「クライアントとサーバー両
方」とすることで実現できます。
左の図は複製ドメイン設定において、「単一レプリカ」を設定しています。この場合、図のようなセッショ
ン情報の保持の仕方になり、１つのセッション・データに関するレプリカが他サーバー上に 1 つ存在しま
す。
レプリカを受ける予定のサーバーに障害が発生すると、正常なサーバーがその役割を引き継ぎます。
障害サーバーが復活した場合、これまで作られたレプリカはそのまま引き継いだサーバーが保持します
が、新たなセッション情報に関しては最初の予定通り復活したサーバーにデータは複製されます。
本来のセッション・データを保持するサーバーに障害が発生すると、その役割はレプリカサーバーに引
き継がれますが、引き継がれたあとレプリカサーバーに障害が発生すると（2 重障害）そのデータは失わ
れます。
右の図は複製ドメイン設定において、「ドメイン全体」を設定しています。この場合、図のようなセッショ
ン情報の保持の仕方になり、１つのセッション・データに関するレプリカが他全てのサーバー上に存在し
ます。この場合、2 重障害にも対応できますが、メモリーリソースを多く取られることになります。
メモリー間トポロジー
クライアント/サーバー
クライアント/サーバーの構成ではすべてのアプリケーション・サーバーのセッション情報を持つアプリ
ケーション・サーバーとセッション情報の保持のみを専門に行うアプリケーション・サーバーに役割を分
離します。データベース構成のデータベースをアプリケーション・サーバーに置き換えたイメージとなりま
す。この構成の場合、クライアントにサービスを提供するサーバーだけを同一のクラスター・メンバーに登
録すればよいことになります。これによりセッション情報の保持を専用に行うアプリケーション・サーバー
がクライアントに対してサービスを提供することはなくなります。またこれらのアプリケーション・サーバー
はセッション情報を共有するため、同一の内部複製ドメインに属している必要があります。複製モードは
クライアントにサービスを提供するアプリケーション・サーバーは「クライアントのみ」とし、セッション情報
の格納のみを行うアプリケーション・サーバーは「サーバーのみ」を設定します。このような構成を組むこ
とによりアプリケーションの処理（サービス）を実行するサーバーから、セッション複製による負荷を軽減
することができます。
ApplicationServer 1
ApplicationServer 1
モード設定は
「クライアントのみ」
Localの
セッション情報
ApplicationServer 2
ApplicationServer 2
モード設定は
「クライアントのみ」
Localの
セッション情報
ApplicationServer 4
ApplicationServer 4
全部のAppServerの
セッション情報
ApplicationServer 3
ApplicationServer 3
モード設定は
「クライアントのみ」
Localの
セッション情報
Replication Domain 1
(単一レプリカ)
図 3-124 複製ドメイン設定における単一レプリカ
- 109 -
モード設定は
「サーバーのみ」
上図は複製ドメイン設定において、「単一レプリカ」を設定しています。クライアント上のレプリカはサー
バー上に全て保持されます。サーバーの障害に対応するためには、レプリカの数を 2 とし、サーバーを
もう 1 台作成することで SPOF は回避されます。
メモリー間複製の前提
メモリー間複製の設定を行う前提として、クラスターと内部複製ドメインの構成が必要となります。クラス
ターと内部複製ドメインに関しては以下の様な観点で設定を行います。
•
•
メモリー間複製を行うサーバーは必ず同じ内部複製ドメインに属している必要があります
クライアントに対して同一のセッション情報を提供する複数のアプリケーション・サーバーは同一ク
ラスターに属している必要がありますが、メモリー間複製を行う為だけの観点では、特に同じクラ
スターであることは必須条件ではありません（例：クライアント/サーバー構成のとき）
複製ドメイン
複製ドメインとは、クラスター配下のアプリケーション・サーバー間でデータ複製を行うアプリケーショ
ン・サーバーの集合です。情報を共用する必要のあるすべてのアプリケーション・サーバーは、同じ複製
ドメインに存在する必要があります。複製ドメイン内のアプリケーション・サーバー間でデータを複製する
機能をデータ複製サービスと言い、HTTP セッションのメモリー間複製もデータ複製サービスを使用しま
す。
複製ドメインの設定では、1 つのアプリケーション・サーバーがいくつのデータ複製を別のアプリケー
ション・サーバーに作成するかを指定します。以下の 3 つの指定から選択できます。
•
単一レプリカ
1 つのデータに対して、複製ドメイン内に 1 つのデータ複製を保持します。WAS V7 のデフォルト
で使用されます。
•
ドメイン全体
1 つのデータに対して、複製ドメイン内のすべてのサーバーがデータの複製を保持します。
•
指定
1 つのデータに対して、複製ドメイン内に保持するデータ複製の数を指定します。
単一レプリカとドメイン全体のデータ複製の概要は下記の図のようになります。
単一レプリカ
ドメイン全体
複製ドメイン
複製ドメイン
アプリケーション・
サーバー1
データ複製
サービス
データ複製
サービス
アプリケーション・
サーバー2
アプリケーション・
サーバー4
データ複製
サービス
アプリケーション・
サーバー1
データ複製
サービス
データ複製
サービス
データ複製
サービス
アプリケーション・
サーバー3
アプリケーション・
サーバー2
図 3-125 複製ドメイン
- 110 -
アプリケーション・
サーバー4
データ複製
サービス
データ複製
サービス
アプリケーション・
サーバー3
複製ドメインの作成・設定変更は管理コンソールで、[環境]→[複製ドメイン]→
[ReplicationDomain_name]または[新規作成]を選択します。
図 3-126 複製ドメインの設定
レプリカの数以外に、複製ドメインの設定では、以下の設定を変更することが可能です。
•
要求タイムアウト
別のアプリケーション・サーバーの情報を要求する際に、その情報が存在しないものと見なして要
求を断念するまでの待機時間です。デフォルト値は 5 秒です。
•
暗号化タイプ
複製したデータを別のネットワーク領域に転送する際に使用する暗号化のタイプを指定します。オ
プションには、[なし]、[DES（Data Encryption Standard）]、および[3DES]があります。デフォル
トは[なし]です。[DES]オプションと[3DES]オプションは、アプリケーション・サーバー・プロセス間
で送信されるデータを暗号化し、プロセス同士を結合するネットワークをより確実に保護します。
ただし、パフォーマンスに影響します。
- 111 -
複製ドメインの設定では、レプリカの数の設定が重要です。HTTP セッションのメモリー間複製を構成
し、[単一レプリカ]を選択した場合には、HTTP セッションのデータが占有するメモリー領域は、メモリー
間複製を構成しない場合の 2 倍占有することになります。[ドメイン全体]または[指定]を選択した場合に
は、複製ドメインに参加するアプリケーション・サーバーの数または指定した数倍のメモリー領域を占有
することになります。また、パフォーマンスの観点からもできる限り、少ない複製の数を指定することが推
奨されます。逆に、[ドメイン全体]または[指定]を選択した場合には、複数のアプリケーション・サーバー
がダウンした場合にも、HTTP セッション・データをリカバリーすることが可能です。
また、垂直クラスターと水平クラスターを合わせて構築するような場合（2 つのアプリケーション・サーバ
ーを起動する筐体を 2 つで、計 4 つのアプリケーション・サーバーでクラスター構成を構築する場合）は
複製ドメインの設定に注意が必要です。全クラスター・メンバーが[単一レプリカ]の複製ドメインを使用す
ると、同一筐体のアプリケーション・サーバーにデータの複製を保持することもあります。この構成で、筐
体障害が発生した場合、セッションのデータが失われてしまうことがあります。これを避けるためには、レ
プリカの数を複数に設定するか、複数の複製ドメインを作成し、同一筐体上で稼動するアプリケーショ
ン・サーバーは異なる複製ドメインを使用するように設定します。
データ複製サービス（Data Replication Service）
データ複製サービスは、DRS（Data Replication Service）とも呼ばれる WAS の内部コンポーネントで
す。データ複製サービス機能は、アプリケーション・サーバー毎に稼動し、お互いに連携することにより、
クラスター配下の複数のアプリケーション・サーバー間におけるデータ複製を可能にします。WAS V7 で
は、データ複製サービスを使用して以下の機能を提供します。
•
HTTP セッションのメモリー間複製
HTTP セッション・オブジェクト生成を実施する Web コンテナー稼動のアプリケーション・サーバー
をクラスター化した際に、アプリケーション・サーバー間でセッション情報のフェイルオーバーを実
施します。HTTP セッションのフェイルオーバーはセッション情報をデータベースに格納することで
も実現できますが、データ複製サービスではすべてメモリー間での複製となります。
•
ステートフル・セッションビーン複製
ステートフル・セッションビーンを使用する EJB コンテナー稼動のアプリケーション・サーバーをク
ラスター化した際に、アプリケーション・サーバー間でステートフル・セッションビーン情報のフェイ
ルオーバーを実施します。詳細は第 1 部 4 章「ワークロード管理、高可用性構成」の章を参照くだ
さい。
•
動的キャッシュの複製
動的キャッシュを生成・保持する Web コンテナー稼動のアプリケーション・サーバーをクラスター
化した際に、アプリケーション・サーバー間でキャッシュ情報の共有を実施します。1 つのキャッシ
ュを複数のアプリケーション・サーバーに保持することで、パフォーマンスの向上が見込めます。
尚、動的キャッシュの複製を行う場合は、使用する複製ドメインのレプリカの数の設定は[ドメイン
全体]を指定してください。詳細は第 2 部 3 章「パフォーマンス管理」の章を参照ください。
基本的には、各複製の種類に応じて、それぞれ異なる複製ドメインで構成する必要があります。例え
ば、HTTP セッションの複製と、動的キャッシュの複製は別の複製ドメインを使用します。しかし、同一の
クラスターで、HTTP セッションのメモリー間複製とステートフル・セッションビーンの複製を構成する場
合は、同じ複製ドメインを使用します。この場合は、同じ複製ドメインを使用することにより、HTTP セッシ
ョンおよびステートフル・セッションビーンの複製されたデータが、確実に同じアプリケーション・サーバー
上に置かれるようにします。
- 112 -
メモリー間複製の設定
メモリー間複製を構成する手順を以下に示します
1). メモリー間複製の設定画面を表示するには［サーバー］→[サーバー･タイプ]→［WebSphere
Application Server］→［Application Server_name］→［Web コンテナー設定］→［Web コンテナ
ー］→［セッション管理］→［分散環境設定］を開きます。
2). ［メモリー間の複製］のリンクをクリックします。
図 3-127
メモリー間複製によるセッション・パーシスタンス設定： 分散セッション実現方法の選択
3). 「構成」タブの項目を設定し、[OK]ボタンを押します。分散環境画面にもどります。
図 3-128 メモリー間複製によるセッション・パーシスタンス設定： 複製モードの選択
- 113 -
複製ドメイン
HTTP セッションが複製される複製ドメインを指定します。
複製モード
このサーバーを実行する必要があるモード (両方、クライアント、およびサーバー) を選択しま
す。モードは、データが送信専用 (クライアント)、受信専用 (サーバー)、またはその両方のいず
れであるかを暗黙的に指定するものです。デフォルトは両方です。
4). チューニング・パラメーターを変更する場合は、追加プロパティーの［カスタム・チューニング・パ
ラメーター］をクリックし、設定を選択するか、設定をカスタマイズします。詳しくは、3-5-4-3 チュ
ーニング・パラメーター設定 114）をご参照ください。
5). [メモリー間複製]のラジオボタンを選択し、[OK]ボタンを押します。
3-5-4-3 チューニング・パラメーター設定
分散セッションのチューニング・パラメーターを設定します。
1). チューニング・パラメーターを変更する場合は、「分散環境設定」の追加プロパティーにある［カス
タム・チューニング・パラメーター］をクリックし、チューニング・パラメータ設定画面に遷移します。
図 3-129 分散セッションのチューニング・パラメータ設定画面
- 114 -
2). チューニング・レベルを選択します。設定をカスタマイズする場合は、必要とする設定に最も近い
定義済み設定のいずれかを選択し、［カスタム設定］をクリックします。
図 3-130
分散セッションのカストマイズ
「書き込み頻度」で設定したタイミングで WAS はセッションオブジェクトを直列化してバイトコードの
データに変換し、データベースまたは、異なる JVM にコピーします。逆にセッション･データを読み込
む際には直列化処理されたデータを WAS が復元する作業が発生します。
「書き込み頻度」には、時間基準とサーブレット・サービスの終了の二種類があります。定期的設定
の場合は時間基準を使用し、時間間隔（たとえば 60 秒など）で設定可能です。ユーザーリクエストの
サーブレット処理の終了毎に書き込みを行う場合はサーブレット・サービスの終了での設定可能で
す。定期的設定を使用した場合には、障害時には最新のセッション・データについては失われる可能
性がありますが、通常時のパフォーマンスは、サーブレット処理毎よりも良いです。
書き込み頻度には、どこまで最新のセッション情報をコピーするかとパフォーマンスのトレードオフ
の関係が成り立ちます。カスタム設定のデフォルトは 10 秒間隔で、更新のあったセッション情報をデ
ータベースまたは異なるメモリーにコピーします。
- 115 -
3-6 トランザクション・サービス
WAS ではトランザクション・マネージャーによってトランザクション・サービスが提供されています。トラ
ンザクション・マネージャーはエンタープライズ Bean(EJB)で設定するトランザクション属性に従って、トラ
ンザクションの有効範囲を管理します。また、トランザクションに対してタイムアウトを設定することで、タイ
ムアウトを迎えたトランザクションをロールバックすることが可能です。この節では、EJB でのトランザクショ
ン属性の設定方法と WAS で設定可能なトランザクション・サービスの各パラメーターについて説明しま
す。
3-6-1 トランザクション属性
EJB では、トランザクション管理を EJB コンテナーに任せる場合（ Container Managed Transaction
(=CMT) ）、コード中にはトランザクション区切りを指定せず、「トランザクション属性」を指定することによ
ってトランザクションの有効範囲を管理します。トランザクション属性は 6 種類あります。ランタイムでは
EJB コンテナーが指定されたトランザクション属性に従い、メソッド呼び出し時点で「トランザクションの開
始」や「メソッド呼び出し元のトランザクション・スコープの引継ぎ」等のトランザクション管理を行います。ト
ランザクション属性はデプロイメント・ディスクリプターに記述します。
3-6-2 デプロイメント記述子への設定
EJB モジュールのデプロイメント記述子でトランザクション属性を設定します。デプロイメント記述子の
設定は、Application Server Toolkit (AST) などのアセンブリー・ツール、または RAD などの開発ツール
を使用して構成します。以下に、RAD を使用したトランザクション属性の設定方法を示します。
1). ［EJB デプロイメント・ディスクリプター］の［Bean］タブを開きます。セッション Bean の場合、トラ
ンザクション・タイプの属性に、［コンテナー］と［Bean］が選択できます。コンテナー管理トランザ
クション（CMT）を使用する場合は、［コンテナー］に、Bean 管理トランザクション（BMT）を使用す
る場合は、［Bean］を設定します。
- 116 -
2). コンテナー管理トランザクションについては、エンタープライズ Bean のビジネス・メソッドにメソッ
ド起動を委任する場合に、コンテナーによるトランザクション有効範囲をどのように管理するかを
構成します。
3). ［アセンブリー］タブを選択し、［コンテナー・トランザクション］のボックスの下にある［追加］ボタン
を押すします。
4). エンタープライズ Bean 選択ウィザードが表示されるので該当する Bean を選び［次へ］を選択し
ます。
- 117 -
5). Bean またはメソッドのリストが表示されますから、それぞれのメソッドに［コンテナー・トランザク
ション・タイプ］を設定し［終了］ボタンを押します。これにより、コンテナー・トランザクションが定義
されます。
- 118 -
3-6-3 トランザクション・サービス設定
トランザクション・サービスは、複数のリソース・マネージャーに対する更新を調整して、データ・トラン
ザクションのアトミック更新（不可分の作業単位として更新）がアプリケーションまたはそのアプリケーショ
ンがデプロイされているコンテナーによって開始および終了されることを保証できるサーバーのランタイ
ム・コンポーネントです。トランザクションは、永続的な更新か、永続的な更新がまったく行われないかの
どちらかです。WAS は、リソース・マネージャーの調整をサポートするトランザクション・マネージャーで
あり、分散グローバル・トランザクションに参加します。
トランザクション・サービスのプロパティーを確認・変更する場合は、管理コンソールから、［サーバー］
→[サーバー・タイプ]→［WebSphere Application Server］→［ApplicationServer_name］→［コンテナ
ー・サービス］→［トランザクション・サービス］をクリックします。
図 3-131 トランザクション・サービスの設定： トランザクション・サービス設定画面へのリンク
- 119 -
下記のトランザクション・サービスのプロパティー画面が表示されます。
図 3-132 トランザクション・サービスの設定： プロパティー画面
トランザクション・ログ・ディレクトリー
トランザクション・ログのロケーションを指定します。これは、アプリケーションが分散リソースまたは XA
トランザクションを使用する場合の構成にのみ該当します。デフォルトは、
<Profile_root>/tranlog/Cell_name/Node_name/ApplicationServer_name/です。
合計トランザクション存続時間タイムアウト
トランザクションの最大存続時間 (秒単位) を指定します。
明示的に設定されたタイムアウトがないコンポーネント管理トランザクションには、この値が割り当てられ
ます。
クライアント非活動タイムアウト
リモート・クライアントからの各トランザクション要求間の最大所要時間 (秒単位) を指定します。
最大トランザクション・タイムアウト
このアプリケーション・サーバーにより開始された、またはこのアプリケーション・サーバーに伝搬されたト
ランザクションを実行できる最大存続時間 (秒単位) を指定します。
- 120 -