この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server v3 環境でデータベース接続タスクを実行する手順について説明します。
ここでは、次のテーマを取り上げます。
これらのタスクを管理コンソールを使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。
データベース管理システム (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 ドライバの統合」を参照してください。
実行時には、アプリケーションがデータベースに接続するときに次の一連の処理が発生します。
アプリケーションは JNDI API を通して呼び出しを行い、データベースに関連付けられた JDBC リソースを取得します。
リソースの JNDI 名を使用して、ネームサービスとディレクトリサービスが JDBC リソースを検索します。JDBC リソースはそれぞれ接続プールを指定します。
アプリケーションは JDBC リソースを使用してデータベース接続を取得します。
Enterprise Server は、データベースに対応する接続プールから物理接続を取得します。プールは、データベース名 (URL)、ユーザー名、パスワードなどの接続属性を定義します。
データベース接続が確立されると、アプリケーションはデータベースに対してデータの読み取り、変更、および追加を実行できるようになります。
アプリケーションは JDBC API を呼び出すことにより、データベースにアクセスします。JDBC ドライバはアプリケーションの JDBC 呼び出しをデータベースサーバーのプロトコルに変換します。
データベースへのアクセスが完了すると、アプリケーションは接続を閉じ、接続を接続プールに戻します。
多くのアプリケーションは、リレーショナルデータベースを使用してデータを保存、編成、および取得します。アプリケーションは、JDBC (JavaTM Database Connectivity) API を通してリレーショナルデータベースにアクセスします。
ここでは、次のテーマを取り上げます。
サポートされたデータベース製品をインストールします。
Enterprise Server でサポートされているデータベース製品の最新のリストを確認するには、『Sun GlassFish Enterprise Server v3 リリースノート』を参照してください。
データベース製品用のサポートされている JDBC ドライバをインストールします。
Enterprise Server でサポートされているドライバのリストについては、「JDBC ドライバに固有の構成」を参照してください。
ドメイン管理サーバー (DAS) が JDBC ドライバの JAR ファイルにアクセスできるようにします。
「JDBC ドライバの統合」を参照してください。
データベースを作成します。
通常はアプリケーションプロバイダが、データベースを作成しデータを生成するためのスクリプトを提供しています。
Enterprise Server には、Java DB (以前の名称は Derby) の実装が含まれていますが、JDBC に準拠した任意のデータベースも使用できます。データベースは Enterprise Server の起動時に自動では起動されません。したがって、データベースを必要とするアプリケーションを使用する場合は、start-database サブコマンドを使用して Java DB を手動で起動する必要があります。
start-database(1) サブコマンドを使用して、データベースを起動します。
データベースサーバーの起動時、またはクライアントがデータベースサーバーに正常に接続したときに、--dbhome オプションで指定された場所に次のファイルが作成されます。
derby.log ファイルには、データベースサーバープロセスのログが、標準出力および標準エラー情報とともに保存されます。
データベースのファイルには、使用するスキーマ (たとえば、データベース表) が保存されます。
この例では、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 を停止します。同一のホストのほかのポートで、複数のデータベースサーバープロセスが動作している場合があります。
必要に応じて、データベースを停止することをユーザーに通知します。
stop-database(1) サブコマンドを使用して、データベースを停止します。
この例では、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Enterprise Server で利用できる Java DB の構成には、Java DB の使用に役立つスクリプトが含まれます。次のスクリプトが、as-install/javadb/frameworks/NetworkServer/bin ディレクトリに格納されています。
ネットワークサーバーを起動するスクリプト
ネットワークサーバーを停止するスクリプト
対話式の JDBC スクリプト作成ツール
データベースのすべてまたは一部の DDL を表示するスクリプト
Java DB 環境に関するバージョン情報を表示するスクリプト
NetworkServerControl API でコマンドを実行するスクリプト
JAVA_HOME 環境変数が JDK のインストールディレクトリを指定していることを確認します。
as-install/derby ディレクトリをポイントするように JAVADB_HOME 環境変数を設定します。
これらのユーティリティーの詳細については、次のドキュメントを参照してください。
『Derby Server and Administration Guide』 (http://db.apache.org/derby/docs/10.1/adminguide/)
データベース接続を確立したら、Enterprise Server アプリケーションのアクセス設定を実行できます。データベースにアクセスする前に、アプリケーションは接続を取得する必要があります。
ここでは、次のテーマを取り上げます。
「JDBC 接続プール」は、特定のデータベースのための再利用可能な接続のグループです。新しい物理接続の作成には時間がかかるため、Enterprise Server は使用可能な接続のプールを維持します。アプリケーションが接続を要求すると、プールから 1 つの接続が取得されます。アプリケーションが接続を閉じると、接続はプールに返されます。
JDBC リソースは、リソースが関連付けられている接続プールを指定することで作成されます。複数の JDBC リソースが 1 つの接続プールを指定することもできます。接続プールのプロパティーは、データベースベンダーによっては異なる場合もあります。共通のプロパティーには、データベースの名前 (URL)、ユーザー名、パスワードなどがあります。
次のタスクと情報を使用して、JDBC 接続プールを管理します。
指定した JDBC 接続プール名で新しい JDBC 接続プールを登録するには、リモートモードで create-jdbc-connection-pool サブコマンドを使用します。。JDBC 接続プールまたはコネクタ接続プールは、認証を使用して作成できます。asadmin ユーティリティーでユーザー、パスワード、またはその他の接続情報を指定するサブコマンドオプションを使用するか、XML 記述子ファイルで接続情報を指定します。
各データベースには接続プールが 1 つ必要です。アプリケーションによっては、複数の接続プールが必要な場合もあります。接続プールを構築するときに、JDBC ドライバとデータベースベンダーに固有のデータが必要となります。次に示す固有データの例の一部は、「JDBC ドライバに固有の構成」にも示してあります。
データベースベンダー名
javax.sql.DataSource (ローカルトランザクションのみ) や javax.sql.XADataSource (グローバルトランザクション) などのリソースタイプ
データソースクラス名
データベース名 (URL)、ユーザー名、およびパスワードなどの必要なプロパティー
JDBC 接続プールの作成は動的なイベントであり、サーバーの再起動は必要ありません。ただし、パラメータの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。
接続プールを作成する前に、データベースとデータベースに関連する JDBC ドライバをインストールして統合しておく必要があります。手順については、「データベースの設定」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jdbc-connection-pool(1) サブコマンドを使用して、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 接続プールをすべて表示するには、リモートモードで list-jdbc-connection-pools サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jdbc-connection-pools(1) サブコマンドを使用して、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-connection-pool サブコマンドを使用します。たとえば、あとで配備する予定のアプリケーション用に新しい JDBC 接続プールを作成した場合、そのアプリケーションを配備する前に、このコマンドを使用して JDBC プールをテストすることができます。ping を実行すると、プールがまだ作成されていない場合は作成を強制されます。
接続プールと通信する前に、認証を使用して接続プールを作成し、サーバーまたはデータベースを実行しておく必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
ping-connection-pool(1) サブコマンドを使用して、接続プールに ping を実行します。
この例では、DerbyPool 接続プールが使用可能かどうかを確認します。
asadmin> ping-connection-pool DerbyPool Command ping-connection-pool executed successfully |
コマンド行に asadmin help ping-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
指定した接続プールで確立されたすべての接続を再初期化するには、リモートモードで flush-connection-pool を使用します。JDBC 接続プールまたはコネクタ接続プールは、初期状態にリセットされます。既存の動作中の接続はすべて破棄され、これらの接続に関連付けられているトランザクションは失われます。続いてプールの初期接続が再作成され、プールは通常プールサイズに復元されます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
flush-connection-pool(1) サブコマンドを使用して、接続プールをリセットします。
この例では、__TimerPool という名前の JDBC 接続プールを通常プールサイズにリセットします。
asadmin> flush-connection-pool __TimerPool Command flush-connection-pool executed successfully. |
コマンド行に asadmin help flush-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
get および set サブコマンドを使用して、JDBC 接続プールのプロパティーの値を表示および変更します。
list-jdbc-connection-pools(1) サブコマンドを使用して、JDBC 接続プールを一覧表示します。
get サブコマンドを使用して、JDBC 接続プールの属性を表示します。
次に例を示します。
asadmin get resources.jdbc-connection-pool.DerbyPool.property |
set サブコマンドを使用して、JDBC 接続プールの属性を設定します。
次に例を示します。
asadmin set resources.jdbc-connection-pool.DerbyPool.steady-pool-size=9 |
(省略可能) 必要な場合は、サーバーを再起動します。
一部のパラメータはサーバーの再起動を必要とします。「サーバーの再起動が必要な構成の変更」を参照してください。
既存の JDBC 接続プールを削除するには、リモートモードで delete-jdbc-connection-pool サブコマンドを使用します。JDBC 接続プールの削除は動的なイベントであり、サーバーの再起動は必要ありません。
JDBC 接続プールを削除する前に、リソースのすべての関連付けを削除する必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jdbc-connection-pools(1) サブコマンドを使用して、JDBC 接続プールを一覧表示します。
必要に応じて、JDBC 接続プールを削除することをユーザーに通知します。
delete-jdbc-connection-pool(1) サブコマンドを使用して、接続プールを削除します。
この例では、DerbyPool という名前の JDBC 接続プールを削除します。
asadmin> delete-jdbc-connection-pool jdbc/DerbyPool Command delete-jdbc-connection-pool executed successfully. |
コマンド行に asadmin help delete-jdbc-connection-pool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
「JDBC リソース」はデータソースとも呼ばれ、アプリケーションがデータベースに接続する手段を提供します。一般的には、ドメインに配備されたアプリケーションがアクセスするデータベースごとに 1 つの JDBC リソースを作成します。1 つのデータベースに複数の JDBC リソースを指定することもできます。
JDBC リソースは、リソースを関連付ける接続プールを指定することで作成されます。一意の Java Naming and Directory Interface (JNDI) 名を使用して、リソースを識別します。たとえば、給与データベースのリソースには、java:comp/env/jdbc/payrolldb のような JNDI 名を付けることができます。
次のタスクと情報を使用して、JDBC リソースを管理します。
JDBC リソースを作成するには、リモートモードで create-jdbc-resource サブコマンドを使用します。JDBC リソースの作成は動的なイベントであり、サーバーの再起動は必要ありません。
すべての JNDI 名は java:comp/env サブコンテキストにあるので、管理コンソール で JDBC リソ スの JNDI を指定するときは、jdbc/name の形式だけを使用します。たとえば、先に述べた給与データベースは、jdbc/payrolldb のように指定できます。
JDBC リソースを作成する前に、JDBC 接続プールを作成する必要があります。手順については、「JDBC 接続プールを作成する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jdbc-resource(1) サブコマンドを使用して、JDBC リソースを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
必要に応じて、新しいリソースを作成したことをユーザーに通知します。
この例では、DerbyPool という名前の JDBC リソースを作成します。
asadmin> create-jdbc-resource --connectionpoolid DerbyPool jdbc/DerbyPool Command create-jdbc-resource executed successfully. |
コマンド行に asadmin help create-jdbc-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の JDBC リソースを一覧表示するには、リモートモードで list-jdbc-resources サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jdbc-resources(1) サブコマンドを使用して、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
set サブコマンドを使用して、JDBC リソースを有効または無効にできます。JDBC リソースはドット表記名で識別されます。
list-jdbc-resources(1) サブコマンドを使用して、JDBC リソースを一覧表示します。
set(1) サブコマンドを使用して、指定した JDBC リソースの値を変更します。
次に例を示します。
この例では、res1 の enabled の設定を false に変更します。
asadmin>set resources.jdbc-resource.res1.enabled=false |
既存の JDBC リソースを削除するには、リモートモードで delete-jdbc-resource サブコマンドを使用します。JDBC リソースの削除は動的なイベントであり、サーバーの再起動は必要ありません。
JDBC リソースを削除する前に、削除するリソースのすべての関連付けを削除する必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jdbc-resources(1) サブコマンドを使用して、JDBC リソースを一覧表示します。
必要に応じて、JDBC リソースを削除することをユーザーに通知します。
delete-jdbc-resource(1) サブコマンドを使用して、JDBC リソースを削除します。
この例では、DerbyPool という名前の JDBC リソースを削除します。
asadmin> delete-jdbc-resource jdbc/DerbyPool Command delete-jdbc-resource executed successfully. |
コマンド行に asadmin help delete-jdbc-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
接続プールとリソースを設定したあと、次のいずれかの方法で JDBC ドライバを統合します。
共通のクラスローダーがドライバにアクセスできるようにして、ドメインを再起動します。
ドライバの JAR および ZIP ファイルを、domain-dir/lib ディレクトリまたは glassfish_home/lib にコピーするか、ドライバのクラスファイルを domain-dir/lib/ext ディレクトリにコピーします。ドライバの JAR ファイルの完全修飾パス名が認識されます。
Enterprise Server は、対応する JDBC ドライバを使用して、すべてのデータベース管理システムに接続できるように設計されています。
次の JDBC ドライバとデータベースの組み合わせはテスト済みで、コンテナ管理による持続性がサポートされています。
サポートされている JDBC ドライバの最新のリストについては、『Sun GlassFish Enterprise Server v3 リリースノート』を参照してください。
このドライバの JAR ファイルは smdb2.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: DB2
「データソースクラス名」: com.sun.sql.jdbcx.db2.DB2DataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
databaseName – 必要に応じて設定します。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
このドライバの JAR ファイルは smoracle.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: Oracle
「データソースクラス名」: com.sun.sql.jdbcx.oracle.OracleDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
このドライバの JAR ファイルは smsqlserver.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: Microsoft SQL Server
「データソースクラス名」: com.sun.sql.jdbcx.sqlserver.SQLServerDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
selectMethod – cursor に設定します。
Sun MySQL ドライバは、MySQL Enterprise のみで動作します。このドライバの JAR ファイルは smmysql.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: SQL Server
「データソースクラス名」: com.sun.sql.jdbcx.mysql.MySQLDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
selectMethod – cursor に設定します。
このドライバの JAR ファイルは smsybase.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: Sybase
「データソースクラス名」: com.sun.sql.jdbcx.sybase.SybaseDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
databaseName – 必要に応じて設定します。これは任意指定です。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
この 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 ドライバの 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 が認証を使用するように設定されている場合にのみ必要です。
MySQLTM ドライバの 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 ドライバの JAR ファイルは postgresql-8.4-701.jdbc4.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: PostgreSQL Server
「データソースクラス名」:
* org.postgresql.ds.PGSimpleDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
databaseName – 必要に応じて設定します。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
次の JDBC ドライバも Enterprise Server で使用できますが、これらのドライバは完全にはテストされていません。Sun では、これらのドライバの製品サポートは提供していませんが、Enterprise Server &; での使用についての限定サポートを提供しています。
Oracle データベースユーザーが capture-schema コマンドを実行するには、そのユーザーがスキーマの所有者でないかぎり、ANALYZE ANY TABLE 特権が必要です。この特権は、データベース管理者がユーザーに付与します。capture-schema の詳細は、『Sun GlassFish Enterprise Server v3 Reference Manual 』を参照してください。
次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: Informix
「データソースクラス名」: 次のいずれかを指定します。
com.informix.jdbcx.IfxDataSource com.informix.jdbcx.IfxXADataSource
「プロパティー」:
serverName – Informix データベースサーバー名を指定します。
portNumber – データベースサーバーのポート番号を指定します。
databaseName – 必要に応じて設定します。これは任意指定です。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
IfxIFXHost – データベースサーバーのホスト名または IP アドレスを指定します。
この 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 ドライバの JAR ファイルは Merlia.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: Microsoft SQL Server
「データソースクラス名」: com.inet.tds.TdsDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
この Inet Sybase ドライバの JAR ファイルは Sybelux.jar です。次のように接続プールを設定します。
「名前」: あとで JDBC リソースを設定するときに、この名前を使用します。
「リソースタイプ」: 適切な値を指定します。
「データベースベンダー」: Sybase
「データソースクラス名」: com.inet.syb.SybDataSource
「プロパティー」:
serverName – データベースサーバーのホスト名または IP アドレスを指定します。
portNumber – データベースサーバーのポート番号を指定します。
databaseName – 必要に応じて設定します。完全な URL ではなく、データベース名のみを指定してください。
user – 必要に応じて設定します。
password – 必要に応じて設定します。
この 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 ドライバの 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 に設定する必要があります。
この 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 つの接続プールを作成することもできます。
この章では、Sun GlassFishTM Enterprise Server v3 環境で、asadmin コマンド行ユーティリティーを使用し、エンタープライズ情報システム (EIS) のデータとの接続を管理する方法について説明します。
Web Profile をインストールした場合は、発信機能だけを使用するコネクタモジュールと、着信機能を伴わない作業管理がサポートされます。その他のコネクタ機能は、Full Platform Profile でのみサポートされます。
ここでは、以下のトピックに関して説明します。
本章で説明するタスクを管理コンソールから実行する手順については、管理コンソールのオンラインヘルプを参照してください。
データベース接続については、第 14 章データベース接続の管理 を参照してください。
エンタープライズ情報システム (EIS) は、組織のデータを保持する任意のシステムです。メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションがこれに使用できます。アプリケーションとモジュールが EIS ソフトウェアにアクセスするには、接続リソースが使用されます。
EIS 接続の主な要素は、次のとおりです。
「コネクタモジュール」。コネクタモジュールは、アプリケーションと EIS ソフトウェアとの対話を可能にする Java EE コンポーネントで、リソースアダプタとも呼ばれます。コネクタモジュールは、Enterprise Server が JavaTM 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 に接続されると次のことが行われます。
JNDI API を介して呼び出しを行うことにより、アプリケーションは EIS に関連したコネクタリソース (データソース) を取得します。
コネクタリソースの JNDI 名を基に、ネーミングおよびディレクトリサービスがリソースを検索します。EIS リソースはそれぞれコネクタ接続プールを指定します。
コネクタリソースを経由して、アプリケーションは EIS 接続を取得します。
Enterprise Server は EIS リソースに対応した接続プールから物理接続を取得します。プールは、EIS 名、ユーザー名、パスワードなどの接続属性を定義します。
EIS 接続が確立されると、アプリケーションは EIS のデータの読み込み、変更、および追加を行うことができます。
アプリケーションは JMS API を呼び出すことにより、EIS 情報にアクセスします。
EIS へのアクセスが完了すると、アプリケーションは接続を終了して、接続を接続プールに返します。
コネクタモジュールを配備すると、これにコネクタ接続プールを作成できるようになります。
ここでは、以下のトピックに関して説明します。
配備したコネクタモジュールにコネクタ接続プールを作成するには、リモートモードで create-connector-connection-pool サブコマンドを使用します。コネクタ接続プールを構築する際に、その EIS に固有の所定データを入力するよう求められます。必須の --connectiondefintion オプションの値が、EIS 情報となります。
複数のコネクタリソースで 1 つの接続プールを指定できます。
コネクタ接続プールの作成は動的イベントで、サーバーの再起動は求められません。ただし、パラメータの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。
コネクタ接続プールを作成する前に、コネクタをインストールしておいてください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-connector-connection-pool(1) サブコマンドを使用して、コネクタ接続プールを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
(省略可能) 接続プールが使用可能であることを確認するには、ping-connection-pool サブコマンドを使用します。
手順については、「接続プールと通信する (ping を実行する)」を参照してください。
この例では、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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-connection-pools(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。
この例では、既存のコネクタ接続プールを一覧表示します。
asadmin> list-connector-connection-pools jms/qConnPool Command list-connector-connection-pools executed successfully |
コマンド行に asadmin help list-connector-connection-pools と 入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
リモートモードで接続プールにこれらのタスクを実行するには、ping-connection-pool または flush-connection-pool サブコマンドを使用します。手順については、「接続プールと通信する (ping を実行する)」または「接続プールをリセット (フラッシュ) する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
flush-connection-pool(1) サブコマンド、または ping-connection-pool(1) サブコマンドを使用して、コネクタ接続プールに接続、またはコネクタ接続プールをリセットします。
コネクタ接続プールのプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。
list-connector-connection-pools(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。
get(1) サブコマンドを使用して、コネクタ接続プールのプロパティーを表示します。
次に例を示します。
asadmin> get domain.resources.connector-connection-pool.conectionpoolname.* |
set(1) サブコマンドを使用して、コネクタ接続プールのプロパティーを設定します。
次に例を示します。
asadmin> set domain.resources.connector-connection-pool .conectionpoolname.validate-atmost-once-period-in-seconds=3 |
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
コネクタ接続プールを削除するには、リモートモードで delete-connector-connection-pool サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-connection-pools(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。
必要な場合は、コネクタ接続プールが削除されることをユーザーに通知してください。
delete-connector-connection-pool(1) サブコマンドを使用して、コネクタ接続プールを削除します。
この例では、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 サブコマンドを使用します。
コネクタリソースの作成は動的イベントで、サーバーの再起動は求められません。ただし、パラメータの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。
コネクタリソースを作成する前に、まずコネクタ接続プールを作成しておく必要があります。手順については、「コネクタ接続プールを作成する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-connector-resource(1) サブコマンドを使用して、コネクタリソースを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
この例では、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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-resources(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。
この例では、既存のコネクタリソースを一覧表示します。
asadmin> list-connector-resources jms/qConnFactory Command list-connector-resources executed successfully |
コマンド行に asadmin help list-connector-resources と 入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
コネクタリソースのプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。
list-connector-resources(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。
get(1) サブコマンドを使用して、コネクタリソースのプロパティーを表示します。
次に例を示します。
asadmin> get domain.resources.connector-resource.jms/qConnFactory |
set(1) サブコマンドを使用して、コネクタリソースのプロパティーを設定します。
次に例を示します。
asadmin> set domain.resources.connector-resource.jms/qConnFactory.enabled=true |
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
JNDI 名を指定してコネクタリソースを削除するには、リモートモードで delete-connector-resource サブコマンドを使用します。
リソースを削除する前に、そのリソースに関連付けられているものをすべて削除しておく必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-resources(1) サブコマンドを使用して、コネクタ接続プールを一覧表示します。
必要な場合は、コネクタリソースが削除されることをユーザーに通知してください。
delete-connector-resource(1) サブコマンドを使用して、コネクタリソースを削除します。
この例では、jms/qConnFactory コネクタリソースを削除します。
asadmin> delete-connector-resource jms/qConnFactory Command delete-connector-resources executed successfully |
コマンド行に asadmin help delete-connector-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
ここでは、以下のトピックに関して説明します。
リソースアダプタ (コネクタモジュール) の構成情報を作成するには、リモートモードで create-resource-adapter-config サブコマンドを使用します。配備するときに構成情報を使用できるように、このサブコマンドを実行してからリソースアダプタを配備することができます。このリソースアダプタ構成は、リソースアダプタを配備したあとでも作成できます。この場合、リソースアダプタは新しい構成で再起動されます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-resource-adapter-config(1) サブコマンドで、構成情報を作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
この例では、リソースアダプタ 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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-resource-adapter-configs(1) サブコマンドで、リソースアダプタの設定を一覧表示します。
この例では、リソースアダプタ構成を一覧表示します。
asadmin> list-resource-adapter-configs ra1 ra2 Command list-resource-adapter-configs executed successfully |
コマンド行に asadmin help list-resource-adapter-configs と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
リソースアダプタ構成のプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。
list-resource-adapter-configs(1) サブコマンドで、リソースアダプタの構成を一覧表示します。
get(1) サブコマンドを使用して、コネクタリソースのプロパティーを表示します。
次に例を示します。
asadmin> get domain.resources.resource-adapter-config.ra1.* |
set(1) サブコマンドを使用して、コネクタリソースのプロパティーを設定します。
次に例を示します。
asadmin> set domain.resources.resource-adapter-config.ra1.raSpecificProperty=value |
指定したリソースアダプタ (コネクタモジュール) のドメイン構成ファイル (domain.xml) に含まれている構成情報を削除するには、リモートモードで delete-resource-adapter-config サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-resource-adapter-configs(1) サブコマンドで、リソースアダプタの構成を一覧表示します。
delete-resource-adapter-config(1) サブコマンドで、リソースアダプタの構成を削除します。
この例では、リソースアダプタ 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 主体に割り当てることもできます。
このサブコマンドを正常に実行するためには、最初にコネクタ接続プールを作成しておく必要があります。手順については、「コネクタ接続プールを作成する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-connector-security-map(1) サブコマンドで、コネクタセキュリティーマップを作成します。
このサブコマンドのオプションについては、このマニュアルページに記載されています。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
この例では、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 サブコマンドを使用します。コネクタ接続プールにコネクタセキュリティーマップの簡易リストを取得することも、マップの主体を表示するような総合リストを取得することもできます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-connection-pools(1) サブコマンドを使用して、既存のコネクタ接続プールを一覧表示します。
list-connector-security-maps(1) サブコマンドで、指定のコネクタ接続プールのセキュリティーマップを一覧表示します。
この例では、connector-Pool1 に関連付けられているコネクタセキュリティーマップを一覧表示します。
asadmin> list-connector-security-maps connector-Pool1 securityMap1 Command list-connector-security-maps executed successfully. |
この例では、securityMap1 に関連付けられている主体を一覧表示します。
asadmin> list-connector-security-maps --securitymap securityMap1 connector-Pool1 principal1 principal1 Command list-connector-security-maps executed successfully. |
この例では、connector-Pool1 に関連付けられているコネクタセキュリティーマップを一覧表示します。
asadmin> list-connector-security-maps --verbose connector-Pool1 securityMap1 principal1 principal1 Command list-connector-security-maps executed successfully. |
指定したコネクタ接続プールにセキュリティーマップを作成または変更するには、リモートモードで update-connector-security-map サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-security-maps(1) サブコマンドを使用して、既存のコネクタセキュリティーマップを一覧表示します。
update-connector-security-map(1) サブコマンドで、指定のコネクタ接続プールのセキュリティーマップを変更します。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
この例では、securityMap1 に主体を追加します。
asadmin> update-connector-security-map --poolname connector-pool1 --addprincipals principal1, principal2 securityMap1 Command update-connector-security-map executed successfully. |
指定したコネクタ接続プールにセキュリティーマップを削除するには、リモートモードで delete-connector-security-map サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-connection-pools(1) サブコマンドを使用して、既存のコネクタ接続プールを一覧表示します。
delete-connector-security-map(1) サブコマンドで、指定のコネクタ接続プールのセキュリティーマップを削除します。
このサブコマンドのオプションについては、このマニュアルページに記載されています。
この例では、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 つ以上の作業セキュリティーマップをコネクタモジュールに関連付けることができます。
コネクタセキュリティーマップの構成では、ワイルドカード文字としてアスタリスク (*) を使用し、すべてのユーザーまたはすべてのユーザーグループを示すことができます。
コネクタリソースを作成する前に、まずコネクタ作業セキュリティーマップを作成しておく必要があります。手順については、「コネクタ接続プールを作成する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-connector-work-security-map(1) サブコマンドで、コネクタ作業セキュリティーマップを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
次の例は、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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-work-security-maps(1) サブコマンドで、コネクタ作業セキュリティーマップを一覧表示します。
この例では、一般的な作業セキュリティーマップを一覧表示します。
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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-work-security-maps(1) サブコマンドで、コネクタ作業セキュリティーマップを一覧表示します。
必要な場合は、コネクタ作業セキュリティーマップが変更されることをユーザーに通知してください。
update-connector-work-security-map(1) サブコマンドで、コネクタ作業セキュリティーマップを更新します。
この例では、作業セキュリティーマップから主体を削除します。
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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-connector-work-security-maps(1) サブコマンドで、コネクタ作業セキュリティーマップを一覧表示します。
delete-connector-work-security-map(1) サブコマンドで、コネクタ作業セキュリティーマップを削除します。
この例では、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) を実行する前に、リソースアダプタを配備しておいてください。
create-admin-object(1) サブコマンドで、管理対象オブジェクトを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
この例では、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 サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-admin-objects(1) サブコマンドで、管理対象オブジェクトを一覧表示します。
この例では、既存の管理対象オブジェクトを一覧表示します。
asadmin> list-admin-objects jms/samplequeue Command list-admin-objects executed successfully |
コマンド行に asadmin help list-admin-object と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
管理対象オブジェクトのプロパティー値を表示および変更するには、 get および set サブコマンドを使用します。
list-admin-objects(1) サブコマンドで、管理対象オブジェクトを一覧表示します。
get(1) サブコマンドを使用して、管理対象オブジェクトのプロパティーを表示します。
次に例を示します。
asadmin> get domain.resources.admin-object-resource.jms/samplequeue.* |
set(1) サブコマンドを使用して、管理対象オブジェクトのプロパティーを設定します。
次に例を示します。
asadmin> set domain.resources.admin-object-resource.jms/samplequeue.enabled=false |
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
管理対象オブジェクトを削除するには、delete-admin-object サブコマンドを使用します。
list-admin-objects(1) サブコマンドで、管理対象オブジェクトを一覧表示します。
必要な場合は、管理対象オブジェクトが削除されることをユーザーに通知してください。
delete-admin-object(1) サブコマンドで、管理対象オブジェクトを削除します。
この例では、JNDI 名 jms/samplequeue が付いた管理対象オブジェクトを削除します。
asadmin> delete-admin-object jms/samplequeue Command delete-admin-object executed successfully |
コマンド行に asadmin help delete-admin-object と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server v3 の環境でインターネット接続のタスクを実行する手順について説明します。
ここでは、次のテーマを取り上げます。
本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。
HTTP サービスは、Web アプリケーションを配備する機能と、配備した Web アプリケーションをインターネットクライアントからアクセス可能にする機能を提供します。HTTP サービスは、リスナーと仮想サーバーという 2 種類の関連オブジェクトにより提供されます。
ここでは、次のテーマを取り上げます。
「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 が含まれる場合)。
デフォルトでは、Enterprise Server の起動時に次の HTTP リスナーが自動的に開始されます。
server の名前を持つ仮想サーバーに関連付けられた HTTP リスナー
リスナー http-listener-1 では、セキュリティーが有効になっていません。
リスナー http-listener-2 では、セキュリティーが有効になっています。
仮想サーバー __asadmin に関連付けられた HTTP リスナー admin-listener。このリスナーでは、セキュリティーが有効になっていません。
次の表に、ポートを使用するリスナーについて、Enterprise Server のデフォルトポートを示します。
表 16–1 リスナーのデフォルトポート
リスナー |
デフォルトポート |
説明 |
---|---|---|
管理サーバー |
4848 |
ドメイン管理サーバーには、管理コンソール と asadmin ユーティリティーを使ってアクセスします。管理コンソール には、ブラウザの URL にポート番号を指定します。リモートから asadmin サブコマンドを実行する場合は、オプション --port を使用してポート番号を指定します。 |
HTTP |
8080 |
Web サーバーはポート上で HTTP 要求を待機します。配備した Web アプリケーションとサービスにアクセスするために、クライアントはこのポートに接続します。 |
HTTPS |
8181 |
セキュリティー保護された通信用に設定された Web アプリケーションは、個別のポートで待機します。 |
ここでは、次のテーマを取り上げます。
リスナーのオプションをすべて指定してインターネット接続を作成するには、この手順でサブコマンドを使用します。ネットワークリスナーは、バックグラウンドで作成されます。このプロセスの簡略バージョンについては、「HTTP ネットワークリスナーを作成する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-protocol(1) サブコマンドにオプション --securityenabled を指定して、HTTP または HTTPS プロトコルを作成します。
組み込みの http-listener-1 HTTP プロトコルまたは http-listener-2 HTTPS プロトコルを使用する場合は、この手順を省略します。
create-http(1) サブコマンドを使用して、HTTP 構成を作成します。
組み込みプロトコルを使用する場合は、この手順を省略します。
create-transport(1) サブコマンドを使用して、トランスポートを作成します。
組み込みの tcp トランスポートを使用する場合は、この手順を省略します。
(省略可能) create-threadpool(1) サブコマンドを使用して、スレッドプールを作成します。
スレッドプールを使用しない場合、または組み込みの http-thread-pool スレッドプールを使用する場合は、この手順を省略します。
スレッドプールの詳細については、第 5 章スレッドプールの管理を参照してください。
create-network-listener(1) サブコマンドを使用して、HTTP リスナーを作成します。
プロトコルとトランスポートを指定します。スレッドプールは省略可能です。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
コマンド行に asadmin help create-http-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
各 HTTP リスナーは HTTP プロトコルを持ち、この HTTP プロトコルは create-protocol サブコマンドを使用するか、「HTTP ネットワークリスナーを作成する」の手順に従った場合に適用される組み込みプロトコルを使用して作成されます。
ここでは、次のテーマを取り上げます。
プロトコルを作成するには、リモートモードで create-protocol サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-protocol(1) を使用して、プロトコルを作成します。
サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。
この例は、セキュリティーを有効にして、プロトコル http-1 を作成します。
asadmin> create-protocol --securityenabled=true http-1 Command create-protocol executed successfully. |
コマンド行に asadmin help create-protocol と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の HTTP プロトコルを一覧表示するには、リモートモードで list-protocols サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-protocols(1) サブコマンドを使用して、既存のプロトコルを一覧表示します。
この例は、既存のプロトコルを一覧表示します。
asadmin> list-protocols admin-listener http-1 http-listener-1 http-listener-2 Command list-protocols executed successfully. |
コマンド行に asadmin help list-protocols と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
プロトコルを削除するには、リモートモードで delete-protocol サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
delete-protocol(1) サブコマンドを使用して、プロトコルを削除します。
この例は、プロトコル http-1 を削除します。
asadmin> delete-protocol http-1 Command delete-protocol executed successfully. |
コマンド行に asadmin help delete-protocol と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
各 HTTP リスナーは HTTP 構成を持ち、この HTTP 構成は、create-http サブコマンドを使用するか、「HTTP ネットワークリスナーを作成する」の手順に従う場合に適用される組み込み構成を使用して作成されます。
ここでは、次のテーマを取り上げます。
プロトコルの HTTP パラメータセットを作成するには、リモートモードで create-http サブコマンドを使用します。このパラメータセットは、ネットワークリスナーを 1 つ以上構成します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-http(1) サブコマンドを使用して、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 のパラメータセットを削除するには、リモートモードで delete-http サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
delete-http(1) サブコマンドを使用して、プロトコルから HTTP のパラメータを削除します。
この例は、http-1 というプロトコルから HTTP のパラメータセットを削除します。
asadmin> delete-http http-1 Command delete-http executed successfully. |
コマンド行に asadmin help delete-http と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
各 HTTP リスナーは HTTP トランスポートを持ち、この HTTP トランスポートは、create-transport サブコマンドを使用するか、「HTTP ネットワークリスナーを作成する」の手順に従う場合に適用される組み込みトランスポートを使用して作成されます。
ここでは、次のテーマを取り上げます。
ネットワークリスナーのトランスポートを作成するには、リモートモードで create-transport サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-transport(1) サブコマンドを使用して、トランスポートを作成します。
サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。
この例は、アクセプタスレッド数としてデフォルト以外の値を使用する、http1-trans というトランスポートを作成します。
asadmin> create-transport --acceptorthreads 100 http1-trans Command create-transport executed successfully. |
コマンド行に asadmin help create-transport と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の HTTP トランスポートを一覧表示するには、リモートモードで list-transports サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-transports(1) サブコマンドを使用して、既存のトランスポートを一覧表示します。
この例は、既存のトランスポートを一覧表示します。
asadmin> list-transports http1-trans tcp Command list-transports executed successfully. |
コマンド行に asadmin help list-transports と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
トランスポートを削除するには、リモートモードで delete-transport サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
delete-transport(1) サブコマンドを使用して、トランスポートを削除します。
この例は、http1-trans というトランスポートを削除します。
asadmin> delete-transport http1-trans Command delete-transport executed successfully. |
コマンド行に asadmin help delete-transport と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
ここでは、次のテーマを取り上げます。
リスナーを作成するには、リモートモードで create-http-listener サブコマンドまたは create-network-listener サブコマンドを使用します。これらのサブコマンドは後方互換性を提供し、さらに HTTP プロトコルを使用するネットワークリスナーを作成するためのショートカットも提供します。ネットワークリスナー、関連プロトコル、トランスポート、および HTTP 構成がバックグラウンドで作成されます。このメソッドは便利なショートカットですが、一部のオプションのみにアクセスできます。リスナーのオプションをすべて指定する場合は、「インターネット接続を作成する」の手順に従ってください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-network-listener(1) サブコマンドまたは create-http-listener(1) サブコマンドを使用して、HTTP ネットワークリスナーを作成します。
必要な場合は、サーバーを再起動します。
admin-listener という名前の特別な 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. |
この例は、実行時に有効にならない 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 リスナーを一覧表示するには、リモートモードで list-http-listeners サブコマンドまたは list-network-listeners サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-http-listeners(1) サブコマンドまたは list-network-listeners(1) サブコマンドを使用して、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
list-http-listeners(1) サブコマンドまたは list-network-listeners(1) サブコマンドを使用して、HTTP リスナーを一覧表示します。
set(1) サブコマンドを使用して、指定リスナーの値を変更します。
リスナーは、そのドット表記名で指定します。
この例は、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 リスナーを削除するには、リモートモードで delete-http-listener サブコマンドまたは delete-network-listener サブコマンドを使用します。これにより、リスナーの通信のセキュリティーが無効になります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-http-listeners(1) サブコマンドを使用して、HTTP リスナーを一覧表示します。
delete-http-listener(1) サブコマンドまたは delete-network-listener(1) サブコマンドを使用して、HTTP リスナーを削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、sampleListener という HTTP リスナーを削除します。
asadmin> delete-http-listener sampleListener Command delete-http-listener executed successfully. |
コマンド行に asadmin help delete-http-listener または asadmin help delete-network-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
指定リスナー内に SSL 要素を作成して構成するには、create-ssl サブコマンドを使用します。これにより、リスナーの通信のセキュリティーが有効になります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-ssl(1) サブコマンドを使用して、HTTP リスナーを構成します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
指定リスナーの SSL 要素を削除するには、リモートモードで delete-ssl サブコマンドを使用します。これにより、リスナーの通信のセキュリティーが無効になります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
delete-ssl(1) サブコマンドを使用して、HTTP リスナーから SSL を削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、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 サービスコンポーネントを開きます。
HTTP サービスコンポーネントの下にある HTTP リスナーコンポーネントを開きます。
HTTP リスナーを選択するか、新規に作成します。
「デフォルト仮想サーバー」ドロップダウンリストから選択します。
詳細については、「デフォルトの 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」を参照してください。
ここでは、次のテーマを取り上げます。
デフォルトでは、Enterprise Server の起動時に次の仮想サーバーが自動的に開始されます。
server: ユーザー定義のすべての Web モジュールをホスティングする仮想サーバー。
本稼動環境以外での Web サービスの開発、テスト、配備で必要となる仮想サーバーは、通常、server だけです。
__asadmin: すべての管理関連 Web モジュール (具体的には &AdminCon ole;) をホスティングする仮想サーバー。このサーバーの使用は制限されています。つまり、この仮想サーバーに Web モジュールを配備することはできません。
ただし本稼動環境では、同一物理サーバー上でユーザーと顧客のそれぞれが専用の Web サーバーを持つように見せる機能をホスティングするため、通常は追加の仮想サーバーも使用されます。
名前付きの仮想サーバーを作成するには、リモートモードで create-virtual-server サブコマンドを使用します。
仮想サーバーは、既存の HTTP リスナーを指定する必要があります。仮想サーバーは、すでに別の仮想サーバーが使用している HTTP リスナーを指定できないので、仮想サーバーを新規作成する前に、HTTP リスナーを 1 つ以上作成します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-virtual-server(1) サブコマンドを使用して、仮想サーバーを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、 localhost に sampleServer という仮想サーバーを作成します。
asadmin> create-virtual-server sampleServer Command create-virtual-server executed successfully. |
コマンド行に asadmin help create-virutal-server と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の仮想サーバーを一覧表示するには、リモートモードで list-virtual-servers サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-virtual-servers(1) サブコマンドを使用して、仮想サーバーを一覧表示します。
この例は、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
list-virtual-servers(1) サブコマンドを使用して、仮想サーバーを一覧表示します。
set(1) サブコマンドを使用して、指定した仮想サーバーの値を変更します。
仮想サーバーは、ドット表記名で指定します。
既存の仮想サーバーを削除するには、リモートモードで delete-virtual-server サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-virtual-servers(1) サブコマンドを使用して、仮想サーバーを一覧表示します。
必要に応じて、仮想サーバーが削除されることをユーザーに通知します。
delete-virtual-server(1) サブコマンドを使用して、仮想サーバーを削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、localhost から sampleServer という仮想サーバーを削除します。
asadmin> delete-virtual-server sampleServer Command delete-virtual-server executed successfully. |
コマンド行に asadmin help delete-virutal-server と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
デフォルト Web モジュールは、デフォルト仮想サーバーや個々の新しい仮想サーバーに割り当てることができます。仮想サーバーのデフォルト Web モジュールにアクセスするには、ブラウザで仮想サーバーの URL をポイントします。ただし、コンテキストルートは指定しないでください。次に例を示します。
http://myvserver:3184/
デフォルト Web モジュールが割り当てられていない仮想サーバーは、ドキュメントルート (通常は domain-dir /docroot) から HTML または JavaServer PagesTM ( JSPTM) のコンテンツを提供します。この HTML または JSP のコンテンツにアクセスするには、ブラウザで仮想サーバーの URL をポイントします。コンテキストルートは指定せず、ターゲットのファイルを指定します。
次に例を示します。
http://myvserver:3184/hellothere.jsp
配備済みのアプリケーションや Web モジュールに仮想サーバーを割り当てることができます。
アプリケーションやモジュールは、すでに配備済みである必要があります。詳細については、『Sun GlassFish Enterprise Server v3 Application Deployment Guide』を参照してください。
管理コンソール で、関連する構成の下にある HTTP サービスコンポーネントを開きます。
HTTP サービスコンポーネントの下にある仮想サーバーコンポーネントを開きます。
デフォルト Web モジュールを割り当てる仮想サーバーを選択します。
「デフォルト Web モジュール」ドロップダウンリストから、アプリケーションまたは Web モジュールを選択します。
詳細については、「デフォルトの Web モジュールを仮想サーバーに割り当てる」を参照してください。
Sun GlassFishTM Enterprise Server は、相互運用性を保証する一連の標準的なプロトコルと形式をサポートします。これらのプロトコルの中には、CORBA で定義されているものがあります。ORB (Object Request Broker) は、CORBA の中枢となるコンポーネントです。ORB は、オブジェクトの特定と検索、接続管理、およびデータと要求の配信に必要なインフラストラクチャーを提供します。この章では、ORB と IIOP リスナーの設定方法について説明します。
ここでは、次のテーマを取り上げます。
本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。
CORBA (Common Object Request Broker Architecture) モデルのベースになっているのは、明確に定義されたインタフェースを介して分散型のオブジェクトやサーバーにサービスを要求するクライアントです。こうしたクライアントは、リモートメソッド要求の形式でオブジェクトに対して要求を発行します。「リモートメソッド要求」では、実行する必要のある操作に関する情報が伝送されます。この情報には、サービスプロバイダのオブジェクト名 (オブジェクト参照) と、存在する場合は、起動メソッドのパラメータが含まれます。CORBA は、オブジェクトの登録、オブジェクトの配置、オブジェクトのアクティブ化、要求の多重分離、エラー処理、整列化、操作のディスパッチをはじめとするネットワークプログラミングのタスクを自動的に処理します。
個々の CORBA オブジェクトが相互に対話することはありません。代わりに、オブジェクトはリモートスタブを通して、ローカルホストで動作している IIOP (Internet Inter-Orb Protocol) に要求を行います。続いて、ローカルの ORB が IIOP を使用して、ほかのホスト上の ORB に要求を渡します。リモート ORB は、適切なオブジェクトを検出し、要求を処理して、結果を返します。
アプリケーションやオブジェクトでは、RMI-IIOP により、IIOP を RMI (Remote Method Invocation) として使用することが可能になっています。エンタープライズ Bean (EJB モジュール) のリモートクライアントは、RMI-IIOP を使用して Enterprise Server と通信します。
「IIOP リスナー」は、Enterprise JavaBeans のリモートクライアントおよびほかの CORBA ベースのクライアントから受信する接続を受け付ける待機ソケットです。Enterprise Server では、複数の IIOP リスナーを設定できます。各リスナーに対して、ポート番号 (オプション、デフォルトは 1072)、ネットワークアドレス、およびセキュリティー属性 (オプション) を指定してください。複数のリスナーを作成する場合は、リスナーごとに異なるポート番号を割り当てる必要があります。
ここでは、次のテーマを取り上げます。
IIOP リスナーを作成するには、リモートモードで create-iiop-listener サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-iiop-listener(1) サブコマンドを使用して、IIOP リスナーを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例では、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 リスナーを一覧表示するには、リモートモードで list-iiop-listeners サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-iiop-listeners(1) サブコマンドを使用して、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
list-iiop-listeners(1) サブコマンドを使用して、IIOP リスナーを一覧表示します。
set(1) サブコマンドを使用して、指定した IIOP リスナーの値を変更します。
リスナーは、そのドット表記名で指定します。
この例では、SSL を有効から無効に変更します。
asadmin> set "server.iiop-service.iiop-listener.SSL.enabled" server.iiop-service.iiop-listener.SSL.enabled=false Command set executed successfully. |
IIOP リスナーを削除するには、リモートモードで delete-iiop-listener サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-iiop-listeners(1) サブコマンドを使用して、IIOP リスナーを一覧表示します。
delete-iiop-listener(1) サブコマンドを使用して、IIOP リスナーを削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例では、sample_iiop_listener という名前の IIOP リスナーを削除します。
asadmin> delete-iiop-listener sample_iiop_listener Command delete-iiop-listener executed successfully. |
コマンド行に asadmin help delete-iiop-listener と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Sun JavaTM Enterprise Server には、JavaMail API、およびアプリケーションコンポーネントでインターネット上で電子メール通知を送信し、IMAP および POP3 メールサーバーから電子メールを読み取ることを可能にする 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 サービスと JNDI にアクセス可能になります。メールセッションを作成するときに、メールホスト、トランスポートプロトコルとストアプロトコル、およびデフォルトのメールユーザーを指定できるので、JavaMail を使用するコンポーネントはこれらのプロパティーを設定する必要がありません。Enterprise Server は単一のセッションオブジェクトを作成して、セッションオブジェクトを必要とするすべてのコンポーネントから使用できるようにするので、電子メールを大量に使用するアプリケーションにメリットがあります。
次のような JavaMail 設定を指定できます。
「JNDI 名」。メールセッションの一意の名前。JavaMail リソースのネーミングサブコンテキストプレフィックス mail/ を使用することをお勧めします。例: mail/MySession
「メールホスト」。デフォルトメールサーバーのホスト名。プロトコル固有のホストプロパティーが提供されていない場合に、Store オブジェクトと Transport オブジェクトの接続メソッドはこの値を使用します。この名前は実際のホスト名として解決可能でなければいけません。
「デフォルトユーザー」。メールサーバーへの接続時に渡されるユーザー名。プロトコル固有の username プロパティーが提供されていない場合に、Store オブジェクトと Transport オブジェクトの接続メソッドはこの値を使用します。
「デフォルトの返信用アドレス」。デフォルトユーザーの電子メールアドレス。username@host.domain の形式で入力します。
「説明」。コンポーネントの説明。
「セッション」。今回メールセッションを有効にするか、無効にするかを指定します。
ここでは、次のテーマを取り上げます。
JavaMail セッションリソースを作成するには、リモートモードでサブコマンド create-javamail-resource を使用します。JavaMail セッションリソースの JNDI 名は通例、mail/ の命名サブコンテキスト (例: mail/MyMailSession.) を含みます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-javamail-resource(1) サブコマンドを使用して、JavaMail リソースを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、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 セッションリソースを一覧表示するには、リモートモードで list-javamail-resources サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-javamail-resources(1) サブコマンドを使用して、JavaMail リソースを一覧表示します。
この例は、localhost の JavaMail リソースを一覧表示します。
asadmin> list-javamail-resources mail/MyMailSession Command list-javamail-resources executed successfuly. |
コマンド行に asadmin help list-javamail-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
list-javamail-resources(1) サブコマンドを使用して、JavaMail リソースを一覧表示します。
set(1) サブコマンドを使用して、指定した 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 セッションリソースを削除するには、リモートモードで delete-javamail-resource サブコマンドを使用します。
サブコマンド delete-javamail-resource を実行するには、指定のリソースへの参照を削除しておく必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-javamail-resources(1) サブコマンドを使用して、JavaMail リソースを一覧表示します。
delete-javamail-resource(1) サブコマンドを使用して、JavaMail リソースを削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例は、mail/MyMailSession という名前の JavaMail セッションリソースを削除します。
asadmin> delete-javamail-resource mail/MyMailSession Command delete-javamail-resource executed successfully. |
コマンド行に asadmin help delete-javamail-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Sun では、Sun GlassFishTM Message Queue ソフトウェアを Sun GlassFish Enterprise Server に統合することで、JMS (JavaTM Message Service) API を実装しています。この章では、asadmin コマンド行ユーティリティーを使用して、Enterprise Server 環境で JMS リソースを管理する手順について説明します。
JMS リソースは、Enterprise Server の Full Platform Profile のみでサポートされ、Web Profile ではサポートされません。
ここでは、次のテーマを取り上げます。
この章のタスクを 管理コンソール を使用して実行する場合の手順は、管理コンソールのオンラインヘルプで説明します。
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 は、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 プロバイダの「物理送信先」を使用して、コンシューマにルーティングおよび配信されます。物理送信先は、管理対象オブジェクト (Topic または Queue 送信先リソースなど) によって識別およびカプセル化されます。アプリケーションコンポーネントはこのオブジェクトを使用して、生成しているメッセージの送信先と、消費しているメッセージの発信元を指定します。送信先リソースを設定する手順については、「接続ファクトリまたは送信先リソースを作成する」を参照してください。
メッセージ駆動型 Bean が配備され、この Bean が待機する物理送信先が存在しない場合、Enterprise Server は自動的に物理送信先を作成し、maxNumActiveConsumers プロパティーの値を -1 に設定します。ただし、あらかじめ物理送信先を作成しておく方がよい方法です。アプリケーションが最初に送信先リソースにアクセスすると、Message Queue は、送信先リソースの名前プロパティーで指定した物理送信先を自動的に作成します。物理送信先は一時的なものなので、Message Queue の構成プロパティーで指定した期限が切れると効力を失います。
ここでは、次のテーマを取り上げます。
本稼動環境では、必ず物理送信先を作成する必要があります。ただし、開発およびテスト段階では、この手順は不要です。物理送信先を作成するには、リモートモードで create-jmsdest サブコマンドを使用します。
物理送信先は、実際にはサーバーオブジェクトというよりも Message Queue オブジェクトであるため、プロパティーを更新する場合は Message Queue ブローカのコマンドを使用します。Message Queue プロパティーの詳細は、『Sun GlassFish Message Queue 4.4 Administration Guide』を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jmsdest(1) サブコマンドを使用して、JMS 物理送信先を作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
この例では、PhysicalQueue という名前のキューを作成します。
asadmin> create-jmsdest --desttype queue --property User=public:Password=public PhysicalQueue Command create-jmsdest executed successfully. |
コマンド行に asadmin help create-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の JMS 物理送信先を一覧表示するには、リモートモードで list-jmsdest サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jmsdest(1) サブコマンドを使用して、既存の JMS 物理送信先を一覧表示します。
この例では、デフォルトサーバーインスタンスの物理送信先を一覧表示します。
asadmin> list-jmsdest PhysicalQueue queue {} PhysicalTopic topic {} Command list-jmsdest executed successfully. |
コマンド行に asadmin help list-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
指定したターゲットの JMS サービス構成の物理送信先からメッセージを消去するには、リモートモードで flush-jmsdest サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
flush-jmsdest(1) サブコマンドを使用して、JMS 物理送信先からメッセージを消去します。
(省略可能) 必要な場合は、サーバーを再起動します。
プロパティーの中には、サーバーの再起動を求めるものもあります。「サーバーの再起動が必要な構成の変更」を参照してください。サーバーを再起動する必要がある場合は、「ドメインの再起動」を参照してください。
この例では、PhysicalQueue という名前のキューからメッセージを消去します。
asadmin> flush-jmsdest --desttype queue PhysicalQueue Command flush-jmsdest executed successfully |
コマンド行に asadmin help flush-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
指定した JMS 物理送信先を削除するには、リモートモードで delete-jmsdest サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jmsdest(1) サブコマンドを使用して、既存の JMS 物理送信先を一覧表示します。
delete-jmsdest(1) サブコマンドを使用して、物理送信先を削除します。
この例では、PhysicalQueue という名前のキューを削除します。
asadmin> delete-jmsdest --desttype queue PhysicalQueue Command delete-jmsdest executed successfully |
コマンド行に asadmin help delete-jmsdest と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
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 接続ファクトリごとに、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 サブコマンドを使用します。「管理対象オブジェクトを更新する」を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jms-resource(1) コマンドを使用して、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. |
この例では、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の接続ファクトリと送信先リソースを一覧表示するには、リモートモードで list-jms-resources サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jms-resources(1) サブコマンドを使用して、既存の JMS リソースを一覧表示します。
この例では、既存の JMS 接続ファクトリと送信先リソースをすべて表示します。
asadmin> list-jms-resources jms/Queue jms/ConnectionFactory jms/DurableConnectionFactory jms/Topic Command list-jms-resources executed successfully |
この例では、リソースタイプが 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 リソースへの参照をすべて削除する必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jms-resources(1) サブコマンドを使用して、既存の JMS リソースを一覧表示します。
delete-jms-resource(1) サブコマンドを使用して、JMS リソースを削除します。
この例では、jms/Queue リソースを削除します。
asadmin> delete-jms-resource jms/Queue Command delete-jms-resource executed successfully |
コマンド行に asadmin help delete-jms-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
「JMS ホスト」は、Message Queue ブローカを表します。JMS には「JMS ホストリスト」 (AddressList プロパティー) が含まれ、このリストには Enterprise Server が使用するすべての JMS ホストが含まれます。JMS ホストリストには、指定した メッセージキュー ブローカのホストとポートが取り込まれ、JMS ホスト構成が変更されるたびに更新されます。JMS リソースを作成するとき、またはメッセージ駆動型 Bean を配備するときに、リソースまたは Bean が JMS ホストリストを継承します。
JMS ホストリスト内のホストの 1 つが、デフォルト JMS ホストに指定されます。Message Queue ブローカモードが LOCAL に設定されている場合は、Enterprise Server がデフォルト 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』を参照してください。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jms-host(1) サブコマンドを使用して、JMS ホストを作成します。
このサブコマンドのプロパティーについては、サブコマンドのマニュアルページを参照してください。
この例では、MyNewHost という名前の JMS ホストを作成します。
asadmin> create-jms-host --mqhost pigeon --mqport 7677 MyNewHost Command create-jms-host executed successfully. |
コマンド行に asadmin help create-jms-host と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の JMS ホストを一覧表示するには、リモートモードで list-jms-hosts サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jms-hosts(1) サブコマンドを使用して、JMS ホストを一覧表示します。
次のサブコマンドは、既存の JMS ホストを一覧表示します。
asadmin> list-jms-hosts default_JMS_host MyNewHost Command list-jmsdest executed successfully |
list-jms-hosts(1) サブコマンドを使用して、JMS ホストを一覧表示します。
set(1) サブコマンドを使用して、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 サービスから削除するには、リモートモードで delete-jms-host サブコマンドを使用します。JMS ホストだけを削除すると、新しい JMS ホストを作成するまで、Message Queue ブローカを起動できなくなります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jms-hosts(1) サブコマンドを使用して、JMS ホストを一覧表示します。
delete-jms-host(1) サブコマンドを使用して、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 と呼ばれます。
ここでは、次のテーマを取り上げます。
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 プロパティーを使用して接続ファクトリリソースを作成します。これにより、リモートサーバーにアクセスする接続が作成されます。
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 から使用できるようにする必要があります。
コネクタモジュールを配備する場合と同じように、汎用リソースアダプタを配備します。
コネクタ接続プールを作成します。
「コネクタ接続プールを作成する」を参照してください。
コネクタリソースを作成します。
「コネクタリソースを作成する」参照してください。
管理対象オブジェクトリソースを作成します。
「管理対象オブジェクトリソースを作成する」を参照してください。
セキュリティーの 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": |
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 |
Java Naming and Directory Interface (JNDI) API は、別の種類のネームサービスおよびディレクトリサービスにアクセスするために使用されます。Java EE コンポーネントは、JNDI ルックアップメソッドを起動することによってオブジェクトを検出します。
ここでは、次のテーマを取り上げます。
アプリケーションは JNDI API を呼び出すことにより、リソースとほかのプログラムオブジェクトを検出します。「リソース」は、データベースサーバーやメッセージングシステムなどのシステムへの接続を提供するプログラムオブジェクトです。JDBC リソースはデータソースと呼ばれる場合もあります。それぞれのリソースオブジェクトは人間が理解しやすい 「JNDI 名」という一意の名前で識別されます。リソースオブジェクトと JNDI 名は、Enterprise Server に含まれているネーミングおよびディレクトリサービスによって相互にバインドされています。
新しい名前とオブジェクトのバインドが JNDI に入力されると、新しいリソースが作成されます。
ここでは、次のテーマを取り上げます。
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 検索と関連するリソース参照 を示します。
表 20–1 JNDI 検索名と関連する参照
JNDI ルックアップ名 |
関連するリソース参照 |
---|---|
java:comp/env |
アプリケーション環境エントリ |
java:comp/env/jdbc |
JDBC データソースリソースマネージャー接続ファクトリ |
java:comp/env/ejb |
EJB 参照 |
java:comp/UserTransaction |
UserTransaction 参照 |
java:comp/env/mail |
JavaMail セッション接続ファクトリ |
java:comp/env/url |
URL 接続ファクトリ |
java:comp/env/jms |
JMS 接続ファクトリと送信先 |
java:comp/ORB |
アプリケーションコンポーネント間で共有された ORB インスタンス |
Enterprise Server 内で、カスタムリソースおよび外部 JNDI リソース用に環境を設定できます。カスタムリソースはローカル JNDI リポジトリにアクセスし、外部リソースは外部 JNDI リポジトリにアクセスします。どちらのタイプのリソースにも、ユーザーが指定したファクトリクラスの要素や JNDI 名前属性などが必要です。
カスタムリソースは、javax.naming.spi.ObjectFactory インタフェースを実装するサーバー全体のカスタムリソースオブジェクトファクトリを指定します。ここでは、次のテーマを取り上げます。
カスタムリソースを作成するには、リモートモードで create-custom-resource サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-custom-resource(1) サブコマンドを使用して、カスタムリソースを作成します。
サブコマンドのプロパティーについては、サブコマンドのマニュアルページを参照してください。
Enterprise Serverを再起動します。
「ドメインの再起動」を参照してください。
この例では、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 と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存のカスタムリソースを一覧表示するには、リモートモードで list-custom-resources サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-custom-resources(1) サブコマンドを使用して、カスタムリソースを一覧表示します。
この例では、既存のカスタムリソースを一覧表示します。
asadmin> list-custom-resources sample_custom_resource01 sample_custom_resource02 Command list-custom-resources executed successfully |
コマンド行に asadmin help list-custom-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
list-custom-resources(1) サブコマンドを使用して、カスタムリソースを一覧表示します。
set(1) サブコマンドを使用して、カスタム JNDI リソースを変更します。
この例では、カスタムリソースを変更します。
asadmin> set server.resources.custom-resource.custom /my-custom-resource.property.value=2010server.resources.custom-resource.custom /my-custom-resource.property.value=2010 |
カスタムリソースを削除するには、リモートモードで delete-custom-resource サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-custom-resources(1) サブコマンドを使用して、カスタムリソースを一覧表示します。
delete-custom-resource(1) サブコマンドを使用して、カスタムリソースを削除します。
この例では、sample-custom-resource という名前のカスタムリソースを削除します。
asadmin> delete-custom-resource sample_custom_resource Command delete-custom-resource executed successfully. |
コマンド行に asadmin help delete-custom-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Enterprise Server 上で動作しているアプリケーションでは、外部 JNDI リポジトリに保存されているリソースへのアクセスが必要となる場合があります。たとえば、汎用の Java オブジェクトを Java スキーマに従って LDAP サーバーに格納する場合があります。外部 JNDI リソース要素を使用すると、このような外部リソースリポジトリを設定できます。
ここでは、次のテーマを取り上げます。
外部 JNDI リソースを登録するには、リモートモードで create-jndi-resource サブコマンドを使用します。
外部 JNDI ファクトリは、javax.naming.spi.InitialContextFactory インタフェースを実装する必要があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jndi-resource(1) サブコマンドを使用して、外部 JNDI リソースを登録します。
サブコマンドのプロパティーについては、サブコマンドのマニュアルページを参照してください。
Enterprise Serverを再起動します。
「ドメインの再起動」を参照してください。
この例では、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 リソースをすべて表示するには、リモートモードで list-jndi-resources サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jndi-resources(1) サブコマンドを使用して、既存の JNDI リソースを一覧表示します。
この例では、JNDI リソースを一覧表示します。
asadmin> list-jndi-resources jndi_resource1 jndi_resource2 jndi_resource3 Command list-jndi-resources executed successfully |
コマンド行に asadmin help list-jndi-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
JNDI ツリーでエントリを参照および一覧表示するには、リモートモードで list-jndi-entries サブコマンドを使用します。すべてのエントリを表示するか、JNDI コンテキストまたはサブコンテキストを指定して特定のエントリだけを一覧表示できます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jndi-entries(1) サブコマンドを使用して、構成の JNDI エントリを一覧表示します。
この例では、ネームサービスの JNDI エントリをすべて表示します。
asadmin> list-jndi-entries jndi_entry03 jndi_entry72 jndi_entry76 Command list-jndi-resources executed successfully |
コマンド行に asadmin help list-jndi-entries と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
list-jndi-resources(1) サブコマンドを使用して、既存の JNDI リソースを一覧表示します。
set(1) サブコマンドを使用して、外部 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 リソースを削除するには、リモートモードで delete-jndi-resource サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
delete-jndi-resource(1) サブコマンドを使用して、外部 JNDI エントリを削除します。
この例では、外部 JNDI リソースを削除します。
asadmin> delete-jndi-resource jndi_resource2 Command delete-jndi-resource executed successfully. |
コマンド行に asadmin help delete-jndi-resource と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
<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>
この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server 環境でトランザクションサービスを管理する方法について説明します。トランザクションを手動で回復する手順についても説明します。
ここでは、次のテーマを取り上げます。
本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。トランザクションサービス、トランザクションログ、および分散トランザクションの回復の設定については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 15 章「Using the Transaction Service」を参照してください。
「トランザクション」は、アプリケーション内の独立したアクションをひと続きにまとめたもので、一連のアクションのすべてが正常に完了する必要があります。トランザクションでは、1 つ以上のアクションをそれ以上分割不可能な作業単位にまとめることで、データの完全性と整合性を保証しています。すべてのアクションが完了しなかった場合、変更はロールバックされます。
たとえば、当座預金口座から普通預金口座に資金を移動する場合は、一般的に次のような手順が発生します。
当座預金口座にその移動をカバーするだけの金額があるかどうかを確認します。
その金額を当座預金口座の借方に記帳します。
その金額を普通預金口座の貸方に記帳します。
その移動を当座預金口座ログに記録します。
その移動を普通預金口座ログに記録します。
これらの手順をまとめて、1 つのトランザクションと見なします。
すべての手順が正常に完了すれば、トランザクションは「コミット」されます。いずれかの手順が失敗した場合は、それ以前の手順で行われた変更がすべてロールバックされ、当座預金口座と普通預金口座はトランザクションが開始される前の状態に戻されます。この種類のイベントは「ロールバック」と呼ばれます。通常のトランザクションは、コミットされた状態かロールバックされた状態で終了します。
次の要素は、さまざまな API と機能を実装することで、信頼性の高いトランザクション処理に貢献します。
「トランザクションマネージャー」。トランザクション境界、トランザクションリソース管理、同期化、およびトランザクションコンテキスト伝達のサポートに必要なサービスと管理機能を提供します。
「Enterprise Server」。トランザクション状態管理を含むアプリケーション実行環境のサポートに必要なインフラストラクチャーを提供します。
「リソースマネージャー」。リソースアダプタを通して、アプリケーションがリソースにアクセスできるようにします。リソースマネージャーは、トランザクションマネージャーがトランザクションの関連付け、トランザクションの完了、および回復作業の伝達に使用するトランザクションリソースインタフェースを実装することで、分散トランザクションに参加します。このようなリソースマネージャーの例としては、リレーショナルデータベースサーバーがあります。
「リソースアダプタ」。Enterprise Server またはクライアントがリソースマネージャーへの接続に使用する、システムレベルのソフトウェアライブラリです。通常、リソースアダプタはリソースマネージャーに固有です。リソースアダプタはライブラリとして使用可能で、クライアントのアドレス空間内で使用されます。リソースアダプタの例として、JavaTM 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 サブコマンドを使用して再開するまで、中断されたままになります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
freeze-transaction-service(1) サブコマンドを使用して、トランザクションサービスを停止します。
この例では、トランザクションサービスを停止します。
asadmin> freeze-transaction-service Command freeze-transaction-service executed successfully |
コマンド行に asadmin help freeze-transaction-service と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
状況に応じて、特定のトランザクションをロールバックできます。トランザクションをロールバックする前に、トランザクション処理を中断するためにトランザクションサービスを停止する必要があります。特定のトランザクションをロールバックするには、リモートモードで rollback-transaction サブコマンドを使用します。
実行中のトランザクションをロールバックする前に、トランザクションサービスを停止します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
ロールバックするトランザクションの ID を確認します。
アクティブなトランザクションの ID を一覧表示するには、get サブコマンドを使用して activeids 統計の監視データを取得します。「トランザクションサービスの統計」を参照してください。
rollback-transaction(1) サブコマンドを使用して、トランザクションをロールバックします。
この例では、トランザクション ID が 0000000000000001_00 のトランザクションをロールバックします。
asadmin> rollback-transaction 0000000000000001_00 Command rollback-transaction executed successfully |
コマンド行に asadmin help rollback-transaction と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
中断されている実行中のトランザクションをすべて再開するには、リモートモードで unfreeze-transaction-service サブコマンドを使用します。トランザクションサービスを凍結したあとは、このサブコマンドを実行してサービスを再開します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
unfreeze-transaction-service(1) サブコマンドを使用して、中断されているトランザクションサービスを再開します。
この例では、凍結されているトランザクションサービスを再開します。
asadmin> unfreeze-transaction-service Command unfreeze-transaction-service executed successfully |
コマンド行に asadmin help unfreeze-transaction-service と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
一般的にサーバーまたはリソースマネージャーのクラッシュが原因で、コミットまたはロールバックの処理が中断される場合があります。クラッシュが発生すると、一部のトランザクションがステップの間に取り残される可能性があります。Enterprise Server は、これらの障害を回復し、サーバーの起動時にそのトランザクションを完了するように設計されています。失敗したトランザクションが複数のサーバーにわたっている場合は、トランザクションを開始したサーバーがトランザクションの結果を取得しようとしてほかのサーバーに問い合わせる場合があります。ほかのサーバーにアクセスできない場合、トランザクションは特殊な結果判別の情報を使用して、その結果を判別します。トランザクションはサーバーの起動時に解決されます。
クラッシュ以外の障害が発生している場合は、次の手順で手動回復を実行することができます。
サーバー上のリソースで障害が発生したときに保留中になったトランザクションを手動で回復するには、リモートモードで recover-transactions サブコマンドを使用します。サーバーがクラッシュしたあとに、手動のトランザクション回復を使用してトランザクションを回復することはできません。手動による操作は、リソースで予期しない障害が発生しても、まだサーバーが動作している状況での回復を目的としています。サーバーがクラッシュした場合、不確かなトランザクションを回復できるのは、完全な起動による回復処理だけです。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
recover-transactions(1) サブコマンドを使用して、トランザクションを手動で回復します。
この例では、sampleserver でトランザクションの手動回復を実行します。
asadmin recover-transactions sampleserver Transaction recovered. |
コマンド行に asadmin help recover-transactions と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。