パート III リソースとサービスの管理

第 14 章 データベース接続の管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFish^TM Enterprise Server v3 環境でデータベース接続タスクを実行する手順について説明します。

ここでは、次のテーマを取り上げます。

• 「データベース接続について」

• 「データベースの設定」

• 「データベースへのアクセスの設定」

• 「JDBC ドライバに固有の構成」

これらのタスクを管理コンソールを使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。

データベース接続について

データベース管理システム (DBMS) は、データを格納、編成、および取得するための機能を提供します。多くの場合、データベース内の情報は持続的なデータとして表現されますが、これはデータがディスク上に保存され、アプリケーションプロセスが終了したあとも存在するためです。ほとんどのビジネスアプリケーションは、データをリレーショナルデータベースに格納します。アプリケーションは JDBC (Java Database Connectivity) API を使用して、データベース情報にアクセスできます。

データベース接続の主な要素は次のとおりです。

• 「データベース」。エンタープライズのデータが格納されるリポジトリです。Java EE アプリケーションは、JDBC API を介してリレーショナルデータベースにアクセスします。管理の手順については、「データベースの設定」を参照してください。

• 「JDBC 接続プール」。特定のデータベースのための再利用可能な接続のグループです。管理の手順については、「JDBC 接続プールの管理」を参照してください。

• 「JDBC リソース」 (データソース)。データベースに接続する手段をアプリケーションに提供します。JDBC リソースを作成するには、関連した接続プールを指定します。複数の JDBC リソースが 1 つの接続プールを指定することもできます。JDBC リソースは、Java Naming Directory Interface (JNDI) 名によって識別されます。管理の手順については、「JDBC リソースの管理」を参照してください。

• 「JDBC ドライバ」。データベースドライバは、Java アプリケーションがデータベース接続 API とやり取りを行うためのソフトウェアコンポーネントです。データベースごとに専用のドライバが必要です。管理の手順については、「JDBC ドライバの統合」を参照してください。

実行時には、アプリケーションがデータベースに接続するときに次の一連の処理が発生します。

1. アプリケーションは JNDI API を通して呼び出しを行い、データベースに関連付けられた JDBC リソースを取得します。

   リソースの JNDI 名を使用して、ネームサービスとディレクトリサービスが JDBC リソースを検索します。JDBC リソースはそれぞれ接続プールを指定します。

2. アプリケーションは JDBC リソースを使用してデータベース接続を取得します。

   Enterprise Server は、データベースに対応する接続プールから物理接続を取得します。プールは、データベース名 (URL)、ユーザー名、パスワードなどの接続属性を定義します。

3. データベース接続が確立されると、アプリケーションはデータベースに対してデータの読み取り、変更、および追加を実行できるようになります。

   アプリケーションは JDBC API を呼び出すことにより、データベースにアクセスします。JDBC ドライバはアプリケーションの JDBC 呼び出しをデータベースサーバーのプロトコルに変換します。

4. データベースへのアクセスが完了すると、アプリケーションは接続を閉じ、接続を接続プールに戻します。

データベースの設定

多くのアプリケーションは、リレーショナルデータベースを使用してデータを保存、編成、および取得します。アプリケーションは、JDBC (Java^TM Database Connectivity) API を通してリレーショナルデータベースにアクセスします。

ここでは、次のテーマを取り上げます。

• 「データベースおよびデータベースドライバをインストールする」

• 「データベースを起動する」

• 「データベースを停止する」

• 「Java DB ユーティリティースクリプト」

データベースおよびデータベースドライバをインストールする

1. サポートされたデータベース製品をインストールします。

   Enterprise Server でサポートされているデータベース製品の最新のリストを確認するには、『Sun GlassFish Enterprise Server v3 リリースノート』を参照してください。

2. データベース製品用のサポートされている JDBC ドライバをインストールします。

   Enterprise Server でサポートされているドライバのリストについては、「JDBC ドライバに固有の構成」を参照してください。

3. ドメイン管理サーバー (DAS) が JDBC ドライバの JAR ファイルにアクセスできるようにします。

   「JDBC ドライバの統合」を参照してください。

4. データベースを作成します。

   通常はアプリケーションプロバイダが、データベースを作成しデータを生成するためのスクリプトを提供しています。

データベースを起動する

Enterprise Server には、Java DB (以前の名称は Derby) の実装が含まれていますが、JDBC に準拠した任意のデータベースも使用できます。データベースは Enterprise Server の起動時に自動では起動されません。したがって、データベースを必要とするアプリケーションを使用する場合は、start-database サブコマンドを使用して Java DB を手動で起動する必要があります。

1. start-database(1) サブコマンドを使用して、データベースを起動します。

   データベースサーバーの起動時、またはクライアントがデータベースサーバーに正常に接続したときに、--dbhome オプションで指定された場所に次のファイルが作成されます。

   • derby.log ファイルには、データベースサーバープロセスのログが、標準出力および標準エラー情報とともに保存されます。

   • データベースのファイルには、使用するスキーマ (たとえば、データベース表) が保存されます。

例 14–1 データベースの起動

この例では、host1 というホストのポート 5001 で Derby を起動します。

asadmin> start-database --dbhost host1 --dbport 5001 --terse=true
Starting database in the background. 
Log redirected to /opt/SUNWappserver/databases/javadb.log.
Command start-database executed successfully.

参照

コマンド行に asadmin help start-database と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

データベースを停止する

ローカルの stop-database サブコマンドを使用して、指定したポートの Java DB を停止します。同一のホストのほかのポートで、複数のデータベースサーバープロセスが動作している場合があります。

1. 必要に応じて、データベースを停止することをユーザーに通知します。

2. stop-database(1) サブコマンドを使用して、データベースを停止します。

例 14–2 データベースの停止

この例では、localhost のポート 5001 で動作している Java DB を停止します。

asadmin> stop-database --dbhost=localhost --dbport=5001
onnection obtained for host: localhost, port number 5001.
Apache Derby Network Server - 10.2.2.1 - (538595) shutdown at 2008-10-17 23:34:2
7.218 GMT
Command stop-database executed successfully.

注意事項

ネットワーク間を移動するノートパソコンでは、データベースのシャットダウンに関して問題が発生する場合があります。Java DB を起動したあとに IP アドレスを変更した場合は、--dbhost 引数を指定しなければ Java DB を停止できません。たとえば、asadmin start-database --dbhost = 0.0.0.0 を実行したあと、Ethernet を切断してワイヤレス接続に切り替えた場合、データベースを停止するには次のようなコマンドを実行する必要があります。

asadmin stop-database --dbhost localhost

参照

コマンド行に asadmin help stop-database と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

Java DB ユーティリティースクリプト

Enterprise Server で利用できる Java DB の構成には、Java DB の使用に役立つスクリプトが含まれます。次のスクリプトが、as-install/javadb/frameworks/NetworkServer/bin ディレクトリに格納されています。

startNetworkServer、startNetworkServer.bat

ネットワークサーバーを起動するスクリプト

stopNetworkServer、stopNetworkServer.bat

ネットワークサーバーを停止するスクリプト

ij、ij.bat

対話式の JDBC スクリプト作成ツール

dblook、dblook.bat

データベースのすべてまたは一部の DDL を表示するスクリプト

sysinfo、sysinfo.bat

Java DB 環境に関するバージョン情報を表示するスクリプト

NetworkServerControl、NetworkServerControl.bat

NetworkServerControl API でコマンドを実行するスクリプト

Java DB ユーティリティースクリプトを実行するための環境を設定する

1. JAVA_HOME 環境変数が JDK のインストールディレクトリを指定していることを確認します。

2. as-install/derby ディレクトリをポイントするように JAVADB_HOME 環境変数を設定します。

参照

これらのユーティリティーの詳細については、次のドキュメントを参照してください。

• 『Derby Tools and Utilities Guide』 ()

• 『Derby Server and Administration Guide』 (http://db.apache.org/derby/docs/10.1/adminguide/)

データベースへのアクセスの設定

データベース接続を確立したら、Enterprise Server アプリケーションのアクセス設定を実行できます。データベースにアクセスする前に、アプリケーションは接続を取得する必要があります。

ここでは、次のテーマを取り上げます。

• 「JDBC 接続プールの管理」

• 「JDBC リソースの管理」

• 「JDBC ドライバの統合」

JDBC 接続プールの管理

「JDBC 接続プール」は、特定のデータベースのための再利用可能な接続のグループです。新しい物理接続の作成には時間がかかるため、Enterprise Server は使用可能な接続のプールを維持します。アプリケーションが接続を要求すると、プールから 1 つの接続が取得されます。アプリケーションが接続を閉じると、接続はプールに返されます。

JDBC リソースは、リソースが関連付けられている接続プールを指定することで作成されます。複数の JDBC リソースが 1 つの接続プールを指定することもできます。接続プールのプロパティーは、データベースベンダーによっては異なる場合もあります。共通のプロパティーには、データベースの名前 (URL)、ユーザー名、パスワードなどがあります。

次のタスクと情報を使用して、JDBC 接続プールを管理します。

• 「JDBC 接続プールを作成する」

• 「JDBC 接続プールを一覧表示する」

• 「接続プールと通信する (ping を実行する)」

• 「接続プールをリセット (フラッシュ) する」

• 「JDBC 接続プールを更新する」

• 「JDBC 接続プールを削除する」

JDBC 接続プールを作成する

指定した JDBC 接続プール名で新しい JDBC 接続プールを登録するには、リモートモードで create-jdbc-connection-pool サブコマンドを使用します。。JDBC 接続プールまたはコネクタ接続プールは、認証を使用して作成できます。asadmin ユーティリティーでユーザー、パスワード、またはその他の接続情報を指定するサブコマンドオプションを使用するか、XML 記述子ファイルで接続情報を指定します。

各データベースには接続プールが 1 つ必要です。アプリケーションによっては、複数の接続プールが必要な場合もあります。接続プールを構築するときに、JDBC ドライバとデータベースベンダーに固有のデータが必要となります。次に示す固有データの例の一部は、「JDBC ドライバに固有の構成」にも示してあります。

• データベースベンダー名

• javax.sql.DataSource (ローカルトランザクションのみ) や javax.sql.XADataSource (グローバルトランザクション) などのリソースタイプ

• データソースクラス名

• データベース名 (URL)、ユーザー名、およびパスワードなどの必要なプロパティー

JDBC 接続プールの作成は動的なイベントであり、サーバーの再起動は必要ありません。ただし、パラメータの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。

始める前に

接続プールを作成する前に、データベースとデータベースに関連する JDBC ドライバをインストールして統合しておく必要があります。手順については、「データベースの設定」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-jdbc-connection-pool(1) サブコマンドを使用して、JDBC 接続プールを作成します。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   一部のパラメータはサーバーの再起動を必要とします。「サーバーの再起動が必要な構成の変更」を参照してください。

例 14–3 JDBC 接続プールの作成

この例では、sample_derby_pool という名前の接続プールを localhost に作成します。

asadmin> create-jdbc-connection-pool 
--datasourceclassname org.apache.derby.jdbc.ClientDataSource 
--restype javax.sql.XADataSource 
--property portNumber=1527:password=APP:user=APP:serverName=
localhost:databaseName=sun-appserv-samples:connectionAttribut
es=\;create\\=true sample_derby_pool
Command create-jdbc-connection-pool executed successfully.

参照

コマンド行に asadmin help create-jdbc-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JDBC 接続プールを一覧表示する

既存の JDBC 接続プールをすべて表示するには、リモートモードで list-jdbc-connection-pools サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jdbc-connection-pools(1) サブコマンドを使用して、JDBC 接続プールを一覧表示します。

例 14–4 JDBC 接続プールの一覧表示

この例では、localhost 上の JDBC 接続プールを一覧表示します。

asadmin> list-jdbc-connection-pools
sample_derby_pool2
poolA
__TimerPool
DerbyPool
sample_derby_pool
Command list-jdbc-connection-pools executed successfully.

参照

コマンド行に asadmin help list-jdbc-connection-pools と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

接続プールと通信する (ping を実行する)

接続プールが使用可能かどうかをテストするには、リモートモードで ping-connection-pool サブコマンドを使用します。たとえば、あとで配備する予定のアプリケーション用に新しい JDBC 接続プールを作成した場合、そのアプリケーションを配備する前に、このコマンドを使用して JDBC プールをテストすることができます。ping を実行すると、プールがまだ作成されていない場合は作成を強制されます。

始める前に

接続プールと通信する前に、認証を使用して接続プールを作成し、サーバーまたはデータベースを実行しておく必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. ping-connection-pool(1) サブコマンドを使用して、接続プールに ping を実行します。

例 14–5 接続プールとの通信

この例では、DerbyPool 接続プールが使用可能かどうかを確認します。

asadmin> ping-connection-pool DerbyPool
Command ping-connection-pool executed successfully

参照

コマンド行に asadmin help ping-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

接続プールをリセット (フラッシュ) する

指定した接続プールで確立されたすべての接続を再初期化するには、リモートモードで flush-connection-pool を使用します。JDBC 接続プールまたはコネクタ接続プールは、初期状態にリセットされます。既存の動作中の接続はすべて破棄され、これらの接続に関連付けられているトランザクションは失われます。続いてプールの初期接続が再作成され、プールは通常プールサイズに復元されます。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. flush-connection-pool(1) サブコマンドを使用して、接続プールをリセットします。

例 14–6 接続プールのリセット (フラッシュ)

この例では、__TimerPool という名前の JDBC 接続プールを通常プールサイズにリセットします。

asadmin> flush-connection-pool __TimerPool 
Command flush-connection-pool executed successfully.

参照

コマンド行に asadmin help flush-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JDBC 接続プールを更新する

get および set サブコマンドを使用して、JDBC 接続プールのプロパティーの値を表示および変更します。

1. list-jdbc-connection-pools(1) サブコマンドを使用して、JDBC 接続プールを一覧表示します。

2. get サブコマンドを使用して、JDBC 接続プールの属性を表示します。

   次に例を示します。

   asadmin get resources.jdbc-connection-pool.DerbyPool.property

3. set サブコマンドを使用して、JDBC 接続プールの属性を設定します。

   次に例を示します。

   asadmin set resources.jdbc-connection-pool.DerbyPool.steady-pool-size=9

4. (省略可能) 必要な場合は、サーバーを再起動します。

   一部のパラメータはサーバーの再起動を必要とします。「サーバーの再起動が必要な構成の変更」を参照してください。

JDBC 接続プールを削除する

既存の JDBC 接続プールを削除するには、リモートモードで delete-jdbc-connection-pool サブコマンドを使用します。JDBC 接続プールの削除は動的なイベントであり、サーバーの再起動は必要ありません。

始める前に

JDBC 接続プールを削除する前に、リソースのすべての関連付けを削除する必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jdbc-connection-pools(1) サブコマンドを使用して、JDBC 接続プールを一覧表示します。

3. 必要に応じて、JDBC 接続プールを削除することをユーザーに通知します。

4. delete-jdbc-connection-pool(1) サブコマンドを使用して、接続プールを削除します。

例 14–7 JDBC 接続プールの削除

この例では、DerbyPool という名前の JDBC 接続プールを削除します。

asadmin> delete-jdbc-connection-pool jdbc/DerbyPool
Command delete-jdbc-connection-pool executed successfully.

参照

コマンド行に asadmin help delete-jdbc-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JDBC リソースの管理

「JDBC リソース」はデータソースとも呼ばれ、アプリケーションがデータベースに接続する手段を提供します。一般的には、ドメインに配備されたアプリケーションがアクセスするデータベースごとに 1 つの JDBC リソースを作成します。1 つのデータベースに複数の JDBC リソースを指定することもできます。

JDBC リソースは、リソースを関連付ける接続プールを指定することで作成されます。一意の Java Naming and Directory Interface (JNDI) 名を使用して、リソースを識別します。たとえば、給与データベースのリソースには、java:comp/env/jdbc/payrolldb のような JNDI 名を付けることができます。

次のタスクと情報を使用して、JDBC リソースを管理します。

• 「JDBC リソースを作成する」

• 「JDBC リソースを一覧表示する」

• 「JDBC リソースを更新する」

• 「JDBC リソースを削除する」

JDBC リソースを作成する

JDBC リソースを作成するには、リモートモードで create-jdbc-resource サブコマンドを使用します。JDBC リソースの作成は動的なイベントであり、サーバーの再起動は必要ありません。

すべての JNDI 名は java:comp/env サブコンテキストにあるので、管理コンソール で JDBC リソ スの JNDI を指定するときは、jdbc/name の形式だけを使用します。たとえば、先に述べた給与データベースは、jdbc/payrolldb のように指定できます。

始める前に

JDBC リソースを作成する前に、JDBC 接続プールを作成する必要があります。手順については、「JDBC 接続プールを作成する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-jdbc-resource(1) サブコマンドを使用して、JDBC リソースを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. 必要に応じて、新しいリソースを作成したことをユーザーに通知します。

例 14–8 JDBC リソースの作成

この例では、DerbyPool という名前の JDBC リソースを作成します。

asadmin> create-jdbc-resource --connectionpoolid DerbyPool jdbc/DerbyPool
Command create-jdbc-resource executed successfully.

参照

コマンド行に asadmin help create-jdbc-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JDBC リソースを一覧表示する

既存の JDBC リソースを一覧表示するには、リモートモードで list-jdbc-resources サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jdbc-resources(1) サブコマンドを使用して、JDBC リソースを一覧表示します。

例 14–9 JDBC リソースの一覧表示

この例では、localhost の JDBC リソースを一覧表示します。

asadmin> list-jdbc-resources
jdbc/__TimerPool
jdbc/DerbyPool
jdbc/__default
jdbc1
Command list-jdbc-resources executed successfully.

参照

コマンド行に asadmin help list-jdbc-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JDBC リソースを更新する

set サブコマンドを使用して、JDBC リソースを有効または無効にできます。JDBC リソースはドット表記名で識別されます。

1. list-jdbc-resources(1) サブコマンドを使用して、JDBC リソースを一覧表示します。

2. set(1) サブコマンドを使用して、指定した JDBC リソースの値を変更します。

   次に例を示します。

例 14–10 JDBC リソースの更新

この例では、res1 の enabled の設定を false に変更します。

asadmin>set resources.jdbc-resource.res1.enabled=false

JDBC リソースを削除する

既存の JDBC リソースを削除するには、リモートモードで delete-jdbc-resource サブコマンドを使用します。JDBC リソースの削除は動的なイベントであり、サーバーの再起動は必要ありません。

始める前に

JDBC リソースを削除する前に、削除するリソースのすべての関連付けを削除する必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jdbc-resources(1) サブコマンドを使用して、JDBC リソースを一覧表示します。

3. 必要に応じて、JDBC リソースを削除することをユーザーに通知します。

4. delete-jdbc-resource(1) サブコマンドを使用して、JDBC リソースを削除します。

例 14–11 JDBC リソースの削除

この例では、DerbyPool という名前の JDBC リソースを削除します。

asadmin> delete-jdbc-resource jdbc/DerbyPool
Command delete-jdbc-resource executed successfully.

参照

コマンド行に asadmin help delete-jdbc-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JDBC ドライバの統合

接続プールとリソースを設定したあと、次のいずれかの方法で JDBC ドライバを統合します。

• 共通のクラスローダーがドライバにアクセスできるようにして、ドメインを再起動します。

  ドライバの JAR および ZIP ファイルを、domain-dir/lib ディレクトリまたは glassfish_home/lib にコピーするか、ドライバのクラスファイルを domain-dir/lib/ext ディレクトリにコピーします。ドライバの JAR ファイルの完全修飾パス名が認識されます。

JDBC ドライバに固有の構成

Enterprise Server は、対応する JDBC ドライバを使用して、すべてのデータベース管理システムに接続できるように設計されています。

• 「完全にサポートされている JDBC ドライバ 」

• 「限定的にサポートされている JDBC ドライバ 」

完全にサポートされている JDBC ドライバ

次の JDBC ドライバとデータベースの組み合わせはテスト済みで、コンテナ管理による持続性がサポートされています。

• 「DB2 データベース用の Sun GlassFish JDBC ドライバ」

• 「Oracle 11 データベース用の Sun GlassFish JDBC ドライバ」

• 「Microsoft SQL Server データベース用の Sun GlassFish JDBC ドライバ」

• 「MySQL Server データベース用の Sun GlassFish JDBC ドライバ」

• 「Sybase データベース用の Sun GlassFish JDBC ドライバ」

• 「IBM DB2 Type 2 ドライバ」

• 「Java DB/Derby Type 4 ドライバ」

• 「MySQL Type 4 JDBC ドライバ」

• 「PostgreSQL ドライバ」

サポートされている JDBC ドライバの最新のリストについては、『Sun GlassFish Enterprise Server v3 リリースノート』を参照してください。

DB2 データベース用の Sun GlassFish JDBC ドライバ

このドライバの JAR ファイルは smdb2.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: DB2

• 「データソースクラス名」: com.sun.sql.jdbcx.db2.DB2DataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

Oracle 11 データベース用の Sun GlassFish JDBC ドライバ

このドライバの JAR ファイルは smoracle.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Oracle

• 「データソースクラス名」: com.sun.sql.jdbcx.oracle.OracleDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

Microsoft SQL Server データベース用の Sun GlassFish JDBC ドライバ

このドライバの JAR ファイルは smsqlserver.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Microsoft SQL Server

• 「データソースクラス名」: com.sun.sql.jdbcx.sqlserver.SQLServerDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • selectMethod – cursor に設定します。

MySQL Server データベース用の Sun GlassFish JDBC ドライバ

Sun MySQL ドライバは、MySQL Enterprise のみで動作します。このドライバの JAR ファイルは smmysql.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: SQL Server

• 「データソースクラス名」: com.sun.sql.jdbcx.mysql.MySQLDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • selectMethod – cursor に設定します。

Sybase データベース用の Sun GlassFish JDBC ドライバ

このドライバの JAR ファイルは smsybase.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Sybase

• 「データソースクラス名」: com.sun.sql.jdbcx.sybase.SybaseDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。これは任意指定です。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

IBM DB2 Type 2 ドライバ

この DB2 ドライバの JAR ファイルは db2jcc.jar、db2jcc_license_cu.jar、および db2java.zip です。環境変数を設定してください。次に例を示します。

LD_LIBRARY_PATH=/usr/db2user/sqllib/lib:${Java EE.home}/lib
DB2DIR=/opt/IBM/db2/V8.2
DB2INSTANCE=db2user
INSTHOME=/usr/db2user
VWSPATH=/usr/db2user/sqllib
THREADS_FLAG=native

次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: DB2

• 「データソースクラス名」: com.ibm.db2.jcc.DB2SimpleDataSource

• 「プロパティー」:

  • databaseName - 必要に応じて設定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • driverType – 2 に設定します。

  • deferPrepares – false に設定します。

Java DB/Derby Type 4 ドライバ

Java DB ドライバの JAR ファイルは derbyclient.jar です。Java DB は Apache Derby に基づいています。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: JavaDB

• 「データソースクラス名」: 次のいずれかを指定します。

  org.apache.derby.jdbc.ClientDataSource
  org.apache.derby.jdbc.ClientXADataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します (デフォルトと異なる場合)。

  • databaseName – データベースの名前を指定します。

  • user - データベースユーザーを指定します。

    これは、Java DB が認証を使用するように設定されている場合にのみ必要です。Java DB は、デフォルトで認証を使用しません。ユーザーを指定すると、その名前が、テーブルが属するスキーマの名前になります。

  • password – データベースパスワードを指定します。

    これは、Java DB が認証を使用するように設定されている場合にのみ必要です。

MySQL Type 4 JDBC ドライバ

MySQL^TM ドライバの JAR ファイルは mysql-connector-java-5.1.7-bin.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Microsoft SQL Server

• 「データソースクラス名」:

  com.mysql.jdbc.jdbc2.optional.MysqlDataSource
  com.mysql.jdbc.jdbc2.optional.MysqlXADataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

PostgreSQL ドライバ

PostgreSQL ドライバの JAR ファイルは postgresql-8.4-701.jdbc4.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: PostgreSQL Server

• 「データソースクラス名」:

      * org.postgresql.ds.PGSimpleDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

限定的にサポートされている JDBC ドライバ

次の JDBC ドライバも Enterprise Server で使用できますが、これらのドライバは完全にはテストされていません。Sun では、これらのドライバの製品サポートは提供していませんが、Enterprise Server &; での使用についての限定サポートを提供しています。

• 「IBM Informix Type 4 ドライバ」

• 「Oracle データベース用の Inet Oraxo JDBC ドライバ」

• 「Microsoft SQL Server データベース用の Inet Merlia JDBC ドライバ」

• 「Sybase データベース用の Inet Sybelux JDBC ドライバ」

• 「Sybase ASE 12.5 データベース用の JConnect Type 4 ドライバ」

• 「Oracle 11 データベース用の Oracle Thin Type 4 JDBC ドライバ」

• 「Oracle データベース用の OCI Oracle Type 2 ドライバ」

Oracle データベースユーザーが capture-schema コマンドを実行するには、そのユーザーがスキーマの所有者でないかぎり、ANALYZE ANY TABLE 特権が必要です。この特権は、データベース管理者がユーザーに付与します。capture-schema の詳細は、『Sun GlassFish Enterprise Server v3 Reference Manual 』を参照してください。

IBM Informix Type 4 ドライバ

次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Informix

• 「データソースクラス名」: 次のいずれかを指定します。

  com.informix.jdbcx.IfxDataSource
  com.informix.jdbcx.IfxXADataSource

• 「プロパティー」:

  • serverName – Informix データベースサーバー名を指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。これは任意指定です。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • IfxIFXHost – データベースサーバーのホスト名または IP アドレスを指定します。

Oracle データベース用の Inet Oraxo JDBC ドライバ

この Oracle ドライバの JAR ファイルは Oranxo.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Oracle

• 「データソースクラス名」: com.inet.ora.OraDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • user – データベースユーザーを指定します。

  • password – データベースパスワードを指定します。

  • serviceName – データベースの URL を指定します。構文は次のとおりです。

    jdbc:inetora:server:port:dbname
    

    次に例を示します。

    jdbc:inetora:localhost:1521:payrolldb

    この例では、localhost は Oracle サーバーを実行しているマシンのホスト名、1521 は Oracle サーバーのポート番号、payrolldb はデータベースの SID を表します。データベース URL の構文の詳細については、Oracle のドキュメントを参照してください。

  • streamstolob - BLOB または CLOB データ型のサイズが 4K バイトを超え、このドライバが CMP で使用される場合は、このプロパティーを true に設定してください。

  • xa-driver-does-not-support-non-tx-operations - true の値に設定します。同じ接続プールから非 XA 接続と XA 接続の両方が取得される場合にのみ必要です。パフォーマンスが低下する可能性があります。

    このプロパティーを設定する代わりに、非 XA 接続用とXA 接続用の 2 つの接続プールを作成することもできます。

Microsoft SQL Server データベース用の Inet Merlia JDBC ドライバ

この Microsoft SQL Server ドライバの JAR ファイルは Merlia.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Microsoft SQL Server

• 「データソースクラス名」: com.inet.tds.TdsDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

Sybase データベース用の Inet Sybelux JDBC ドライバ

この Inet Sybase ドライバの JAR ファイルは Sybelux.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Sybase

• 「データソースクラス名」: com.inet.syb.SybDataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。完全な URL ではなく、データベース名のみを指定してください。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

Sybase ASE 12.5 データベース用の JConnect Type 4 ドライバ

この Sybase ドライバの JAR ファイルは jconn4.jar です。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Sybase

• 「データソースクラス名」: 次のいずれかを指定します。

  com.sybase.jdbc4.jdbc.SybDataSource
  com.sybase.jdbc4.jdbc.SybXADataSource

• 「プロパティー」:

  • serverName – データベースサーバーのホスト名または IP アドレスを指定します。

  • portNumber – データベースサーバーのポート番号を指定します。

  • databaseName – 必要に応じて設定します。完全な URL ではなく、データベース名のみを指定してください。

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • BE_AS_JDBC_COMPLIANT_AS_POSSIBLE – true に設定します。

  • FAKE_METADATA – true に設定します。

Oracle 11 データベース用の Oracle Thin Type 4 JDBC ドライバ

この Oracle ドライバの JAR ファイルは ojdbc6.jar です。

このドライバを使用する場合は、1 つの列に 2000 バイトを超えるデータを挿入できないことに注意してください。この問題を回避するには、OCI ドライバ (JDBC Type 2) を使用します。

次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Oracle

• 「データソースクラス名」: 次のいずれかを指定します。

  oracle.jdbc.pool.OracleDataSource
  oracle.jdbc.xa.client.OracleXADataSource

• 「プロパティー」:

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • xa-driver-does-not-support-non-tx-operations - true の値に設定します。これは任意指定です。 同じ接続プールから非 XA 接続と XA 接続の両方が取得される場合にのみ必要です。パフォーマンスが低下する可能性があります。

    このプロパティーを設定する代わりに、非 XA 接続用とXA 接続用の 2 つの接続プールを作成することもできます。

  ---

  注 –

  Oracle thin ドライバでは、XAResource.recover メソッドが、入力フラグに関係なく同じ未確定の Xid のセットを繰り返し返します。XA 仕様に従って、トランザクションマネージャーは最初に TMSTARTSCAN でこのメソッドを呼び出したあと、TMNOFLAGS で、Xid が返されなくなるまで繰り返しこのメソッドを呼び出します。XAResource.commit メソッドにもいくつかの問題があります。

  この Enterprise Server の回避方法を無効にするには、oracle-xa-recovery-workaround プロパティーの値を false に設定する必要があります。

  ---

Oracle データベース用の OCI Oracle Type 2 ドライバ

この OCI Oracle ドライバの JAR ファイルは ojdbc14.jar です。LD_LIBRARY_PATH を介して共用ライブラリが使用可能であること、および ORACLE_HOME プロパティーが設定されていることを確認してください。次のように接続プールを設定します。

• 「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。

• 「リソースタイプ」: 適切な値を指定します。

• 「データベースベンダー」: Oracle

• 「データソースクラス名」: 次のいずれかを指定します。

  oracle.jdbc.pool.OracleDataSource
  oracle.jdbc.xa.client.OracleXADataSource

• 「プロパティー」:

  • user – 必要に応じて設定します。

  • password – 必要に応じて設定します。

  • xa-driver-does-not-support-non-tx-operations - true の値に設定します。同じ接続プールから非 XA 接続と XA 接続の両方が取得される場合にのみ必要です。パフォーマンスが低下する可能性があります。

    このプロパティーを設定する代わりに、非 XA 接続用とXA 接続用の 2 つの接続プールを作成することもできます。

第 15 章 EIS 接続の管理

この章では、Sun GlassFish^TM Enterprise Server v3 環境で、asadmin コマンド行ユーティリティーを使用し、エンタープライズ情報システム (EIS) のデータとの接続を管理する方法について説明します。

Web Profile をインストールした場合は、発信機能だけを使用するコネクタモジュールと、着信機能を伴わない作業管理がサポートされます。その他のコネクタ機能は、Full Platform Profile でのみサポートされます。

ここでは、以下のトピックに関して説明します。

• 「EIS 接続とは」

• 「コネクタ接続プールの管理」

• 「コネクタリソースの管理」

• 「リソースアダプタ構成の管理」

• 「コネクタセキュリティーマップの管理」

• 「コネクタ作業セキュリティーマップの管理」

• 「管理対象オブジェクトの管理」

本章で説明するタスクを管理コンソールから実行する手順については、管理コンソールのオンラインヘルプを参照してください。

データベース接続については、第 14 章データベース接続の管理 を参照してください。

EIS 接続とは

エンタープライズ情報システム (EIS) は、組織のデータを保持する任意のシステムです。メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションがこれに使用できます。アプリケーションとモジュールが EIS ソフトウェアにアクセスするには、接続リソースが使用されます。

EIS 接続の主な要素は、次のとおりです。

• 「コネクタモジュール」。コネクタモジュールは、アプリケーションと EIS ソフトウェアとの対話を可能にする Java EE コンポーネントで、リソースアダプタとも呼ばれます。コネクタモジュールは、Enterprise Server が Java^TM Message Service (JMS) を実装する際に使用されます。ほかのJava EE モジュールと同様に、コネク タモジュールをインストールするには、これを配備する必要があります。コネクタモジュールの作成方法については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 12 章「Developing Connectors」を参照してください。

• 「コネクタ接続プール」。コネクタ接続プールとは、特定の EIS のための再利用可能な接続のグループです。コネクタ接続プールを作成するには、プールに関連付けるコネクタモジュールを指定します。管理手順については、「コネクタ接続プールの管理」を参照してください。

• 「コネクタリソース」。コネクタリソースとは、アプリケーションに EIS への接続を提供するプログラムオブジェクトです。コネクタリソースを作成するには、JNDI 名と関連する接続プールを指定します。EIS 用コネクタリソースの JNDI 名は、通常 java:comp/env/eis-specific サブコンテキストにあります。管理手順については、「コネクタリソースの管理」を参照してください。

• 「コネクタモジュール構成」。コネクタモジュール構成とは、ドメイン構成ファイル (domain.xml) 内にある、特別なコネクタモジュール (リソースアダプタ) の情報です。管理手順については、「リソースアダプタ構成の管理」を参照してください。

• 「コネクタセキュリティーマップ」。コネクタセキュリティーマップとは、アプリケーションの (主体またはユーザーグループの) 呼び出し側 ID を、適切な EIS 主体またはグループに関連付けるものです。管理手順については、「コネクタセキュリティーマップの管理」を参照してください。

• 「コネクタの作業セキュリティーマップ」。コネクタの作業セキュリティーマップは、コネクタモジュール (リソースアダプタ) の EIS 主体または EIS グループが提出した作業の呼び出し側 ID を、Enterprise Server セキュリティードメインの適切な主体またはユーザーグループに関連付けます。管理手順については、「コネクタ作業セキュリティーマップの管理」を参照してください。

• 「管理対象オブジェクト」。管理対象オブジェクトは、アプリケーションの特殊な機能を提供します。たとえば、管理対象オブジェクトは、コネクタモジュールおよびそれに関連付けられた EIS に固有なパーサーへのアクセスを提供できます。管理手順については、「管理対象オブジェクトの管理」を参照してください。

実行時に、アプリケーションが EIS に接続されると次のことが行われます。

1. JNDI API を介して呼び出しを行うことにより、アプリケーションは EIS に関連したコネクタリソース (データソース) を取得します。

   コネクタリソースの JNDI 名を基に、ネーミングおよびディレクトリサービスがリソースを検索します。EIS リソースはそれぞれコネクタ接続プールを指定します。

2. コネクタリソースを経由して、アプリケーションは EIS 接続を取得します。

   Enterprise Server は EIS リソースに対応した接続プールから物理接続を取得します。プールは、EIS 名、ユーザー名、パスワードなどの接続属性を定義します。

3. EIS 接続が確立されると、アプリケーションは EIS のデータの読み込み、変更、および追加を行うことができます。

   アプリケーションは JMS API を呼び出すことにより、EIS 情報にアクセスします。

4. EIS へのアクセスが完了すると、アプリケーションは接続を終了して、接続を接続プールに返します。

コネクタ接続プールの管理

コネクタモジュールを配備すると、これにコネクタ接続プールを作成できるようになります。

ここでは、以下のトピックに関して説明します。

• 「コネクタ接続プールを作成する」

• 「コネクタ接続プールを一覧表示する」

• 「コネクタ接続プールに接続 (ping) するかコネクタ接続プールをリセット (フラッシュ) する」

• 「コネクタ接続プールを更新する」

• 「コネクタ接続プールを削除する」

コネクタ接続プールを作成する

配備したコネクタモジュールにコネクタ接続プールを作成するには、リモートモードで create-connector-connection-pool サブコマンドを使用します。コネクタ接続プールを構築する際に、その EIS に固有の所定データを入力するよう求められます。必須の --connectiondefintion オプションの値が、EIS 情報となります。

複数のコネクタリソースで 1 つの接続プールを指定できます。

コネクタ接続プールの作成は動的イベントで、サーバーの再起動は求められません。ただし、パラメータの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。

始める前に

コネクタ接続プールを作成する前に、コネクタをインストールしておいてください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-connector-connection-pool(1) サブコマンドを使用して、コネクタ接続プールを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

4. (省略可能) 接続プールが使用可能であることを確認するには、ping-connection-pool サブコマンドを使用します。

   手順については、「接続プールと通信する (ping を実行する)」を参照してください。

例 15–1 コネクタ接続プールの作成

この例では、javax.jms.QueueConnectionFactory コネクタモジュールに jms/qConnPool プールを新規作成します。

asadmin> create-connector-connection-pool --steadypoolsize 20 --maxpoolsize 100 
--poolresize 2 --maxwait 60000 --raname jmsra --connectiondefinition 
javax.jms.QueueConnectionFactory jms/qConnPool  
Command create-connector-connection-pool executed successfully

参照

コマンド行に asadmin help create-connector-connection-pool と 入力して、サブコマンドの完全な構文とオプションを確認することもできます。

コネクタ接続プールを一覧表示する

作成済みのプールを一覧表示するには、リモートモードで list-connector-connection-pools サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-connection-pools(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。

例 15–2 コネクタ接続プールの一覧表示

この例では、既存のコネクタ接続プールを一覧表示します。

asadmin> list-connector-connection-pools
jms/qConnPool
Command list-connector-connection-pools executed successfully

参照

コマンド行に asadmin help list-connector-connection-pools と 入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタ接続プールに接続 (ping) するかコネクタ接続プールをリセット (フラッシュ) する

リモートモードで接続プールにこれらのタスクを実行するには、ping-connection-pool または flush-connection-pool サブコマンドを使用します。手順については、「接続プールと通信する (ping を実行する)」または「接続プールをリセット (フラッシュ) する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. flush-connection-pool(1) サブコマンド、または ping-connection-pool(1) サブコマンドを使用して、コネクタ接続プールに接続、またはコネクタ接続プールをリセットします。

コネクタ接続プールを更新する

コネクタ接続プールのプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。

1. list-connector-connection-pools(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。

2. get(1) サブコマンドを使用して、コネクタ接続プールのプロパティーを表示します。

   次に例を示します。

   asadmin> get domain.resources.connector-connection-pool.conectionpoolname.*

3. set(1) サブコマンドを使用して、コネクタ接続プールのプロパティーを設定します。

   次に例を示します。

   asadmin> set domain.resources.connector-connection-pool .conectionpoolname.validate-atmost-once-period-in-seconds=3

4. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

コネクタ接続プールを削除する

コネクタ接続プールを削除するには、リモートモードで delete-connector-connection-pool サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-connection-pools(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。

3. 必要な場合は、コネクタ接続プールが削除されることをユーザーに通知してください。

4. delete-connector-connection-pool(1) サブコマンドを使用して、コネクタ接続プールを削除します。

例 15–3 コネクタ接続プールの削除

この例では、jms/qConnPool という接続プールを削除します。

asadmin> delete-connector-connection-pool --cascade=false jms/qConnPool
Command delete-connector-connection-pool executed successfully

参照

コマンド行に asadmin help delete-connector-connection-pool と 入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタリソースの管理

コネクタリソースとは、アプリケーションまたはモジュールに EIS への接続手段を提供するものです。通常、ドメインに配備するアプリケーションのアクセス対象となる EIS ごとに、コネクタリソースを作成します。

ここでは、以下のトピックに関して説明します。

• 「コネクタリソースを作成する」

• 「コネクタリソースを一覧表示する」

• 「コネクタリソースを更新する」

• 「コネクタリソースを削除する」

コネクタリソースを作成する

新しいコネクタリソースとその JNDI 名を登録するには、リモートモードで create-connector-resource サブコマンドを使用します。

コネクタリソースの作成は動的イベントで、サーバーの再起動は求められません。ただし、パラメータの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。

始める前に

コネクタリソースを作成する前に、まずコネクタ接続プールを作成しておく必要があります。手順については、「コネクタ接続プールを作成する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-connector-resource(1) サブコマンドを使用して、コネクタリソースを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 15–4 コネクタリソースの作成

この例では、jms/qConnPool 接続プールに jms/qConnFactory というリソースを新規作成します。

asadmin> create-connector-resource --poolname jms/qConnPool 
--description "creating sample connector resource" jms/qConnFactory
Command create-connector-resource executed successfully

参照

コマンド行に asadmin help create-connector-resource と 入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタリソースを一覧表示する

作成済みのコネクタリソースを一覧表示するには、リモートモードで list-connector-resources サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-resources(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。

例 15–5 コネクタリソースの一覧表示

この例では、既存のコネクタリソースを一覧表示します。

asadmin> list-connector-resources
jms/qConnFactory
Command list-connector-resources executed successfully

参照

コマンド行に asadmin help list-connector-resources と 入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタリソースを更新する

コネクタリソースのプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。

1. list-connector-resources(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。

2. get(1) サブコマンドを使用して、コネクタリソースのプロパティーを表示します。

   次に例を示します。

   asadmin> get domain.resources.connector-resource.jms/qConnFactory

3. set(1) サブコマンドを使用して、コネクタリソースのプロパティーを設定します。

   次に例を示します。

   asadmin> set domain.resources.connector-resource.jms/qConnFactory.enabled=true

4. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

コネクタリソースを削除する

JNDI 名を指定してコネクタリソースを削除するには、リモートモードで delete-connector-resource サブコマンドを使用します。

始める前に

リソースを削除する前に、そのリソースに関連付けられているものをすべて削除しておく必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-resources(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。

3. 必要な場合は、コネクタリソースが削除されることをユーザーに通知してください。

4. delete-connector-resource(1) サブコマンドを使用して、コネクタリソースを削除します。

例 15–6 コネクタリソースの削除

この例では、jms/qConnFactory コネクタリソースを削除します。

asadmin> delete-connector-resource jms/qConnFactory 
Command delete-connector-resources executed successfully

参照

コマンド行に asadmin help delete-connector-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

リソースアダプタ構成の管理

ここでは、以下のトピックに関して説明します。

• 「リソースアダプタの構成情報を作成する」

• 「リソースアダプタ構成の一覧表示」

• 「リソースアダプタ構成を更新する」

• 「リソースアダプタ構成を削除する」

リソースアダプタの構成情報を作成する

リソースアダプタ (コネクタモジュール) の構成情報を作成するには、リモートモードで create-resource-adapter-config サブコマンドを使用します。配備するときに構成情報を使用できるように、このサブコマンドを実行してからリソースアダプタを配備することができます。このリソースアダプタ構成は、リソースアダプタを配備したあとでも作成できます。この場合、リソースアダプタは新しい構成で再起動されます。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-resource-adapter-config(1) サブコマンドで、構成情報を作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

例 15–7 リソースアダプタ構成の作成

この例では、リソースアダプタ ra1 の構成を作成します。

asadmin> create-resource-adapter-config --property foo=bar 
--threadpoolid mycustomerthreadpool ra1
Command create-resource-adapter-config executed successfully

参照

コマンド行に asadmin help create-resource-adapter-config と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

リソースアダプタ構成の一覧表示

指定したリソースアダプタ (コネクタモジュール) のドメイン構成ファイル (domain.xml) に含まれている構成情報を一覧表示するには、リモートモードで list-resource-adapter-configs サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-resource-adapter-configs(1) サブコマンドで、リソースアダプタの設定を一覧表示します。

例 15–8 リソースアダプタ構成の一覧表示

この例では、リソースアダプタ構成を一覧表示します。

asadmin> list-resource-adapter-configs
ra1
ra2
Command list-resource-adapter-configs executed successfully

参照

コマンド行に asadmin help list-resource-adapter-configs と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

リソースアダプタ構成を更新する

リソースアダプタ構成のプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。

1. list-resource-adapter-configs(1) サブコマンドで、リソースアダプタの構成を一覧表示します。

2. get(1) サブコマンドを使用して、コネクタリソースのプロパティーを表示します。

   次に例を示します。

   asadmin> get domain.resources.resource-adapter-config.ra1.*

3. set(1) サブコマンドを使用して、コネクタリソースのプロパティーを設定します。

   次に例を示します。

   asadmin> set domain.resources.resource-adapter-config.ra1.raSpecificProperty=value

リソースアダプタ構成を削除する

指定したリソースアダプタ (コネクタモジュール) のドメイン構成ファイル (domain.xml) に含まれている構成情報を削除するには、リモートモードで delete-resource-adapter-config サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-resource-adapter-configs(1) サブコマンドで、リソースアダプタの構成を一覧表示します。

3. delete-resource-adapter-config(1) サブコマンドで、リソースアダプタの構成を削除します。

例 15–9 リソースアダプタ構成の削除

この例では、リソースアダプタ ra1 の構成を削除します。

asadmin> delete-resource-adapter-config ra1
Command delete-resource-adapter-config executed successfully

参照

コマンド行に asadmin help delete-resource-adapter-config と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタセキュリティーマップの管理

EIS は、組織のデータを保持する任意のシステムです。メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションがこれに使用できます。コネクタセキュリティーマップは、アプリケーションの証明を EIS 証明にマッピングするのに使用します。

セキュリティーマップは、個々のコネクタ接続プールに適用されます。1 つ以上の指定したセキュリティーマップをコネクタ接続プールに関連付けることができます。

ここでは、以下のトピックに関して説明します。

• 「コネクタセキュリティーマップを作成する」

• 「コネクタセキュリティーマップの一覧表示」

• 「コネクタセキュリティーマップを更新する」

• 「コネクタセキュリティーマップを削除する」

コネクタセキュリティーマップを作成する

指定したコネクタ接続プールにセキュリティーマップを作成するには、リモートモードで create-connector-security-map サブコマンドを使用します。セキュリティーマップが存在しない場合は、新規に作成されます。バックエンド EIS 主体、またはバックエンド EIS ユーザーグループを指定できます。コネクタセキュリティーマップの構成では、ワイルドカード文字としてアスタリスク (*) を使用し、すべてのユーザーまたはすべてのユーザーグループを示すことができます。

このサブコマンドを使用して、コンテナ管理トランザクションベースのシナリオで、アプリケーション (主体またはユーザーグループ) の呼び出し側 ID を適切な EIS 主体に割り当てることもできます。

始める前に

このサブコマンドを正常に実行するためには、最初にコネクタ接続プールを作成しておく必要があります。手順については、「コネクタ接続プールを作成する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-connector-security-map(1) サブコマンドで、コネクタセキュリティーマップを作成します。

   このサブコマンドのオプションについては、このマニュアルページに記載されています。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 15–10 コネクタセキュリティーマップの作成

この例では、connection-pool1 に、securityMap1 コネクタセキュリティーマップを作成します。

asadmin> create-connector-security-map --poolname connector-pool1 
--principals principal1, principal2 --mappedusername backend-username securityMap1
Command create-connector-security-map executed successfully

コネクタセキュリティーマップの一覧表示

指定したコネクタ接続プールに属する既存のセキュリティーマップを一覧表示するには、リモートモードで list-connector-security-maps サブコマンドを使用します。コネクタ接続プールにコネクタセキュリティーマップの簡易リストを取得することも、マップの主体を表示するような総合リストを取得することもできます。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-connection-pools(1) サブコマンドを使用して、既存のコネクタ接続プールを一覧表示します。

3. list-connector-security-maps(1) サブコマンドで、指定のコネクタ接続プールのセキュリティーマップを一覧表示します。

例 15–11 コネクタ接続プールのコネクタセキュリティーマップの一覧表示

この例では、connector-Pool1 に関連付けられているコネクタセキュリティーマップを一覧表示します。

asadmin> list-connector-security-maps connector-Pool1
securityMap1 
Command list-connector-security-maps executed successfully.

例 15–12 コネクタ接続プールの指定セキュリティーマップの主体の一覧表示

この例では、securityMap1 に関連付けられている主体を一覧表示します。

asadmin> list-connector-security-maps --securitymap securityMap1 connector-Pool1
principal1
principal1
Command list-connector-security-maps executed successfully.

例 15–13 コネクタ接続プールのコネクタセキュリティーマップの主体の一覧表示

この例では、connector-Pool1 に関連付けられているコネクタセキュリティーマップを一覧表示します。

asadmin> list-connector-security-maps --verbose connector-Pool1
securityMap1
principal1
principal1
Command list-connector-security-maps executed successfully.

コネクタセキュリティーマップを更新する

指定したコネクタ接続プールにセキュリティーマップを作成または変更するには、リモートモードで update-connector-security-map サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-security-maps(1) サブコマンドを使用して、既存のコネクタセキュリティーマップを一覧表示します。

3. update-connector-security-map(1) サブコマンドで、指定のコネクタ接続プールのセキュリティーマップを変更します。

4. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 15–14 コネクタセキュリティーマップの更新

この例では、securityMap1 に主体を追加します。

asadmin> update-connector-security-map --poolname connector-pool1 
--addprincipals principal1, principal2 securityMap1
Command update-connector-security-map executed successfully.

コネクタセキュリティーマップを削除する

指定したコネクタ接続プールにセキュリティーマップを削除するには、リモートモードで delete-connector-security-map サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-connection-pools(1) サブコマンドを使用して、既存のコネクタ接続プールを一覧表示します。

3. delete-connector-security-map(1) サブコマンドで、指定のコネクタ接続プールのセキュリティーマップを削除します。

   このサブコマンドのオプションについては、このマニュアルページに記載されています。

例 15–15 コネクタセキュリティーマップの削除

この例では、connector-pool1 から securityMap1 を削除します。

asadmin> delete-connector-security-map --poolname connector-pool1 securityMap1
Command delete-connector-security-map executed successfully

コネクタ作業セキュリティーマップの管理

EIS は、組織のデータを保持する任意のシステムです。メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションがこれに使用できます。コネクタ作業セキュリティーマップは、EIS 証明を Enterprise Server セキュリティードメインの証明にマッピングするのに使用します。

セキュリティーマップは、個々のコネクタ接続プールに適用されます。1 つ以上の指定したセキュリティーマップをコネクタ接続プールに関連付けることができます。

ここでは、以下のトピックに関して説明します。

• 「コネクタ作業セキュリティーマップを作成する」

• 「コネクタ作業セキュリティーマップを一覧表示する」

• 「コネクタ作業セキュリティーマップを更新する」

• 「コネクタ作業セキュリティーマップを削除する」

コネクタ作業セキュリティーマップを作成する

コネクタモジュール (リソースアダプタ) の EIS 主体または EIS グループが提出した作業の呼び出し側 ID を、Enterprise Server セキュリティードメインの適切な主体またはユーザーグループにマッピングするには、リモートモードで create-connector-work-security-map サブコマンドを使用します。1 つ以上の作業セキュリティーマップをコネクタモジュールに関連付けることができます。

コネクタセキュリティーマップの構成では、ワイルドカード文字としてアスタリスク (*) を使用し、すべてのユーザーまたはすべてのユーザーグループを示すことができます。

始める前に

コネクタリソースを作成する前に、まずコネクタ作業セキュリティーマップを作成しておく必要があります。手順については、「コネクタ接続プールを作成する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-connector-work-security-map(1) サブコマンドで、コネクタ作業セキュリティーマップを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 15–16 コネクタ作業セキュリティーマップを作成する

次の例は、my-resource-adapter-name に workSecurityMap1 および workSecurityMap2 を作成します。

asadmin> create-connector-work-security-map --raname my-resource-adapter-name 
--principalsmap eis-principal-1=server-principal-1,eis-principal-2=server-principal-2, 
eis-principal-3=server-principal-1 workSecurityMap1

asadmin> create-connector-work-security-map --raname my-resource-adapter-name
--groupsmap eis-group-1=server-group-1,eis-group-2=server-group-2,
eis-group-3=server-group-1 workSecurityMap2
Command create-connector-work-security-map executed successfully

参照

コマンド行に asadmin help create-connector-work-security-map と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタ作業セキュリティーマップを一覧表示する

指定のコネクタモジュールに属する作業セキュリティーマップを一覧表示するには、リモートモードで list-connector-work-security-maps サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-work-security-maps(1) サブコマンドで、コネクタ作業セキュリティーマップを一覧表示します。

例 15–17 コネクタ作業セキュリティーマップの一覧表示

この例では、一般的な作業セキュリティーマップを一覧表示します。

asadmin> list-connector-work-security-maps generic-ra
generic-ra-groups-map: EIS group=eis-group, mapped group=glassfish-group
generic-ra-principals-map: EIS principal=eis-bar, mapped principal=bar
generic-ra-principals-map: EIS principal=eis-foo, mapped principal=foo
Command list-connector-work-security-maps executed successfully.

参照

コマンド行に asadmin help list-connector-work-security-maps と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタ作業セキュリティーマップを更新する

指定のリソースアダプタ (接続モジュール) に属する作業セキュリティーマップを変更するには、リモートモードで update-connector–work-security-map サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-work-security-maps(1) サブコマンドで、コネクタ作業セキュリティーマップを一覧表示します。

3. 必要な場合は、コネクタ作業セキュリティーマップが変更されることをユーザーに通知してください。

4. update-connector-work-security-map(1) サブコマンドで、コネクタ作業セキュリティーマップを更新します。

例 15–18 コネクタ作業セキュリティーマップの更新

この例では、作業セキュリティーマップから主体を削除します。

asadmin> update-connector-work-security-map --raname generic-ra 
--removeprincipals eis-foo generic-ra-principals-map
Command update-connector-work-security-map executed successfully.

参照

コマンド行に asadmin help update-connector-work-security-map と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

コネクタ作業セキュリティーマップを削除する

指定のコネクタモジュール (リソースアダプタ) に属する作業セキュリティーマップを削除するには、リモートモードで delete-connector–work-security-map サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-connector-work-security-maps(1) サブコマンドで、コネクタ作業セキュリティーマップを一覧表示します。

3. delete-connector-work-security-map(1) サブコマンドで、コネクタ作業セキュリティーマップを削除します。

例 15–19 コネクタ作業セキュリティーマップの削除

この例では、my_ra コネクタモジュールから worksecuritymap1 マップを削除します。

asadmin> delete-connector-work-security-map --raname my_ra worksecuritymap1
Command delete-connector-work-security-map executed successfully.

参照

コマンド行に asadmin help delete-connector-work-security-map と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

管理対象オブジェクトの管理

コネクタモジュールにパッケージ化されている管理対象オブジェクトは、アプリケーションの特殊な機能を提供します。たとえば、管理対象オブジェクトは、コネクタモジュールおよびそれに関連付けられた EIS に固有なパーサーへのアクセスを提供できます。

ここでは、以下のトピックに関して説明します。

• 「管理対象オブジェクトリソースを作成する」

• 「管理対象オブジェクトを一覧表示する」

• 「管理対象オブジェクトを更新する」

• 「管理対象オブジェクトリソースを削除する」

管理対象オブジェクトリソースを作成する

管理対象オブジェクトを作成するには、create-admin-object サブコマンドを使用します。管理対象オブジェクトリソースを作成すると、名前と値のペアが作成され、そのオブジェクトが JNDI 名と関連付けられます。

始める前に

このサブコマンド (jmsrar.rar) を実行する前に、リソースアダプタを配備しておいてください。

1. create-admin-object(1) サブコマンドで、管理対象オブジェクトを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

2. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 15–20 管理対象オブジェクトの作成

この例では、ra.xml ファイルから javax.jms.Queue リソースの型が取得されます。新たに作成される管理対象オブジェクトの JNDI 名は、jms/samplequeue です。

asadmin> create-admin-object --restype javax.jms.Queue 
--raname jmsra  --description "sample administered object" 
--property Name=sample_jmsqueue jms/samplequeue
Command create-admin-object executed successfully

参照

コマンド行に asadmin help create-admin-object と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

管理対象オブジェクトを一覧表示する

既存の管理対象オブジェクトを一覧表示するには、リモートモードで list-admin-object サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-admin-objects(1) サブコマンドで、管理対象オブジェクトを一覧表示します。

例 15–21 管理対象オブジェクトの一覧表示

この例では、既存の管理対象オブジェクトを一覧表示します。

asadmin> list-admin-objects
jms/samplequeue
Command list-admin-objects executed successfully

参照

コマンド行に asadmin help list-admin-object と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

管理対象オブジェクトを更新する

管理対象オブジェクトのプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。

1. list-admin-objects(1) サブコマンドで、管理対象オブジェクトを一覧表示します。

2. get(1) サブコマンドを使用して、管理対象オブジェクトのプロパティーを表示します。

   次に例を示します。

   asadmin> get domain.resources.admin-object-resource.jms/samplequeue.*

3. set(1) サブコマンドを使用して、管理対象オブジェクトのプロパティーを設定します。

   次に例を示します。

   asadmin> set domain.resources.admin-object-resource.jms/samplequeue.enabled=false

4. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

管理対象オブジェクトリソースを削除する

管理対象オブジェクトを削除するには、delete-admin-object サブコマンドを使用します。

1. list-admin-objects(1) サブコマンドで、管理対象オブジェクトを一覧表示します。

2. 必要な場合は、管理対象オブジェクトが削除されることをユーザーに通知してください。

3. delete-admin-object(1) サブコマンドで、管理対象オブジェクトを削除します。

例 15–22 管理対象オブジェクトの削除

この例では、JNDI 名 jms/samplequeue が付いた管理対象オブジェクトを削除します。

asadmin> delete-admin-object jms/samplequeue
Command delete-admin-object executed successfully

参照

コマンド行に asadmin help delete-admin-object と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 16 章 インターネット接続の管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFish^TM Enterprise Server v3 の環境でインターネット接続のタスクを実行する手順について説明します。

ここでは、次のテーマを取り上げます。

• 「インターネット接続について」

• 「HTTP ネットワークリスナーの管理」

• 「仮想サーバーの管理」

本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。

インターネット接続について

HTTP サービスは、Web アプリケーションを配備する機能と、配備した Web アプリケーションをインターネットクライアントからアクセス可能にする機能を提供します。HTTP サービスは、リスナーと仮想サーバーという 2 種類の関連オブジェクトにより提供されます。

ここでは、次のテーマを取り上げます。

• 「HTTP ネットワークリスナーについて」

• 「仮想サーバーについて」

HTTP ネットワークリスナーについて

「HTTP リスナー」はインターネットプロトコル (IP) アドレス、ポート番号、サーバー名、およびデフォルトの仮想サーバーを持つリスナーソケットで、「ネットワークリスナー」とも呼ばれます。各仮想サーバーは、1 つまたは複数のリスナーを通じてサーバーとクライアントの間の接続を提供します。各リスナーは、ポート番号と IP アドレスの一意の組み合わせを持つ必要があります。たとえば、IP アドレス 0.0.0.0 を指定すると、HTTP リスナーは設定されたすべての IP アドレスのホストを特定のポートで待機できます。また、同一ポートを使用して、各リスナーに一意の IP アドレスを指定することもできます。

HTTP リスナーは IP アドレスとポート番号の組み合わせなので、同じ IP アドレスと異なるポート番号の組み合わせ、または異なる IP アドレスと同じポート番号の組み合わせ (これらのアドレスに対応するようにホストが構成されている場合) で、複数の HTTP リスナーを持つことができます。ただし、HTTP リスナーに単一のポート上ですべての IP アドレスを待機する 0.0.0.0 を使用する場合は、この同じポート上に、特定の IP アドレスを待機する HTTP リスナーを作成できません。たとえば、HTTP リスナーが 0.0.0.0: 8080 (ポート 8080 のすべての IP アドレス) を使用する場合、別の HTTP リスナーが 1.2.3.4: 8080 を使用することはできません。Enterprise Server が稼働中のホストは通常、1 つの IP アドレスにのみアクセスします。HTTP リスナーは通常、IP アドレス 0.0.0.0 と複数のポート番号を使用し、各ポート番号が異なる役割に使用されます。ただし、システムが複数の IP アドレスにアクセスできる場合は、各アドレスを異なる役割に使用できます。

Enterprise Server に配備された Web アプリケーションにアクセスするには、Web アプリケーション用に指定したコンテキストルートとともに、http://localhost:8080/ (セキュリティー保護されたアプリケーションでは https://localhost:8081/) という URL を使用します。

管理コンソール にアクセスするには、https://localhost:4848/か http://localhost:4848/asadmin/ (コンソールのデフォルトコンテキストルート) の URL を使用します。

仮想サーバーについて

「仮想サーバー」は、複数のインターネットドメイン名を同一の物理サーバーでホストするためのオブジェクトで、仮想ホストとも呼ばれます。同一物理サーバーでホストされるすべての仮想サーバーが、その物理サーバーの IP アドレスを共有します。仮想サーバーは、サーバーのドメイン名 (www.aaa.com など) と、Enterprise Server が稼動するサーバーを関連付けます。各仮想サーバーは、ネットワークの DNS サーバーに登録する必要があります。

インターネットドメインと Enterprise Server の管理ドメインを混同しないでください。

たとえば、物理サーバーの www.aaa.com、www.bbb.com、および www.ccc.com のドメインをホストする場合を考えます。これらのドメインがそれぞれ、Web モジュール web1、web2、および web3 に関連付けられていると仮定します。つまり、その物理サーバーでは、次の URL が処理されます。

http://www.aaa.com:8080/web1
http://www.bbb.com:8080/web2
http://www.ccc.com:8080/web3

最初の URL は仮想サーバー www.aaa.com、2 番目の URL は仮想サーバー www.bbb.com、3 番目の URL は仮想サーバー www.ccc.com にそれぞれマッピングされます。このマッピングが機能するためには、www.aaa.com、www.bbb.com、および www.ccc.com がすべて、物理サーバーの IP アドレスに解決され、仮想サーバーがネットワークの DNS サーバーに登録される必要があります。さらに、UNIX システムでは、これらのドメインを /etc/hosts ファイルに追加します (/etc/nsswitch.conf ファイルの hosts の設定に files が含まれる場合)。

HTTP ネットワークリスナーの管理

デフォルトでは、Enterprise Server の起動時に次の HTTP リスナーが自動的に開始されます。

• server の名前を持つ仮想サーバーに関連付けられた HTTP リスナー

  • リスナー http-listener-1 では、セキュリティーが有効になっていません。

  • リスナー http-listener-2 では、セキュリティーが有効になっています。

• 仮想サーバー __asadmin に関連付けられた HTTP リスナー admin-listener。このリスナーでは、セキュリティーが有効になっていません。

次の表に、ポートを使用するリスナーについて、Enterprise Server のデフォルトポートを示します。

ここでは、次のテーマを取り上げます。

• 「インターネット接続を作成する」

• 「HTTP プロトコルの管理」

• 「HTTP 構成の管理」

• 「HTTP トランスポートの管理」

• 「HTTP ネットワークリスナーの管理」

インターネット接続を作成する

リスナーのオプションをすべて指定してインターネット接続を作成するには、この手順でサブコマンドを使用します。ネットワークリスナーは、バックグラウンドで作成されます。このプロセスの簡略バージョンについては、「HTTP ネットワークリスナーを作成する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-protocol(1) サブコマンドにオプション --securityenabled を指定して、HTTP または HTTPS プロトコルを作成します。

   組み込みの http-listener-1 HTTP プロトコルまたは http-listener-2 HTTPS プロトコルを使用する場合は、この手順を省略します。

3. create-http(1) サブコマンドを使用して、HTTP 構成を作成します。

   組み込みプロトコルを使用する場合は、この手順を省略します。

4. create-transport(1) サブコマンドを使用して、トランスポートを作成します。

   組み込みの tcp トランスポートを使用する場合は、この手順を省略します。

5. (省略可能) create-threadpool(1) サブコマンドを使用して、スレッドプールを作成します。

   スレッドプールを使用しない場合、または組み込みの http-thread-pool スレッドプールを使用する場合は、この手順を省略します。

   スレッドプールの詳細については、第 5 章スレッドプールの管理を参照してください。

6. create-network-listener(1) サブコマンドを使用して、HTTP リスナーを作成します。

   プロトコルとトランスポートを指定します。スレッドプールは省略可能です。

7. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

参照

コマンド行に asadmin help create-http-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP プロトコルの管理

各 HTTP リスナーは HTTP プロトコルを持ち、この HTTP プロトコルは create-protocol サブコマンドを使用するか、「HTTP ネットワークリスナーを作成する」の手順に従った場合に適用される組み込みプロトコルを使用して作成されます。

ここでは、次のテーマを取り上げます。

• 「プロトコルを作成する」

• 「プロトコルを一覧表示する」

• 「プロトコルを削除する」

プロトコルを作成する

プロトコルを作成するには、リモートモードで create-protocol サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-protocol(1) を使用して、プロトコルを作成します。

   サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。

例 16–1 HTTP プロトコルの作成

この例は、セキュリティーを有効にして、プロトコル http-1 を作成します。

asadmin> create-protocol --securityenabled=true http-1
Command create-protocol executed successfully.

参照

コマンド行に asadmin help create-protocol と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

プロトコルを一覧表示する

既存の HTTP プロトコルを一覧表示するには、リモートモードで list-protocols サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-protocols(1) サブコマンドを使用して、既存のプロトコルを一覧表示します。

例 16–2 プロトコルの一覧表示

この例は、既存のプロトコルを一覧表示します。

asadmin> list-protocols
admin-listener
http-1
http-listener-1
http-listener-2
Command list-protocols executed successfully.

参照

コマンド行に asadmin help list-protocols と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

プロトコルを削除する

プロトコルを削除するには、リモートモードで delete-protocol サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. delete-protocol(1) サブコマンドを使用して、プロトコルを削除します。

例 16–3 プロトコルの削除

この例は、プロトコル http-1 を削除します。

asadmin> delete-protocol http-1
Command delete-protocol executed successfully.

参照

コマンド行に asadmin help delete-protocol と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP 構成の管理

各 HTTP リスナーは HTTP 構成を持ち、この HTTP 構成は、create-http サブコマンドを使用するか、「HTTP ネットワークリスナーを作成する」の手順に従う場合に適用される組み込み構成を使用して作成されます。

ここでは、次のテーマを取り上げます。

• 「HTTP 構成を作成する」

• 「HTTP 構成を削除する」

HTTP 構成を作成する

プロトコルの HTTP パラメータセットを作成するには、リモートモードで create-http サブコマンドを使用します。このパラメータセットは、ネットワークリスナーを 1 つ以上構成します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-http(1) サブコマンドを使用して、HTTP 構成を作成します。

   サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。

例 16–4 HTTP 構成の作成

この例は、http-1 というプロトコルの HTTP パラメータセットを作成します。

asadmin> create-http --timeout-seconds 60 --default-virtual-server server http-1
Command create-http executed successfully.

参照

コマンド行に asadmin help create-http と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP 構成を削除する

プロトコルから HTTP のパラメータセットを削除するには、リモートモードで delete-http サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. delete-http(1) サブコマンドを使用して、プロトコルから HTTP のパラメータを削除します。

例 16–5 HTTP 構成の削除

この例は、http-1 というプロトコルから HTTP のパラメータセットを削除します。

asadmin> delete-http http-1
Command delete-http executed successfully.

参照

コマンド行に asadmin help delete-http と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP トランスポートの管理

各 HTTP リスナーは HTTP トランスポートを持ち、この HTTP トランスポートは、create-transport サブコマンドを使用するか、「HTTP ネットワークリスナーを作成する」の手順に従う場合に適用される組み込みトランスポートを使用して作成されます。

ここでは、次のテーマを取り上げます。

• 「トランスポートを作成する」

• 「トランスポートを一覧表示する」

• 「トランスポートを削除する」

トランスポートを作成する

ネットワークリスナーのトランスポートを作成するには、リモートモードで create-transport サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-transport(1) サブコマンドを使用して、トランスポートを作成します。

   サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。

例 16–6 トランスポートの作成

この例は、アクセプタスレッド数としてデフォルト以外の値を使用する、http1-trans というトランスポートを作成します。

asadmin> create-transport --acceptorthreads 100 http1-trans
Command create-transport executed successfully.

参照

コマンド行に asadmin help create-transport と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

トランスポートを一覧表示する

既存の HTTP トランスポートを一覧表示するには、リモートモードで list-transports サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-transports(1) サブコマンドを使用して、既存のトランスポートを一覧表示します。

例 16–7 HTTP トランスポートの一覧表示

この例は、既存のトランスポートを一覧表示します。

asadmin> list-transports
http1-trans
tcp
Command list-transports executed successfully.

参照

コマンド行に asadmin help list-transports と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

トランスポートを削除する

トランスポートを削除するには、リモートモードで delete-transport サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. delete-transport(1) サブコマンドを使用して、トランスポートを削除します。

例 16–8 トランスポートの削除

この例は、http1-trans というトランスポートを削除します。

asadmin> delete-transport http1-trans
Command delete-transport executed successfully. 

参照

コマンド行に asadmin help delete-transport と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP ネットワークリスナーの管理

ここでは、次のテーマを取り上げます。

• 「HTTP ネットワークリスナーを作成する」

• 「HTTP ネットワークリスナーを一覧表示する」

• 「HTTP ネットワークリスナーを更新する」

• 「HTTP ネットワークリスナーを削除する」

• 「SSL の HTTP リスナーを構成する」

• 「HTTP リスナーから SSL を削除する」

• 「HTTP リスナーにデフォルト仮想サーバーを割り当てる」

HTTP ネットワークリスナーを作成する

リスナーを作成するには、リモートモードで create-http-listener サブコマンドまたは create-network-listener サブコマンドを使用します。これらのサブコマンドは後方互換性を提供し、さらに HTTP プロトコルを使用するネットワークリスナーを作成するためのショートカットも提供します。ネットワークリスナー、関連プロトコル、トランスポート、および HTTP 構成がバックグラウンドで作成されます。このメソッドは便利なショートカットですが、一部のオプションのみにアクセスできます。リスナーのオプションをすべて指定する場合は、「インターネット接続を作成する」の手順に従ってください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-network-listener(1) サブコマンドまたは create-http-listener(1) サブコマンドを使用して、HTTP ネットワークリスナーを作成します。

3. 必要な場合は、サーバーを再起動します。

   admin-listener という名前の特別な HTTP ネットワークリスナーを編集する場合は、変更を有効にするためにサーバーを再起動する必要があります。「ドメインの再起動」を参照してください。

例 16–9 HTTP リスナーの作成

この例は、アクセプタスレッド数としてデフォルト以外の値を使用する、sampleListener という HTTP リスナーを作成します。実行時にセキュリティーは有効になりません。

asadmin> create-http-listener --listeneraddress 0.0.0.0 
--listenerport 7272 --defaultvs server --servername host1.sun.com 
--acceptorthreads 100 --securityenabled=false 
--enabled=false sampleListener
Command create-http-listener executed successfully.

例 16–10 ネットワークリスナーの作成

この例は、実行時に有効にならない sampleListener というネットワークリスナーを作成します。

asadmin> create-network-listener --listenerport 7272 protocol http-1
--enabled=false sampleListenerCommand create-network-listener executed successfully.

参照

コマンド行に asadmin help create-http-listener または asadmin help create-network-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP ネットワークリスナーを一覧表示する

既存の HTTP リスナーを一覧表示するには、リモートモードで list-http-listeners サブコマンドまたは list-network-listeners サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-http-listeners(1) サブコマンドまたは list-network-listeners(1) サブコマンドを使用して、HTTP リスナーを一覧表示します。

例 16–11 HTTP リスナーの一覧表示

この例は、HTTP リスナーを一覧表示します。list-network-listeners サブコマンドを使用しても、同じ結果が得られます。

asadmin> list-http-listeners
admin-listener
http-listener-2
http-listener-1
Command list-http-listeners executed successfully.

参照

コマンド行に asadmin help list-http-listeners または asadmin help list-network-listeners と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP ネットワークリスナーを更新する

1. list-http-listeners(1) サブコマンドまたは list-network-listeners(1) サブコマンドを使用して、HTTP リスナーを一覧表示します。

2. set(1) サブコマンドを使用して、指定リスナーの値を変更します。

   リスナーは、そのドット表記名で指定します。

例 16–12 HTTP ネットワークリスナーの更新

この例は、security-enabled を false に変更します。

asadmin> set "server.network-config.protocols.protocol.
http-listener-2.security-enabled=false"server.network-config.
protocols.protocol.http-listener-2.security-enabled=falseCommand set executed successfully.

HTTP ネットワークリスナーを削除する

既存の HTTP リスナーを削除するには、リモートモードで delete-http-listener サブコマンドまたは delete-network-listener サブコマンドを使用します。これにより、リスナーの通信のセキュリティーが無効になります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-http-listeners(1) サブコマンドを使用して、HTTP リスナーを一覧表示します。

3. delete-http-listener(1) サブコマンドまたは delete-network-listener(1) サブコマンドを使用して、HTTP リスナーを削除します。

4. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 16–13 HTTP リスナーの削除

この例は、sampleListener という HTTP リスナーを削除します。

asadmin> delete-http-listener sampleListener
Command delete-http-listener executed successfully.

参照

コマンド行に asadmin help delete-http-listener または asadmin help delete-network-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

SSL の HTTP リスナーを構成する

指定リスナー内に SSL 要素を作成して構成するには、create-ssl サブコマンドを使用します。これにより、リスナーの通信のセキュリティーが有効になります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-ssl(1) サブコマンドを使用して、HTTP リスナーを構成します。

3. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 16–14 SSL の HTTP リスナーの構成

この例は、http-listener-1 という SSL の HTTP リスナーを有効にします。

asadmin> create-ssl --type http-listener --certname sampleCert http-listener-1
Command create-ssl executed successfully.

参照

コマンド行に asadmin help create-ssl と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP リスナーから SSL を削除する

指定リスナーの SSL 要素を削除するには、リモートモードで delete-ssl サブコマンドを使用します。これにより、リスナーの通信のセキュリティーが無効になります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. delete-ssl(1) サブコマンドを使用して、HTTP リスナーから SSL を削除します。

3. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 16–15 HTTP リスナーからの SSL の削除

この例は、http-listener-1 という HTTP リスナーの SSL を無効にします。

asadmin> delete-ssl --type http-listener http-listener-1
Command delete-http-listener executed successfully.

参照

コマンド行に asadmin help delete-ssl と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

HTTP リスナーにデフォルト仮想サーバーを割り当てる

未定

1. 管理コンソール で、関連する構成の下にある HTTP サービスコンポーネントを開きます。

2. HTTP サービスコンポーネントの下にある HTTP リスナーコンポーネントを開きます。

3. HTTP リスナーを選択するか、新規に作成します。

4. 「デフォルト仮想サーバー」ドロップダウンリストから選択します。

   詳細については、「デフォルトの Web モジュールを仮想サーバーに割り当てる」を参照してください。

参照

詳細については、管理コンソール の「HTTP リスナー」ページの「ヘルプ」ボタンをクリックしてください。

仮想サーバーの管理

仮想サーバーは、特定の URL を対象にコンテンツを提供する仮想 Web サーバーです。複数の仮想サーバーが、同一または異なるホスト名、ポート番号、または IP アドレスを使用して、コンテンツを提供できます。HTTP サービスは、受信した Web 要求を URL に基づいて異なる仮想サーバーに送信します。

Enterprise Server を初めてインストールするときに、デフォルト仮想サーバーが作成されます。新規作成する個々の HTTP サーバーに、デフォルト仮想サーバーを割り当てることができます。

Web コンポーネント (Web モジュール) を含む Web アプリケーションと Java EE アプリケーションを、配備時に仮想サーバーに割り当てることができます。Web モジュールは複数のサーバーに割り当てることができ、仮想サーバーには複数の Web モジュールを割り当てることができます。Web アプリケーションを配備するときに仮想サーバーを指定していない場合、その Web アプリケーションが現在定義されている仮想サーバーのすべてに割り当てられます。その後、追加の仮想サーバーを作成して既存の Web アプリケーションを割り当てる場合は、Web アプリケーションを再配備する必要があります。配備の詳細については、『Sun GlassFish Enterprise Server v3 Application Deployment Guide 』を参照してください。

仮想サーバーのプロパティーを定義するには、asadmin set コマンドを使用します。次に例を示します。

asadmin set server-config.http-service.virtual-server.MyVS.property.sso-enabled="true"

指定の Web アプリケーションについて、一部の仮想サーバーのプロパティーを設定できます。詳細については、『Sun GlassFish Enterprise Server v3 Application Deployment Guide』の「sun-web-app」を参照してください。

ここでは、次のテーマを取り上げます。

• 「仮想サーバーを作成する」

• 「仮想サーバーを一覧表示する」

• 「仮想サーバーを更新する」

• 「仮想サーバーを削除する」

• 「デフォルトの Web モジュールを仮想サーバーに割り当てる」

• 「仮想サーバーをアプリケーションまたはモジュールに割り当てる」

仮想サーバーを作成する

デフォルトでは、Enterprise Server の起動時に次の仮想サーバーが自動的に開始されます。

• server: ユーザー定義のすべての Web モジュールをホスティングする仮想サーバー。

  本稼動環境以外での Web サービスの開発、テスト、配備で必要となる仮想サーバーは、通常、server だけです。

• __asadmin: すべての管理関連 Web モジュール (具体的には &AdminCon ole;) をホスティングする仮想サーバー。このサーバーの使用は制限されています。つまり、この仮想サーバーに Web モジュールを配備することはできません。

ただし本稼動環境では、同一物理サーバー上でユーザーと顧客のそれぞれが専用の Web サーバーを持つように見せる機能をホスティングするため、通常は追加の仮想サーバーも使用されます。

名前付きの仮想サーバーを作成するには、リモートモードで create-virtual-server サブコマンドを使用します。

始める前に

仮想サーバーは、既存の HTTP リスナーを指定する必要があります。仮想サーバーは、すでに別の仮想サーバーが使用している HTTP リスナーを指定できないので、仮想サーバーを新規作成する前に、HTTP リスナーを 1 つ以上作成します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-virtual-server(1) サブコマンドを使用して、仮想サーバーを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 16–16 仮想サーバーの作成

この例は、 localhost に sampleServer という仮想サーバーを作成します。

asadmin> create-virtual-server sampleServer
Command create-virtual-server executed successfully.

参照

コマンド行に asadmin help create-virutal-server と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

仮想サーバーを一覧表示する

既存の仮想サーバーを一覧表示するには、リモートモードで list-virtual-servers サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-virtual-servers(1) サブコマンドを使用して、仮想サーバーを一覧表示します。

例 16–17 仮想サーバーの一覧表示

この例は、localhost の仮想サーバーを一覧表示します。

asadmin> list-virtual-servers
sampleListener
admin-listener
http-listener-2
http-listener-1

Command list-http-listeners executed successfully.

参照

コマンド行に asadmin help list-virutal-servers と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

仮想サーバーを更新する

1. list-virtual-servers(1) サブコマンドを使用して、仮想サーバーを一覧表示します。

2. set(1) サブコマンドを使用して、指定した仮想サーバーの値を変更します。

   仮想サーバーは、ドット表記名で指定します。

仮想サーバーを削除する

既存の仮想サーバーを削除するには、リモートモードで delete-virtual-server サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-virtual-servers(1) サブコマンドを使用して、仮想サーバーを一覧表示します。

3. 必要に応じて、仮想サーバーが削除されることをユーザーに通知します。

4. delete-virtual-server(1) サブコマンドを使用して、仮想サーバーを削除します。

5. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 16–18 仮想サーバーの削除

この例は、localhost から sampleServer という仮想サーバーを削除します。

asadmin> delete-virtual-server sampleServer
Command delete-virtual-server executed successfully.

参照

コマンド行に asadmin help delete-virutal-server と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

デフォルトの Web モジュールを仮想サーバーに割り当てる

デフォルト Web モジュールは、デフォルト仮想サーバーや個々の新しい仮想サーバーに割り当てることができます。仮想サーバーのデフォルト Web モジュールにアクセスするには、ブラウザで仮想サーバーの URL をポイントします。ただし、コンテキストルートは指定しないでください。次に例を示します。

http://myvserver:3184/

デフォルト Web モジュールが割り当てられていない仮想サーバーは、ドキュメントルート (通常は domain-dir /docroot) から HTML または JavaServer Pages^TM ( JSP^TM) のコンテンツを提供します。この HTML または JSP のコンテンツにアクセスするには、ブラウザで仮想サーバーの URL をポイントします。コンテキストルートは指定せず、ターゲットのファイルを指定します。

次に例を示します。

http://myvserver:3184/hellothere.jsp

仮想サーバーをアプリケーションまたはモジュールに割り当てる

配備済みのアプリケーションや Web モジュールに仮想サーバーを割り当てることができます。

始める前に

アプリケーションやモジュールは、すでに配備済みである必要があります。詳細については、『Sun GlassFish Enterprise Server v3 Application Deployment Guide』を参照してください。

1. 管理コンソール で、関連する構成の下にある HTTP サービスコンポーネントを開きます。

2. HTTP サービスコンポーネントの下にある仮想サーバーコンポーネントを開きます。

3. デフォルト Web モジュールを割り当てる仮想サーバーを選択します。

4. 「デフォルト Web モジュール」ドロップダウンリストから、アプリケーションまたは Web モジュールを選択します。

   詳細については、「デフォルトの Web モジュールを仮想サーバーに割り当てる」を参照してください。

第 17 章 ORB (Object Request Broker) の管理

Sun GlassFish^TM Enterprise Server は、相互運用性を保証する一連の標準的なプロトコルと形式をサポートします。これらのプロトコルの中には、CORBA で定義されているものがあります。ORB (Object Request Broker) は、CORBA の中枢となるコンポーネントです。ORB は、オブジェクトの特定と検索、接続管理、およびデータと要求の配信に必要なインフラストラクチャーを提供します。この章では、ORB と IIOP リスナーの設定方法について説明します。

ここでは、次のテーマを取り上げます。

• 「ORB について」

• 「ORB の設定」

• 「IIOP リスナーの管理」

本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。

ORB について

CORBA (Common Object Request Broker Architecture) モデルのベースになっているのは、明確に定義されたインタフェースを介して分散型のオブジェクトやサーバーにサービスを要求するクライアントです。こうしたクライアントは、リモートメソッド要求の形式でオブジェクトに対して要求を発行します。「リモートメソッド要求」では、実行する必要のある操作に関する情報が伝送されます。この情報には、サービスプロバイダのオブジェクト名 (オブジェクト参照) と、存在する場合は、起動メソッドのパラメータが含まれます。CORBA は、オブジェクトの登録、オブジェクトの配置、オブジェクトのアクティブ化、要求の多重分離、エラー処理、整列化、操作のディスパッチをはじめとするネットワークプログラミングのタスクを自動的に処理します。

ORB の設定

個々の CORBA オブジェクトが相互に対話することはありません。代わりに、オブジェクトはリモートスタブを通して、ローカルホストで動作している IIOP (Internet Inter-Orb Protocol) に要求を行います。続いて、ローカルの ORB が IIOP を使用して、ほかのホスト上の ORB に要求を渡します。リモート ORB は、適切なオブジェクトを検出し、要求を処理して、結果を返します。

アプリケーションやオブジェクトでは、RMI-IIOP により、IIOP を RMI (Remote Method Invocation) として使用することが可能になっています。エンタープライズ Bean (EJB モジュール) のリモートクライアントは、RMI-IIOP を使用して Enterprise Server と通信します。

IIOP リスナーの管理

「IIOP リスナー」は、Enterprise JavaBeans のリモートクライアントおよびほかの CORBA ベースのクライアントから受信する接続を受け付ける待機ソケットです。Enterprise Server では、複数の IIOP リスナーを設定できます。各リスナーに対して、ポート番号 (オプション、デフォルトは 1072)、ネットワークアドレス、およびセキュリティー属性 (オプション) を指定してください。複数のリスナーを作成する場合は、リスナーごとに異なるポート番号を割り当てる必要があります。

ここでは、次のテーマを取り上げます。

• 「IIOP リスナーを作成する」

• 「IIOP リスナーを一覧表示する」

• 「IIOP リスナーを更新する」

• 「IIOP リスナーを削除する」

IIOP リスナーを作成する

IIOP リスナーを作成するには、リモートモードで create-iiop-listener サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-iiop-listener(1) サブコマンドを使用して、IIOP リスナーを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 17–1 IIOP リスナーの作成

この例では、sample_iiop_listener という名前の IIOP リスナーを作成します。

asadmin> create-iiop-listener --listeneraddress 192.168.1.100
--iiopport 1400 sample_iiop_listener
Command create-iiop-listener executed successfully.

参照

コマンド行に asadmin help create-iiop-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

IIOP リスナーを一覧表示する

既存の IIOP リスナーを一覧表示するには、リモートモードで list-iiop-listeners サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-iiop-listeners(1) サブコマンドを使用して、IIOP リスナーを一覧表示します。

例 17–2 IIOP リスナーの一覧表示

この例では、サーバーインスタンスの IIOP リスナーをすべて表示します。

asadmin> list-iiop-listeners
 orb-listener-1
SSL
SSL_MUTUALAUTH
sample_iiop_listener
Command list-iiop-listeners executed successfully.

参照

コマンド行に asadmin help list-iiop-listeners と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

IIOP リスナーを更新する

1. list-iiop-listeners(1) サブコマンドを使用して、IIOP リスナーを一覧表示します。

2. set(1) サブコマンドを使用して、指定した IIOP リスナーの値を変更します。

   リスナーは、そのドット表記名で指定します。

例 17–3 IIOP リスナーの更新

この例では、SSL を有効から無効に変更します。

asadmin> set "server.iiop-service.iiop-listener.SSL.enabled"
server.iiop-service.iiop-listener.SSL.enabled=false
Command set executed successfully.

IIOP リスナーを削除する

IIOP リスナーを削除するには、リモートモードで delete-iiop-listener サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-iiop-listeners(1) サブコマンドを使用して、IIOP リスナーを一覧表示します。

3. delete-iiop-listener(1) サブコマンドを使用して、IIOP リスナーを削除します。

4. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 17–4 IIOP リスナーの削除

この例では、sample_iiop_listener という名前の IIOP リスナーを削除します。

asadmin> delete-iiop-listener sample_iiop_listener
 Command delete-iiop-listener executed successfully.

参照

コマンド行に asadmin help delete-iiop-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 18 章 JavaMail サービスの管理

Sun Java^TM Enterprise Server には、JavaMail API、およびアプリケーションコンポーネントでインターネット上で電子メール通知を送信し、IMAP および POP3 メールサーバーから電子メールを読み取ることを可能にする JavaMail サービスプロバイダが含まれています。

ここでは、次のテーマを取り上げます。

• 「JavaMail について」

• 「JavaMail リソースの管理」

本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。

JavaMail について

JavaMail API はメールシステムをモデル化する一連の抽象 API です。JavaMail API は、プラットフォームやプロトコルに依存しないフレームワークを提供して、メールおよびメッセージングアプリケーションを構築し電子メッセージの読み取りと送信の機能を提供します。サービスプロバイダは特定のプロトコルを実装します。API を使用して、アプリケーションに電子メール機能を追加できます。JavaMail は Java アプリケーションから、ネットワークまたはインターネット上の IMAP (Internet Message Access Protocol) および SMTP (メール転送プロトコル) 対応のメールサーバーにアクセスできます。API にはメールサーバー機能がないため、JavaMail を使用するにはメールサーバーにアクセスする必要があります。

JavaMail API は、Java プラットフォームのオプションパッケージとして実装され、Java EE プラットフォームの一部としても使用できます。

JavaMail API の詳細は、JavaMail Web サイト http://java.sun.com/products/javamail/ を参照してください。

JavaMail リソースの管理

メールセッションを作成すると、サーバー側のコンポーネントとアプリケーションが、割り当てたセッションプロパティーを使用して JavaMail サービスと JNDI にアクセス可能になります。メールセッションを作成するときに、メールホスト、トランスポートプロトコルとストアプロトコル、およびデフォルトのメールユーザーを指定できるので、JavaMail を使用するコンポーネントはこれらのプロパティーを設定する必要がありません。Enterprise Server は単一のセッションオブジェクトを作成して、セッションオブジェクトを必要とするすべてのコンポーネントから使用できるようにするので、電子メールを大量に使用するアプリケーションにメリットがあります。

次のような JavaMail 設定を指定できます。

• 「JNDI 名」。メールセッションの一意の名前。JavaMail リソースのネーミングサブコンテキストプレフィックス mail/ を使用することをお勧めします。例: mail/MySession

• 「メールホスト」。デフォルトメールサーバーのホスト名。プロトコル固有のホストプロパティーが提供されていない場合に、Store オブジェクトと Transport オブジェクトの接続メソッドはこの値を使用します。この名前は実際のホスト名として解決可能でなければいけません。

• 「デフォルトユーザー」。メールサーバーへの接続時に渡されるユーザー名。プロトコル固有の username プロパティーが提供されていない場合に、Store オブジェクトと Transport オブジェクトの接続メソッドはこの値を使用します。

• 「デフォルトの返信用アドレス」。デフォルトユーザーの電子メールアドレス。username@host.domain の形式で入力します。

• 「説明」。コンポーネントの説明。

• 「セッション」。今回メールセッションを有効にするか、無効にするかを指定します。

ここでは、次のテーマを取り上げます。

• 「JavaMail リソースを作成する」

• 「JavaMail リソースを一覧表示する」

• 「JavaMail リソースを更新する」

• 「JavaMail リソースを削除する」

JavaMail リソースを作成する

JavaMail セッションリソースを作成するには、リモートモードでサブコマンド create-javamail-resource を使用します。JavaMail セッションリソースの JNDI 名は通例、mail/ の命名サブコンテキスト (例: mail/MyMailSession.) を含みます。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-javamail-resource(1) サブコマンドを使用して、JavaMail リソースを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 18–1 JavaMail リソースの作成

この例は、mail/MyMailSession という名前の JavaMail リソースを作成します。--fromaddress オプションでエスケープ文字 (\) を使用して、ドット (.) とアットマーク (@) を区別します。

asadmin> create-javamail-resource --mailhost localhost 
--mailuser sample --fromaddress sample\@sun\.com mail/MyMailSession 
Command create-javamail-resource executed successfully.

参照

コマンド行に asadmin help create-javamail-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JavaMail リソースを一覧表示する

既存の JavaMail セッションリソースを一覧表示するには、リモートモードで list-javamail-resources サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-javamail-resources(1) サブコマンドを使用して、JavaMail リソースを一覧表示します。

例 18–2 JavaMail リソースの一覧表示

この例は、localhost の JavaMail リソースを一覧表示します。

asadmin> list-javamail-resources 
mail/MyMailSession
Command list-javamail-resources executed successfuly.

参照

コマンド行に asadmin help list-javamail-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JavaMail リソースを更新する

1. list-javamail-resources(1) サブコマンドを使用して、JavaMail リソースを一覧表示します。

2. set(1) サブコマンドを使用して、指定した JavaMail リソースの値を変更します。

   リソースは、ドット表記名で指定します。

例 18–3 JavaMail リソースの更新

この例は、joeserver を joe に変更します。

asadmin> set server.resources.mail-resource.mail/
MyMailSession.user=joeserver.resources.mail-resource.mail/
MyMailSession.user=joe
Command set executed successfully.

JavaMail リソースを削除する

JavaMail セッションリソースを削除するには、リモートモードで delete-javamail-resource サブコマンドを使用します。

始める前に

サブコマンド delete-javamail-resource を実行するには、指定のリソースへの参照を削除しておく必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-javamail-resources(1) サブコマンドを使用して、JavaMail リソースを一覧表示します。

3. delete-javamail-resource(1) サブコマンドを使用して、JavaMail リソースを削除します。

4. 変更内容を適用するために、Enterprise Server を再起動します。

   「ドメインの再起動」を参照してください。

例 18–4 JavaMail リソースの削除

この例は、mail/MyMailSession という名前の JavaMail セッションリソースを削除します。

asadmin> delete-javamail-resource  mail/MyMailSession 
Command delete-javamail-resource executed successfully.

参照

コマンド行に asadmin help delete-javamail-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

第 19 章 JMS (Java Message Service) の管理

Sun では、Sun GlassFish^TM Message Queue ソフトウェアを Sun GlassFish Enterprise Server に統合することで、JMS (Java^TM Message Service) API を実装しています。この章では、asadmin コマンド行ユーティリティーを使用して、Enterprise Server 環境で JMS リソースを管理する手順について説明します。

JMS リソースは、Enterprise Server の Full Platform Profile のみでサポートされ、Web Profile ではサポートされません。

ここでは、次のテーマを取り上げます。

• 「JMS について」

• 「JMS 物理送信先の管理」

• 「JMS 接続ファクトリと送信先の管理」

• 「JMS ホストの管理」

• 「接続のアドレス指定の管理」

• 「JMS のリソースアダプタの設定」

• 「JMS に関するトラブルシューティング」

この章のタスクを 管理コンソール を使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。

JMS について

JMS API は、Java EE アプリケーションおよびコンポーネントで、メッセージの作成、送信、受信、および読み取りを可能にするメッセージング標準です。この API によって、緩やかに結合され、信頼性が高く、非同期の分散通信が可能となります。

一般的に、Enterprise Server の JMS メッセージングのサポートや、特にメッセージ駆動型 Bean のサポートでは、「JMS プロバイダ」が必要です。Enterprise Server は、Sun GlassFish メッセージキュー ソフトウェアをネイティブの JMS プロバイダとして使用し、透過的な JMS メッセージングのサポートを提供します。このサポートは、Enterprise Server では「JMS サービス」と呼ばれます。JMS で必要になるのは最低限の管理のみです。JMS クライアントが JMS 管理対象オブジェクトにはじめてアクセスするときに、クライアントの JVM が Enterprise Server から JMS 構成を受け取ります。

JMS リソースはコネクタの一種です。Message Queue は、「コネクタモジュール」によって Enterprise Server と統合されます。コネクタモジュールはリソースアダプタとも呼ばれ、Java EE Connector Architecture Specification 1.6 で定義されています。Enterprise Server に配備されるすべての Java EE コンポーネントは、コネクタモジュールによって統合された JMS プロバイダを使用して、JMS メッセージを交換します。JMS リソースが Enterprise Server に作成されるときに、コネクタリソースがバックグラウンドで作成されます。JMS 操作はそれぞれコネクタのランタイムを呼び出し、Message Queue コネクタモジュールをバックグラウンドで使用します。Enterprise Server は JMS 接続を自動的にプールします。

すべての JMS 接続で使用されるプロパティーを設定できます。これらのプロパティーを実行時に更新する場合は、プロパティーの更新後に作成された接続ファクトリのみに、更新した値が適用されます。既存の接続ファクトリは元のプロパティー値のままになります。ほとんどの値は、Enterprise Server を再起動して有効にする必要があります。手順については、「ドメインの再起動」を参照してください。Enterprise Server を再起動せずに更新できるプロパティーは、デフォルト JMS ホストだけです。

Message Queue ブローカのモード

Message Queue は、Enterprise Server に LOCAL、REMOTE、または EMBEDDED のモードで統合できます。これらのモードは、JMS の type 属性で表されます。

• 「LOCAL モード」。Enterprise Server は、デフォルト JMS ホストとして指定された Message Queue ブローカを起動または停止します。Message Queue プロセスは、Enterprise Server プロセスとは別の仮想マシンで開始されます。Enterprise Server はブローカに追加ポートを提供し、ブローカはこのポートを使用して RMI レジストリを起動します。このポート番号は、そのインスタンス用に設定された JMS ポートの番号に 100 を足した値になります。たとえば、JMS ポート番号が 37676 である場合、この追加ポートの番号は 37776 になります。

  LOCAL モードでは、「起動引数」属性を使用して Message Queue ブローカの起動パラメータを指定します。

• 「REMOTE モード」。type 属性が REMOTE に設定されている場合は、Message Queue ブローカを Enterprise Server から独立して起動および停止する必要があります。Message Queue のツールを使用して、ブローカを設定および調整する必要があります。この状況では、Enterprise Server は外部で設定されたブローカを使用するか、ブローカクラスタを使用します。「REMOTE」 の type 属性はクラスタ環境にもっとも適しています。

  REMOTE モードでは、Message Queue のツールを使用して、Message Queue ブローカの起動パラメータを指定する必要があります。「起動引数」属性は無視されます。

• 「EMBEDDED モード」 (デフォルト)。JMS の type 属性が EMBEDDED に設定されている場合、Enterprise Server と JMS ブローカは同じ仮想マシンに共存します。JMS サービスは、Enterprise Server によってインプロセスで起動され管理されます。

  EMBEDDED モードでは、JMS 操作はネットワークスタックの処理を省略するため、パフォーマンスが最適化されます。

Message Queue の管理については、『Sun GlassFish Message Queue 4.4 Administration Guide 』を参照してください。

JMS 物理送信先の管理

メッセージは、JMS プロバイダの「物理送信先」を使用して、コンシューマにルーティングおよび配信されます。物理送信先は、管理対象オブジェクト (Topic または Queue 送信先リソースなど) によって識別およびカプセル化されます。アプリケーションコンポーネントはこのオブジェクトを使用して、生成しているメッセージの送信先と、消費しているメッセージの発信元を指定します。送信先リソースを設定する手順については、「接続ファクトリまたは送信先リソースを作成する」を参照してください。

メッセージ駆動型 Bean が配備され、この Bean が待機する物理送信先が存在しない場合、Enterprise Server は自動的に物理送信先を作成し、maxNumActiveConsumers プロパティーの値を -1 に設定します。ただし、あらかじめ物理送信先を作成しておく方がよい方法です。アプリケーションが最初に送信先リソースにアクセスすると、Message Queue は、送信先リソースの名前プロパティーで指定した物理送信先を自動的に作成します。物理送信先は一時的なものなので、Message Queue の構成プロパティーで指定した期限が切れると効力を失います。

ここでは、次のテーマを取り上げます。

• 「JMS 物理送信先を作成する」

• 「JMS 物理送信先を一覧表示する」

• 「物理送信先からメッセージを消去する」

• 「JMS 物理送信先を削除する」

JMS 物理送信先を作成する

本稼動環境では、必ず物理送信先を作成する必要があります。ただし、開発およびテスト段階では、この手順は不要です。物理送信先を作成するには、リモートモードで create-jmsdest サブコマンドを使用します。

物理送信先は、実際にはサーバーオブジェクトというよりも Message Queue オブジェクトであるため、プロパティーを更新する場合は Message Queue ブローカのコマンドを使用します。Message Queue プロパティーの詳細は、『Sun GlassFish Message Queue 4.4 Administration Guide』を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-jmsdest(1) サブコマンドを使用して、JMS 物理送信先を作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 19–1 JMS 物理送信先の作成

この例では、PhysicalQueue という名前のキューを作成します。

asadmin> create-jmsdest --desttype queue --property 
User=public:Password=public PhysicalQueue
Command create-jmsdest executed successfully.

参照

コマンド行に asadmin help create-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS 物理送信先を一覧表示する

既存の JMS 物理送信先を一覧表示するには、リモートモードで list-jmsdest サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jmsdest(1) サブコマンドを使用して、既存の JMS 物理送信先を一覧表示します。

例 19–2 JMS 物理送信先の一覧表示

この例では、デフォルトサーバーインスタンスの物理送信先を一覧表示します。

asadmin> list-jmsdest
PhysicalQueue queue {} 
PhysicalTopic topic {}
Command list-jmsdest executed successfully.

参照

コマンド行に asadmin help list-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

物理送信先からメッセージを消去する

指定したターゲットの JMS サービス構成の物理送信先からメッセージを消去するには、リモートモードで flush-jmsdest サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. flush-jmsdest(1) サブコマンドを使用して、JMS 物理送信先からメッセージを消去します。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 19–3 JMS 物理送信先からのメッセージのフラッシュ

この例では、PhysicalQueue という名前のキューからメッセージを消去します。

asadmin> flush-jmsdest --desttype queue PhysicalQueue
Command flush-jmsdest executed successfully

参照

コマンド行に asadmin help flush-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS 物理送信先を削除する

指定した JMS 物理送信先を削除するには、リモートモードで delete-jmsdest サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jmsdest(1) サブコマンドを使用して、既存の JMS 物理送信先を一覧表示します。

3. delete-jmsdest(1) サブコマンドを使用して、物理送信先を削除します。

例 19–4 物理送信先の削除

この例では、PhysicalQueue という名前のキューを削除します。

asadmin> delete-jmsdest --desttype queue PhysicalQueue
Command delete-jmsdest executed successfully

参照

コマンド行に asadmin help delete-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS 接続ファクトリと送信先の管理

JMS API は、2 種類の管理対象オブジェクトを使用します。「接続ファクトリオブジェクト」は、アプリケーションがプログラムによってほかの JMS オブジェクトを作成できるようにします。「送信先オブジェクト」は、メッセージのリポジトリとして動作します。これらのオブジェクトがどのように作成されるかは、JMS の実装ごとに異なります。Enterprise Server では、次のタスクの実行により JMS が実装されます。

• 接続ファクトリの作成。

• 送信先の作成。送信先の作成には、物理送信先の作成と、物理送信先が参照する送信先リソースの作成が必要です。

JMS アプリケーションは、Java Naming and Directory Interface (JNDI) API を使用して、接続ファクトリと送信先リソースにアクセスします。通常、JMS アプリケーションは 1 つ以上の接続ファクトリと 1 つ以上の宛先を使用します。アプリケーションについて確認するか、アプリケーション開発者に問い合わせることで、作成が必要なリソースを決定できます。リソースを作成する順序は重要ではありません。

Enterprise Server は、次の接続ファクトリオブジェクトを提供します。

• ポイントツーポイント通信で使用する QueueConnectionFactory オブジェクト

• パブリッシュ - サブスクライブ通信で使用する TopicConnectionFactory オブジェクト

• ポイントツーポイント通信とパブリッシュ - サブスクライブ通信の両方で使用できる ConnectionFactory オブジェクト (新しいアプリケーションで推奨)

Enterprise Server は、次の送信先オブジェクトを提供します。

• ポイントツーポイント通信で使用する Queue オブジェクト

• パブリッシュ - サブスクライブ通信で使用する Topic オブジェクト

ここでは、次のテーマを取り上げます。

• 「接続ファクトリまたは送信先リソースを作成する」

• 「JMS リソースを一覧表示する」

• 「接続ファクトリまたは送信先リソースを削除する」

この節で使用するサブコマンドは、接続ファクトリリソースと送信先リソースのどちらの管理にも使用できます。物理送信先を管理する手順については、「JMS 物理送信先の管理」を参照してください。

接続ファクトリまたは送信先リソースを作成する

作成する JMS 接続ファクトリごとに、Enterprise Server はコネクタ接続プールとコネクタリソースを作成します。作成する JMS 送信先ごとに、Enterprise Server はコネクタ管理オブジェクトリソースを作成します。JMS リソースを削除すると、Enterprise Server は自動的にコネクタリソースを削除します。

JMS 接続ファクトリリソースまたは送信先リソースを作成するには、リモートモードで create-jms-resource コマンドを使用します。

asadmin create-jms-resource コマンドで addresslist プロパティーを (host:mqport,host2:mqport,host3:mqport の形式で) 指定するには、コロン (:) を \\ を使用してエスケープします。たとえば、host1\\: mqport,host2\\: mqport,host3\\: mpqport のようになります。エスケープ文字の使用方法については、asadmin(1M) の概念のページを参照してください。

JMS 接続ファクトリを更新するには、更新する接続ファクトリのコネクタ接続プールに対して set サブコマンドを使用します。「コネクタ接続プールを更新する」を参照してください。

送信先を更新するには、管理オブジェクトリソースに対して set サブコマンドを使用します。「管理対象オブジェクトを更新する」を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-jms-resource(1) コマンドを使用して、JMS リソースを作成します。

   このサブコマンドのプロパティーについては、このマニュアルページに記載されています。

3. (省略可能) 必要な場合は、サーバーを再起動します。

   プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。

例 19–5 JMS 接続ファクトリの作成

この例では、JNDI 名が jms/DurableConnectionFactory の javax.jms.ConnectionFactory タイプの接続ファクトリリソースを作成します。ClientId プロパティーは、接続ファクトリのクライアント ID を設定し、接続ファクトリを永続サブスクリプションで使用できるようにします。JMS リソースの JNDI 名には、慣習的に jms/ のネーミングサブコンテキストを含めます。

asadmin> create-jms-resource --restype javax.jms.ConnectionFactory
--description "connection factory for durable subscriptions"
--property ClientId=MyID jms/DurableConnectionFactory
Command create-jms-resource executed successfully.

例 19–6 JMS 送信先の作成

この例では、JNDI 名が jms/MyQueue の送信先リソースを作成します。

asadmin> create-jms-resource --restype javax.jms.Queue 
--property Name=PhysicalQueue jms/MyQueue
Command create-jms-resource executed successfully.

参照

コマンド行に asadmin help create-jms-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS リソースを一覧表示する

既存の接続ファクトリと送信先リソースを一覧表示するには、リモートモードで list-jms-resources サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jms-resources(1) サブコマンドを使用して、既存の JMS リソースを一覧表示します。

例 19–7 すべての JMS リソースの表示

この例では、既存の JMS 接続ファクトリと送信先リソースをすべて表示します。

asadmin> list-jms-resources
jms/Queue
jms/ConnectionFactory
jms/DurableConnectionFactory
jms/Topic
Command list-jms-resources executed successfully

例 19–8 指定したタイプの JMS リソースの一覧表示

この例では、リソースタイプが javax のリソースを一覧表示します。

asadmin> list-jms-resources --restype javax.jms.TopicConnectionFactory 
jms/DurableTopicConnectionFactory 
jms/TopicConnectionFactory 
Command list-jms-resources executed successfully.

参照

コマンド行に asadmin help list-jms-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

接続ファクトリまたは送信先リソースを削除する

指定した接続ファクトリまたは送信先リソースを削除するには、リモートモードで delete-jms-resource サブコマンドを使用します。

始める前に

このサブコマンドを実行する前に、削除する JMS リソースへの参照をすべて削除する必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jms-resources(1) サブコマンドを使用して、既存の JMS リソースを一覧表示します。

3. delete-jms-resource(1) サブコマンドを使用して、JMS リソースを削除します。

例 19–9 JMS リソースの削除

この例では、jms/Queue リソースを削除します。

asadmin> delete-jms-resource jms/Queue
Command delete-jms-resource executed successfully

参照

コマンド行に asadmin help delete-jms-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS ホストの管理

「JMS ホスト」は、Message Queue ブローカを表します。JMS には「JMS ホストリスト」 (AddressList プロパティー) が含まれ、このリストには Enterprise Server が使用するすべての JMS ホストが含まれます。JMS ホストリストには、指定した メッセージキュー ブローカのホストとポートが取り込まれ、JMS ホスト構成が変更されるたびに更新されます。JMS リソースを作成するとき、またはメッセージ駆動型 Bean を配備するときに、リソースまたは Bean が JMS ホストリストを継承します。

JMS ホストリスト内のホストの 1 つが、デフォルト JMS ホストに指定されます。Message Queue ブローカモードが LOCAL に設定されている場合は、Enterprise Server がデフォルト JMS ホストを起動します。

ここでは、次のテーマを取り上げます。

• 「JMS ホストを作成する」

• 「JMS ホストを一覧表示する」

• 「JMS ホストを更新する」

• 「JMS ホストを削除する」

JMS ホストを作成する

Enterprise Server では、デフォルト JMS ホストの default_JMS_host が提供されます。デフォルト JMS ホストは、JMS 送信先の作成や削除など、メッセージキュー ブローカのすべての管理操作を実行するために、Enterprise Server によって使用されます。

通常は、新しい JMS ホストを作成する必要はありません。このタスクは上級ユーザー向けのタスクです。追加の JMS ホストを作成するには、リモートモードで create-jms-host サブコマンドを使用します。

JMS は、実際にはサーバーオブジェクトというよりも Message Queue オブジェクトであるため、プロパティーを更新する場合は Message Queue ブローカのコマンドを使用します。Message Queue プロパティーの詳細は、『Sun GlassFish Message Queue 4.4 Administration Guide』を参照してください。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-jms-host(1) サブコマンドを使用して、JMS ホストを作成します。

   このサブコマンドのプロパティーについては、サブコマンドのマニュアルページを参照してください。

例 19–10 JMS ホストの作成

この例では、MyNewHost という名前の JMS ホストを作成します。

asadmin> create-jms-host --mqhost pigeon --mqport 7677 MyNewHost
Command create-jms-host executed successfully.

参照

コマンド行に asadmin help create-jms-host と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS ホストを一覧表示する

既存の JMS ホストを一覧表示するには、リモートモードで list-jms-hosts サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jms-hosts(1) サブコマンドを使用して、JMS ホストを一覧表示します。

例 19–11 JMS ホストの一覧表示

次のサブコマンドは、既存の JMS ホストを一覧表示します。

asadmin> list-jms-hosts
default_JMS_host
MyNewHost
Command list-jmsdest executed successfully

JMS ホストを更新する

1. list-jms-hosts(1) サブコマンドを使用して、JMS ホストを一覧表示します。

2. set(1) サブコマンドを使用して、JMS ホストを変更します。

例 19–12 JMS ホストの更新

この例では、デフォルト JMS ホストの host 属性の値を変更します。この属性のデフォルト値は localhost です。

asadmin>  set server-config.jms-service.jms-host.default_JMS_host.host=
"archie.india.sun.com"

参照

コマンド行に asadmin help set と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

JMS ホストを削除する

JMS ホストを JMS サービスから削除するには、リモートモードで delete-jms-host サブコマンドを使用します。JMS ホストだけを削除すると、新しい JMS ホストを作成するまで、Message Queue ブローカを起動できなくなります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jms-hosts(1) サブコマンドを使用して、JMS ホストを一覧表示します。

3. delete-jms-host(1) サブコマンドを使用して、JMS ホストを削除します。

例 19–13 JMS ホストの削除

この例では、MyNewHost という名前の JMS ホストを削除します。

asadmin> delete-jms-host MyNewHost
Command delete-jms-host executed successfully.

参照

コマンド行に asadmin help delete-jms-host と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

接続のアドレス指定の管理

一部の JMS リソースは、JMS ホストリスト (AddressList) の構成を使用します。このリストは、Enterprise Server で定義されている JMS ホストのホスト名とポートを指定します。JMS ホスト構成が変更されるたびに、JMS ホストリストは更新されます。JMS ホストリストは、JMS リソースの作成時およびメッセージ駆動型 Bean の配備時に、リソースまたは Bean によって継承されます。

メッセージキュー ソフトウェアでは、AddressList プロパティーは imqAddressList と呼ばれます。

ここでは、次のテーマを取り上げます。

• 「JMS 接続プールの設定」

• 「リモートサーバーへのアクセス」

JMS 接続プールの設定

Enterprise Server は JMS 接続を自動的にプールします。JMS 接続プールが作成されるときに、ManagedConnectionFactory のインスタンスが 1 つ関連付けられます。AddressList プロパティーを ManagedConnectionFactory プロパティーとして設定すると、ManagedConnectionFactory 値の AddressList の構成が、Enterprise Server で定義された値よりも優先されます。

create-connector-connection-pool サブコマンドを使用して、既存のプールを管理します。手順については、「コネクタ接続プールの管理」を参照してください。

デフォルトでは、JMS サービス属性の addresslist-behavior が random に設定されます。この場合、ManagedConnectionFactory から作成された各物理送信先 (ManagedConnection) は、主ブローカを AddressList プロパティーからランダムに選択します。

接続が失われたときに Enterprise Server が主ブローカに再接続を試みるかどうかを指定するには、set(1) サブコマンドを使用して、JMS サービスの reconnect-enabled 属性を設定します。再試行の回数と間隔を指定するには、それぞれ reconnect-attempts 属性と reconnect-interval-in-seconds 属性で設定します。

再接続が有効な場合に主ブローカで障害が発生すると、Enterprise Server は JMS ホストリスト (AddressList) の別のブローカに再接続を試みます。スキャンのロジックは、addresslist-behavior と addresslist-iterations の 2 つの JMS サービス属性で決定されます。これらの設定は、JMS 接続ファクトリ設定を使用してオーバーライドできます。Sun GlassFish メッセージキュー ソフトウェアは、フェイルオーバーが発生したときに、負荷を別のブローカに透過的に転送します。JMS のセマンティクスはフェイルオーバー中も維持されます。

リモートサーバーへのアクセス

プロバイダとホストをリモートシステムに変更すると、すべての JMS アプリケーションがリモートサーバーで実行するようになります。ローカルサーバーと、1 つまたは複数のリモートサーバーの両方を使用するには、AddressList プロパティーを使用して接続ファクトリリソースを作成します。これにより、リモートサーバーにアクセスする接続が作成されます。

JMS のリソースアダプタの設定

Enterprise Server は、jmsra という名前のシステムリソースアダプタを使用して JMS を実装します。JMS リソースを作成するときに、Enterprise Server は自動的にコネクタリソースを作成します。リソースアダプタの設定により、JMS プロバイダが XA をサポートするかどうかを指定できます。JMS プロバイダで可能な統合のモードを指定することもできます。

リソースアダプタでは、2 つの統合のモードをサポートしています。最初のモードは、統合の手段として JNDI を使用します。この場合、管理対象オブジェクトが JMS プロバイダの JNDI ツリーに設定され、汎用リソースアダプタがそれらを検索して使用します。このモードが統合に適切でない場合は、JMS 管理対象オブジェクト JavaBean クラスの Java リフレクションを統合のモードとして使用することもできます。

JMS の汎用リソースアダプタ 1.6 は、外部 JMS プロバイダ (IBM WebSphere MQ、Tibco EMS、Sonic MQ など) の JMS クライアントライブラリをラップできる Java EE コネクタ 2.0 リソースアダプタです。これにより、すべての JMS プロバイダは Sun GlassFish Enterprise Server などの Java EE 6 アプリケーションサーバーに統合されます。アダプタは、Java EE 6 アプリケーションサーバーの管理ツールを使用して配備および設定可能な .rar アーカイブです。

汎用リソースアダプタを設定する

汎用リソースアダプタを配備する前に、Enterprise Server が JMS クライアントライブラリを使用できるようにする必要があります。一部の JMS プロバイダでは、クライアントライブラリにネイティブライブラリが含まれている場合もあります。この場合は、これらのネイティブライブラリをすべての Enterprise Server JVM から使用できるようにする必要があります。

1. コネクタモジュールを配備する場合と同じように、汎用リソースアダプタを配備します。

2. コネクタ接続プールを作成します。

   「コネクタ接続プールを作成する」を参照してください。

3. コネクタリソースを作成します。

   「コネクタリソースを作成する」参照してください。

4. 管理対象オブジェクトリソースを作成します。

   「管理対象オブジェクトリソースを作成する」を参照してください。

5. セキュリティーの Enterprise Server ポリシーファイルに次の変更を行います。

   • sjsas_home/domains/domain1/config/server.policy ファイルに、次の行を追加します。

     java.util.logging.LoggingPermission "control"

   • sjsas_home/lib/appclient/client.policy ファイルに、次のアクセス権を追加します。

     javax.security.auth.PrivateCredentialPermission "javax.resource.spi.security.PasswordCredential ^ \"^\"","read":

JMS に関するトラブルシューティング

Enterprise Sever の起動時に、JMS サービスは使用可能になっていますが、必要になる (たとえば、JMS リソースを作成するとき) まで読み込まれません。jms-ping(1) サブコマンドを使用して、JMS サービスが動作しているか確認し、動作していない場合はサービスを起動します。jms-ping サブコマンドが組み込みの JMS サービスと通信できない場合は、エラーメッセージが表示されます。

問題が起きた場合は、次の点を考慮してください。

• Enterprise Server のログファイルを確認します。通常、ログファイルは domain-dir/logs/server.log にあります。

  ログファイルで Message Queue ブローカがメッセージに応答していないことを確認できた場合は、ブローカを停止して再起動します。

• ブローカのログファイルを確認します。通常、このファイルは as-install /domains/domain1/imq/instances/imqbroker/log/log.txt にあります。

• JMS の REMOTE モードでは、Message Queue を起動したあとに Enterprise Server を起動する必要があります。

• すべての Message Queue ブローカが停止している場合、JMS のデフォルト値を使用しているときは、Enterprise Server の停止または起動に 30 分かかります。このタイムアウトのデフォルト値は変更できます。次に例を示します。

  asadmin set domain1.jms-service.reconnect-interval-in-seconds=5

第 20 章 Java Naming and Directory Interface (JNDI) サービスの管理

Java Naming and Directory Interface (JNDI) API は、別の種類のネームサービスおよびディレクトリサービスにアクセスするために使用されます。Java EE コンポーネントは、JNDI ルックアップメソッドを起動することによってオブジェクトを検出します。

ここでは、次のテーマを取り上げます。

• 「JNDI について」

• 「JNDI リソースの管理」

JNDI について

アプリケーションは JNDI API を呼び出すことにより、リソースとほかのプログラムオブジェクトを検出します。「リソース」は、データベースサーバーやメッセージングシステムなどのシステムへの接続を提供するプログラムオブジェクトです。JDBC リソースはデータソースと呼ばれる場合もあります。それぞれのリソースオブジェクトは人間が理解しやすい 「JNDI 名」という一意の名前で識別されます。リソースオブジェクトと JNDI 名は、Enterprise Server に含まれているネーミングおよびディレクトリサービスによって相互にバインドされています。

新しい名前とオブジェクトのバインドが JNDI に入力されると、新しいリソースが作成されます。

ここでは、次のテーマを取り上げます。

• 「Java EE ネーミング環境」

• 「ネーミング環境とコンテナの動作」

• 「ネーミング参照とバインディング情報」

Java EE ネーミング環境

JNDI 名は、Java EE サーバーが提供するネームサービスとディレクトリサービスによってオブジェクトにバインドされます。Java EE コンポーネントは JNDI API を介してこのサービスにアクセスするので、通常オブジェクトはその JNDI 名を使用します。たとえば、PointBase データベースの JNDI 名は jdbc/Pointbase となります。Enterprise Server は、起動時に構成ファイルから情報を読み取り、自動的に JNDI データベース名を名前空間に追加します。そのうちの 1 つが jdbc/Pointbase です。

Java EE アプリケーションクライアント、Enterprise JavaBeans、および Web コンポーネントは、JNDI ネーミング環境にアクセスする必要があります。

アプリケーションコンポーネントのネーミング環境は、配備またはアセンブリの際に、アプリケーションコンポーネントのビジネスロジックのカスタマイズを可能にするメカニズムです。この環境では、コンポーネントからソースコードにアクセスしたりソースコードを変更することなく、アプリケーションコンポーネントをカスタマイズすることができます。Java EE コンテナは、環境を「JNDI ネーミングコンテキスト」として実装し、アプリケーションコンポーネントのインスタンスに提供します。

ネーミング環境とコンテナの動作

アプリケーションコンポーネントの環境は次のとおり使用されます。

• アプリケーションコンポーネントのビジネスメソッドは JNDI インタフェースを使用して環境にアクセスします。アプリケーションコンポーネントプロバイダは、アプリケーションコンポーネントが実行時に環境内で提供されると期待しているすべての環境エントリを、配備記述子で宣言します。

• コンテナは、アプリケーションコンポーネントの環境を格納する JNDI ネーミングコンテキストの実装を提供します。また、コンテナは、配備担当者が各アプリケーションコンポーネントの環境を作成し、管理するツールも提供します。

• 配備担当者は、コンテナが提供するツールを使用して、アプリケーションコンポーネントの配備記述子で宣言された環境エントリを初期化します。配備担当者は環境エントリの値を設定し、変更します。

• コンテナは、実行時にアプリケーションコンポーネントのインスタンスで JNDI コンテキストを利用できるようにします。これらのインスタンスは、JNDI インタフェースを使用して環境エントリの値を取得します。

各アプリケーションコンポーネントは、自身の一連の環境エントリを定義します。同じコンテナ内のすべてのアプリケーションコンポーネントのインスタンスは、同じ環境エントリを共有します。アプリケーションコンポーネントのインスタンスは、実行時に環境を変更することはできません。

ネーミング参照とバインディング情報

「リソース参照」は、リソース用にコード化されたコンポーネントの名前を識別する配備記述子の要素です。たとえば、jdbc/SavingsAccountDB です。具体的には、コード化された名前はリソースの接続ファクトリを参照します。

リソースの JNDI 名とリソース参照名は同じではありません。このネーミングへのアプローチでは、配備前に 2 つの名前をマップする必要がありますが、同時にコンポーネントをリソースから分離します。この分離により、あとでコンポーネントが別のリソースにアクセスする必要があっても、名前を変更する必要がなくなります。この柔軟性により、既存のコンポーネントから Java EE アプリケーションを簡単にアセンブルすることが可能になります。

次の表に、Enterprise Server で使用される J2EE リソースの JNDI 検索と関連するリソース参照 を示します。

JNDI リソースの管理

Enterprise Server 内で、カスタムリソースおよび外部 JNDI リソース用に環境を設定できます。カスタムリソースはローカル JNDI リポジトリにアクセスし、外部リソースは外部 JNDI リポジトリにアクセスします。どちらのタイプのリソースにも、ユーザーが指定したファクトリクラスの要素や JNDI 名前属性などが必要です。

• 「カスタム JNDI リソースの管理」

• 「外部 JNDI リソースの管理」

カスタム JNDI リソースの管理

カスタムリソースは、javax.naming.spi.ObjectFactory インタフェースを実装するサーバー全体のカスタムリソースオブジェクトファクトリを指定します。ここでは、次のテーマを取り上げます。

• 「カスタム JNDI リソースを作成する」

• 「カスタム JNDI リソースを一覧表示する」

• 「カスタム JNDI リソースを更新する」

• 「カスタム JNDI リソースを削除する」

カスタム JNDI リソースを作成する

カスタムリソースを作成するには、リモートモードで create-custom-resource サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-custom-resource(1) サブコマンドを使用して、カスタムリソースを作成します。

   サブコマンドのプロパティーについては、サブコマンドのマニュアルページを参照してください。

3. Enterprise Serverを再起動します。

   「ドメインの再起動」を参照してください。

例 20–1 カスタムリソースの作成

この例では、sample-custom-resource という名前のカスタムリソースを作成します。

asadmin> create-custom-resource --restype topic --factoryclass com.imq.topic 
sample_custom_resource
Command create-custom-resource executed successfully.

参照

コマンド行に asadmin help create-custom-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

カスタム JNDI リソースを一覧表示する

既存のカスタムリソースを一覧表示するには、リモートモードで list-custom-resources サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-custom-resources(1) サブコマンドを使用して、カスタムリソースを一覧表示します。

例 20–2 カスタムリソースの一覧表示

この例では、既存のカスタムリソースを一覧表示します。

asadmin> list-custom-resources
sample_custom_resource01 
sample_custom_resource02 
Command list-custom-resources executed successfully

参照

コマンド行に asadmin help list-custom-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

カスタム JNDI リソースを更新する

1. list-custom-resources(1) サブコマンドを使用して、カスタムリソースを一覧表示します。

2. set(1) サブコマンドを使用して、カスタム JNDI リソースを変更します。

例 20–3 カスタム JNDI リソースの更新

この例では、カスタムリソースを変更します。

asadmin> set server.resources.custom-resource.custom
/my-custom-resource.property.value=2010server.resources.custom-resource.custom
/my-custom-resource.property.value=2010

カスタム JNDI リソースを削除する

カスタムリソースを削除するには、リモートモードで delete-custom-resource サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-custom-resources(1) サブコマンドを使用して、カスタムリソースを一覧表示します。

3. delete-custom-resource(1) サブコマンドを使用して、カスタムリソースを削除します。

例 20–4 カスタムリソースの削除

この例では、sample-custom-resource という名前のカスタムリソースを削除します。

asadmin> delete-custom-resource sample_custom_resource
Command delete-custom-resource executed successfully.

参照

コマンド行に asadmin help delete-custom-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

外部 JNDI リソースの管理

Enterprise Server 上で動作しているアプリケーションでは、外部 JNDI リポジトリに保存されているリソースへのアクセスが必要となる場合があります。たとえば、汎用の Java オブジェクトを Java スキーマに従って LDAP サーバーに格納する場合があります。外部 JNDI リソース要素を使用すると、このような外部リソースリポジトリを設定できます。

ここでは、次のテーマを取り上げます。

• 「外部 JNDI リソースを登録する」

• 「外部 JNDI リソースを一覧表示する」

• 「外部 JNDI エントリを一覧表示する」

• 「外部 JNDI リソースを更新する」

• 「外部 JNDI リソースを削除する」

• 「外部 JNDI リソースの使用例」

外部 JNDI リソースを登録する

外部 JNDI リソースを登録するには、リモートモードで create-jndi-resource サブコマンドを使用します。

始める前に

外部 JNDI ファクトリは、javax.naming.spi.InitialContextFactory インタフェースを実装する必要があります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. create-jndi-resource(1) サブコマンドを使用して、外部 JNDI リソースを登録します。

   サブコマンドのプロパティーについては、サブコマンドのマニュアルページを参照してください。

3. Enterprise Serverを再起動します。

   「ドメインの再起動」を参照してください。

例 20–5 外部 JNDI リソースの登録

この例では、sample_jndi_resource が登録されています。

asadmin> create-jndi-resource --jndilookupname sample_jndi 
--restype queue --factoryclass sampleClass --description "this is a sample jndi 
resource" sample_jndi_resource
Command create-jndi-resource executed successfully

参照

コマンド行に asadmin help create-jndi-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

外部 JNDI リソースを一覧表示する

既存の JNDI リソースをすべて表示するには、リモートモードで list-jndi-resources サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jndi-resources(1) サブコマンドを使用して、既存の JNDI リソースを一覧表示します。

例 20–6 JNDI リソースの一覧表示

この例では、JNDI リソースを一覧表示します。

asadmin> list-jndi-resources
jndi_resource1
jndi_resource2
jndi_resource3
Command list-jndi-resources executed successfully

参照

コマンド行に asadmin help list-jndi-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

外部 JNDI エントリを一覧表示する

JNDI ツリーでエントリを参照および一覧表示するには、リモートモードで list-jndi-entries サブコマンドを使用します。すべてのエントリを表示するか、JNDI コンテキストまたはサブコンテキストを指定して特定のエントリだけを一覧表示できます。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. list-jndi-entries(1) サブコマンドを使用して、構成の JNDI エントリを一覧表示します。

例 20–7 JNDI エントリの一覧表示

この例では、ネームサービスの JNDI エントリをすべて表示します。

asadmin> list-jndi-entries
jndi_entry03
jndi_entry72
jndi_entry76
Command list-jndi-resources executed successfully

参照

コマンド行に asadmin help list-jndi-entries と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

外部 JNDI リソースを更新する

1. list-jndi-resources(1) サブコマンドを使用して、既存の JNDI リソースを一覧表示します。

2. set(1) サブコマンドを使用して、外部 JNDI リソースを変更します。

例 20–8 外部 JNDI リソースの更新

この例では、外部リソースを変更します。

asadmin> set server.resources.external-jndi-resource.my-jndi-resource.
jndi-lookup-name=bar server.resources.external-jndi-resource.my-jndi-resource.jndi-lookup-name=bar 

外部 JNDI リソースを削除する

JNDI リソースを削除するには、リモートモードで delete-jndi-resource サブコマンドを使用します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. delete-jndi-resource(1) サブコマンドを使用して、外部 JNDI エントリを削除します。

例 20–9 外部 JNDI リソースの削除

この例では、外部 JNDI リソースを削除します。

asadmin> delete-jndi-resource jndi_resource2
Command delete-jndi-resource executed successfully.

参照

コマンド行に asadmin help delete-jndi-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

外部 JNDI リソースの使用例

<resources>
 <!-- external-jndi-resource element specifies how to access J2EE resources
 -- stored in an external JNDI repository. This example
 -- illustrates how to access a java object stored in LDAP.
 -- factory-class element specifies the JNDI InitialContext factory that
 -- needs to be used to access the resource factory. property element
 -- corresponds to the environment applicable to the external JNDI context
 -- and jndi-lookup-name refers to the JNDI name to lookup to fetch the
 -- designated (in this case the java) object.
 -->
  <external-jndi-resource jndi-name="test/myBean"
      jndi-lookup-name="cn=myBean"
      res-type="test.myBean"
      factory-class="com.sun.jndi.ldap.LdapCtxFactory">
    <property name="PROVIDER-URL" value="ldap://ldapserver:389/o=myObjects" />
    <property name="SECURITY_AUTHENTICATION" value="simple" />
    <property name="SECURITY_PRINCIPAL", value="cn=joeSmith, o=Engineering" />
    <property name="SECURITY_CREDENTIALS" value="changeit" />
  </external-jndi-resource>
</resources>

第 21 章 トランザクションの管理

この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFish^TM Enterprise Server 環境でトランザクションサービスを管理する方法について説明します。トランザクションを手動で回復する手順についても説明します。

ここでは、次のテーマを取り上げます。

• 「トランザクションについて」

• 「トランザクションサービスの管理」

• 「トランザクションの回復」

本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。トランザクションサービス、トランザクションログ、および分散トランザクションの回復の設定については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 15 章「Using the Transaction Service」を参照してください。

トランザクションについて

「トランザクション」は、アプリケーション内の独立したアクションをひと続きにまとめたもので、一連のアクションのすべてが正常に完了する必要があります。トランザクションでは、1 つ以上のアクションをそれ以上分割不可能な作業単位にまとめることで、データの完全性と整合性を保証しています。すべてのアクションが完了しなかった場合、変更はロールバックされます。

たとえば、当座預金口座から普通預金口座に資金を移動する場合は、一般的に次のような手順が発生します。

1. 当座預金口座にその移動をカバーするだけの金額があるかどうかを確認します。

2. その金額を当座預金口座の借方に記帳します。

3. その金額を普通預金口座の貸方に記帳します。

4. その移動を当座預金口座ログに記録します。

5. その移動を普通預金口座ログに記録します。

これらの手順をまとめて、1 つのトランザクションと見なします。

すべての手順が正常に完了すれば、トランザクションは「コミット」されます。いずれかの手順が失敗した場合は、それ以前の手順で行われた変更がすべてロールバックされ、当座預金口座と普通預金口座はトランザクションが開始される前の状態に戻されます。この種類のイベントは「ロールバック」と呼ばれます。通常のトランザクションは、コミットされた状態かロールバックされた状態で終了します。

次の要素は、さまざまな API と機能を実装することで、信頼性の高いトランザクション処理に貢献します。

• 「トランザクションマネージャー」。トランザクション境界、トランザクションリソース管理、同期化、およびトランザクションコンテキスト伝達のサポートに必要なサービスと管理機能を提供します。

• 「Enterprise Server」。トランザクション状態管理を含むアプリケーション実行環境のサポートに必要なインフラストラクチャーを提供します。

• 「リソースマネージャー」。リソースアダプタを通して、アプリケーションがリソースにアクセスできるようにします。リソースマネージャーは、トランザクションマネージャーがトランザクションの関連付け、トランザクションの完了、および回復作業の伝達に使用するトランザクションリソースインタフェースを実装することで、分散トランザクションに参加します。このようなリソースマネージャーの例としては、リレーショナルデータベースサーバーがあります。

• 「リソースアダプタ」。Enterprise Server またはクライアントがリソースマネージャーへの接続に使用する、システムレベルのソフトウェアライブラリです。通常、リソースアダプタはリソースマネージャーに固有です。リソースアダプタはライブラリとして使用可能で、クライアントのアドレス空間内で使用されます。リソースアダプタの例として、Java^TM Database Connectivity (JDBC) ドライバがあります。サポートされている JDBC ドライバについては、「JDBC ドライバに固有の構成」を参照してください。

• 「トランザクションユーザーアプリケーション」。Enterprise Server 環境では、トランザクションユーザーアプリケーションは Java Naming and Directory Interface (JNDI) を使用して、トランザクションデータソースおよびオプションのユーザートランザクションを検索します。アプリケーションは、Enterprise Bean の宣言的なトランザクション属性設定や、プログラムによる明示的なトランザクション境界設定を使用する場合があります。

トランザクションサービスの管理

この節で説明する asadmin サブコマンドを使用して、単一のトランザクションをロールバックできます。ロールバックを行うには、アクティブなトランザクションを表示して、ロールバックが必要なトランザクションを正しく識別できるように、トランザクションサービスを停止する必要があります。また、これらの操作のあと、トランザクションサービスを再開する必要があります。

トランザクションサービスの設定と自動回復の設定の手順については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 15 章「Using the Transaction Service」を参照してください。

ここでは、次のテーマを取り上げます。

• 「トランザクションサービスを停止する」

• 「トランザクションをロールバックする」

• 「トランザクションサービスを再開する」

トランザクションサービスを停止する

トランザクションサービスを停止するには、リモートモードで freeze-transaction-service サブコマンドを使用します。トランザクションサービスを停止すると、実行中のすべてのトランザクションがただちに中断されます。実行中のトランザクションをロールバックする前に、トランザクションサービスを停止する必要があります。

停止されたトランザクションサブシステムでこのサブコマンドを実行しても、影響はありません。トランザクションサービスは、unfreeze-transaction-service サブコマンドを使用して再開するまで、中断されたままになります。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. freeze-transaction-service(1) サブコマンドを使用して、トランザクションサービスを停止します。

例 21–1 トランザクションサービスの停止

この例では、トランザクションサービスを停止します。

asadmin> freeze-transaction-service
Command freeze-transaction-service executed successfully

参照

コマンド行に asadmin help freeze-transaction-service と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

トランザクションをロールバックする

状況に応じて、特定のトランザクションをロールバックできます。トランザクションをロールバックする前に、トランザクション処理を中断するためにトランザクションサービスを停止する必要があります。特定のトランザクションをロールバックするには、リモートモードで rollback-transaction サブコマンドを使用します。

始める前に

実行中のトランザクションをロールバックする前に、トランザクションサービスを停止します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. ロールバックするトランザクションの ID を確認します。

   アクティブなトランザクションの ID を一覧表示するには、get サブコマンドを使用して activeids 統計の監視データを取得します。「トランザクションサービスの統計」を参照してください。

3. rollback-transaction(1) サブコマンドを使用して、トランザクションをロールバックします。

例 21–2 トランザクションのロールバック

この例では、トランザクション ID が 0000000000000001_00 のトランザクションをロールバックします。

asadmin> rollback-transaction 0000000000000001_00
Command rollback-transaction executed successfully

参照

コマンド行に asadmin help rollback-transaction と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

トランザクションサービスを再開する

中断されている実行中のトランザクションをすべて再開するには、リモートモードで unfreeze-transaction-service サブコマンドを使用します。トランザクションサービスを凍結したあとは、このサブコマンドを実行してサービスを再開します。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. unfreeze-transaction-service(1) サブコマンドを使用して、中断されているトランザクションサービスを再開します。

例 21–3 トランザクションサービスの再開

この例では、凍結されているトランザクションサービスを再開します。

asadmin> unfreeze-transaction-service
Command unfreeze-transaction-service executed successfully

参照

コマンド行に asadmin help unfreeze-transaction-service と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。

トランザクションの回復

一般的にサーバーまたはリソースマネージャーのクラッシュが原因で、コミットまたはロールバックの処理が中断される場合があります。クラッシュが発生すると、一部のトランザクションがステップの間に取り残される可能性があります。Enterprise Server は、これらの障害を回復し、サーバーの起動時にそのトランザクションを完了するように設計されています。失敗したトランザクションが複数のサーバーにわたっている場合は、トランザクションを開始したサーバーがトランザクションの結果を取得しようとしてほかのサーバーに問い合わせる場合があります。ほかのサーバーにアクセスできない場合、トランザクションは特殊な結果判別の情報を使用して、その結果を判別します。トランザクションはサーバーの起動時に解決されます。

クラッシュ以外の障害が発生している場合は、次の手順で手動回復を実行することができます。

トランザクションを手動で回復する

サーバー上のリソースで障害が発生したときに保留中になったトランザクションを手動で回復するには、リモートモードで recover-transactions サブコマンドを使用します。サーバーがクラッシュしたあとに、手動のトランザクション回復を使用してトランザクションを回復することはできません。手動による操作は、リソースで予期しない障害が発生しても、まだサーバーが動作している状況での回復を目的としています。サーバーがクラッシュした場合、不確かなトランザクションを回復できるのは、完全な起動による回復処理だけです。

1. サーバーが実行されていることを確認します。

   リモートサブコマンドには、実行中のサーバーが必要です。

2. recover-transactions(1) サブコマンドを使用して、トランザクションを手動で回復します。

例 21–4 手動によるトランザクションの回復

この例では、sampleserver でトランザクションの手動回復を実行します。

asadmin recover-transactions sampleserver
Transaction recovered.

参照

コマンド行に asadmin help recover-transactions と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。