WebLogic JMS プログラマーズ ガイド
|
 |
 |
|
WebLogic Server Administration Console は、JMS を含む WebLogic Server の機能を有効化、コンフィグレーション、およびモニタするためのインタフェースを備えています。Administration Console の起動手順については、Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。
以下の節では、WebLogic JMS のコンフィグレーションおよびモニタについて概説します。
Administration Console を使用して、以下のコンフィグレーション属性を定義します。
WebLogic JMS では、一部のコンフィグレーション属性に対して、デフォルト値が用意されていますが、それ以外のすべての属性に対しては値を指定する必要があります。コンフィグレーション属性に対して無効な値を指定した場合や、デフォルト値が存在しない属性に対して値を指定しなかった場合は、再起動時に JMS が起動されません。コンフィグレーション可能なすべての JMS 属性のデフォルト値を確認するには、Administration Console オンライン ヘルプの「JMS に関する属性と Administration Console 画面のリファレンス」を参照してください。
examplesServer には、サンプル コンフィグレーションとして examplesJMSServer が用意されています。サンプル サーバを起動する手順については、『WebLogic Server のコンフィグレーションと管理』の「サーバの起動と停止 : クイック リファレンス」を参照してください。
WebLogic JMS 属性をコンフィグレーションするには、Administration Console オンライン ヘルプの「JMS : コンフィグレーション」で説明されている手順に従って JMS オブジェクトを作成およびコンフィグレーションします。WebLogic JMS をコンフィグレーションすると、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。WebLogic JMS アプリケーションの開発の詳細については、「WebLogic JMS アプリケーションの開発」を参照してください。
Weblogic Server の以前のリリースから移行する場合、コンフィグレーション情報は自動的に変換されます (「既存のアプリケーションの移植」を参照)。
以下の節では、WebLogic Server および Administration Console の起動方法を概説し、基本的な WebLogic JMS 実装をコンフィグレーションする手順について説明します。
WebLogic Server のデフォルトのロールは管理サーバです。ドメインが 1 つの WebLogic Server のみで構成されている場合は、そのサーバが管理サーバになります。ドメインが複数の WebLogic Server インスタンスで構成されている場合は、まず管理サーバを起動してから、管理対象サーバを起動します。
管理サーバの起動方法の詳細については、Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。
Administration Console は、WebLogic Server に対する Web ベースの管理者フロントエンド (管理者クライアント インタフェース) です。サーバの Administration Console にアクセスする前に、サーバを起動する必要があります。
Administration Console を使用して WebLogic Server インスタンスをコンフィグレーションする手順については、『WebLogic Server のコンフィグレーションと管理』の「Administration Console の起動」を参照してください。
この節では、Administration Console を使用して基本的な JMS 実装をコンフィグレーションする方法について説明します。
JMS ファイル ストアおよびページング ファイル ストアのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS ファイル ストアのタスク」を参照してください。
注意 : JDBC 接続プールおよび JMS JDBC ストアのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS JDBC ストアのタスク」、「JDBC 接続プール」、「[JDBC マルチ プール]」、および「JDBC データ ソース」を参照してください。
JMS テンプレートのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS テンプレートのタスク」を参照してください。
JMS サーバのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS サーバのタスク」を参照してください。
JMS 送り先のコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS キューおよびトピック送り先のタスク」を参照してください。
デフォルト接続ファクトリの使い方の詳細については、「デフォルト接続ファクトリの使い方」を参照してください。接続ファクトリのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」を参照してください。
コンフィグレーション ウィザードは、WebLogic Server の管理ドメインとサーバ コンフィグレーションを作成する Java アプリケーションです。コンフィグレーション ウィザードを使用して、JMS、データベース接続 (JDBC)、セキュリティ グループなどのリソースや、セキュリティ ロール、およびユーザ アカウントをコンフィグレーションできます。既存のドメインを変更することもできます。詳細については、『コンフィグレーション ウィザードの使い方』の「Java Messaging Service のコンフィグレーション」を参照してください。
WebLogic Server のクラスタはドメイン内のサーバ群で、より強力で信頼性のあるアプリケーション プラットフォームを提供します。クラスタはそのクライアントにとって単一のサーバに見えますが、実際には、一体で機能するサーバ群です。クラスタは、単一のサーバを超える下記の 4 つの重要な機能を提供します。
WebLogic Server クラスタの機能とメリットについては、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic Server のクラスタ化の概要」を参照してください。
JMS クラスタ化を実装するには、クラスタ化された有効な JMS ライセンスが必要です。このライセンスにより、接続ファクトリや送り先を別の WebLogic Server インスタンスに配置することが可能になります。クラスタ化された JMS ライセンスは、外部 JMS プロバイダ機能を使用するためにも必要です。外部 JMS プロバイダ機能の詳細については、Administration Console オンライン ヘルプの「リモートまたは外部 JMS プロバイダへの単純なアクセス」を参照してください。クラスタ化された有効な JMS ライセンスの入手方法については、BEA 販売代理店にお問い合わせください。
管理者は、クラスタ内の各サーバ インスタンスのデフォルト接続ファクトリを使用するか、1 つまたは複数の接続ファクトリをコンフィグレーションしてクラスタ内の 1 つまたは複数のサーバ インスタンスを対象とすることで、クラスタ内のあらゆるサーバから JMS 送り先へのクラスタワイドで透過的なアクセスを確立できます。これにより、各接続ファクトリを複数の WebLogic Server にデプロイできます。 ただし、複数の WebLogic Server にデプロイする場合は、問題なくデプロイできるように、ユーザ定義の各接続ファクトリにユニークな名前を付ける必要があります。接続ファクトリのコンフィグレーションおよびデプロイ、またはデフォルトの接続ファクトリの使い方の詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」を参照してください。
管理者は、クラスタ内のさまざまなサーバ インスタンス上の複数の JMS サーバにユニークな名前が付けられているかぎり、それらの JMS サーバをコンフィグレーションして JMS 送り先を割り当てることもできます。アプリケーションでは、Java Naming and Directory Interface (JNDI) を使用して接続ファクトリをルックアップし、JMS サーバとの通信を確立するための接続を作成します。各 JMS サーバでは、複数の送り先に対するリクエストが処理されます。JMS サーバで処理されない送り先へのリクエストは、適切な WebLogic Server インスタンスに転送されます。JMS サーバのコンフィグレーションおよびデプロイの詳細については、Administration Console オンライン ヘルプの「JMS サーバのタスク」を参照してください。
以下のガイドラインは、WebLogic JMS を単一または複数ドメインで構成されるクラスタ環境で動作するようにコンフィグレーションする場合に適用されます。
単一および複数のドメイン環境における JMS リソースの命名規則の詳細については、Administration Console オンライン ヘルプの「ドメインの相互運用性を実現するための JMS リソースの命名規則」を参照してください。
分散送り先は、単一の JNDI 名でアクセスされ、クライアントからは単一の論理的な送り先に見える物理的な送り先のセットです。分散送り先のメンバーは、実際にはクラスタ内の複数のサーバに分散されており、各送り先メンバーは個々の JMS サーバに属しています。分散送り先を使用すると、WebLogic JMS によって高可用性およびクラスタ内の物理的な送り先間でのロード バランシングがサポートされます。すなわち、サーバの障害で送り先メンバーがアクセス不能になった場合に、他のアクセス可能な送り先メンバーにトラフィックがリダイレクトされます。分散送り先のコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS 分散送り先のタスク」を参照してください。
WebLogic JMS は、クラスタ環境用の WebLogic Server コアに実装されている移行フレームワークを利用します。これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への対応としての移行も含まれます。詳細については、「JMS サーバの移行可能対象のコンフィグレーション」を参照してください。
クラスタ環境で WebLogic JMS を使用する場合は、以下のガイドラインに従います。
これらの接続ファクトリのコンフィグレーション属性の詳細については、Administration Console オンライン ヘルプの「JMS 接続ファクトリのタスク」を参照してください。
JMS の移行可能対象サーバの詳細については、「JMS サーバの移行可能対象のコンフィグレーション」を参照してください。 JMS サーバのコンフィグレーション属性の詳細については、Administration Console オンライン ヘルプの「JMS サーバのタスク」を参照してください。
注意 : 同じ送り先を複数の JMS サーバにデプロイすることはできません。また、1 つの JMS サーバを複数の WebLogic Server にデプロイすることもできません。
クラスタ環境の一部である WebLogic Server インスタンスでは、複数の物理的送り先 (キューとトピック) を単一の分散送り先セットの一部としてコンフィグレーションすることで、1 台のサーバに障害が発生した場合にも、WebLogic JMS によるサービスが継続されます。さらに、移行可能サービスの機能を実装すると、JMS のような固定された「かならず 1 回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル ポイント障害が発生しなくなります。
ただし、自動フェイルオーバは現在 WebLogic JMS でサポートされていません。手動フェイルオーバの実行の詳細については、「WebLogic Server の障害からの回復」を参照してください。
JMS サーバが行うのは「かならず 1 回」のサービスなので、クラスタ内のすべての WebLogic Server のインスタンスに対してアクティブというわけではありません。代わりに、データの一貫性を保持するためにクラスタ内の単一サーバに「固定」されます。固定されたサービスにより、クラスタ内にある依存するアプリケーションに対してシングル ポイント障害が発生しないように、移行可能対象リスト内のあらゆるサーバをコンフィグレーションして、1 回だけサービスを移行するようにできます。
WebLogic JMS は、この移行フレームワークを活用して、管理者が Administration Console で JMS サーバの移行可能対象を指定できるようにします。いったん適切にコンフィグレーションすると、JMS サーバとその送り先すべてをクラスタ内の別の WebLogic Server へ移行することができます。
これにより、WebLogic JMS は、移行リクエストに適切に応答し、JMS サーバを正しい順序でオンラインまたはオフラインにすることができます。移行には、スケジューリング済み移行のほかに、クラスタ内の WebLogic Server の障害に応答して発生する移行が含まれます。
固定サービスの移行の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「固定サービスの移行」を参照してください。
クラスタ環境で JMS サーバを移行可能なサービスにするには、以下の作業が必要です。
注意 : 移行された JMS サーバをホストすることになる移行可能対象サーバのインスタンスには、ユニークなリスン アドレス値を設定する必要があります。ユニークな値を設定しない場合、移行は失敗します。
注意 : 移行可能対象サーバが起動すると、クラスタ内のユーザが選んだサーバ上で、JMS サーバも自動的に起動します。
注意 : 対象サーバ インスタンスがすでに JMS サーバとその分散送り先メンバーをホストしているときでも、JMS サーバの分散送り先メンバーはクラスタ内の別のサーバ インスタンスへ移行できます。 分散送り先でのフェイル オーバーの詳細については、「分散送り先のフェイルオーバ」を参照してください。
警告 : グローバル トランザクションに単独で参加している JMS サービスを、保留中のトランザクションが残らないように移行するには、JMS サービスと JTA サービスの両方を移行する必要があります。その場合、JMS サービスを移行してから JTA サービスを移行しなければなりません。
JMS ファイル ストアは、JMS サーバとともに移行できません。したがって、JMS サーバを移行した後にほかの物理マシンから永続ストアへのアクセスを必要とするアプリケーションでは、次のように代替のソリューションを実装する必要があります。
JMS JDBC ストアのコンフィグレーションの詳細については、Administration Console オンライン ヘルプの「JMS JDBC ストアのタスク」を参照してください。
JMS サーバとは、WebLogic Server によって管理されるリソースです。管理対象リソースとしての JMS には、管理用にコンフィグレーションおよびモニタできる一連の属性が組み込まれています。たとえば、各 JMS サーバには、そのサーバの名前、送り先名、しきい値、および配信パラメータを定義する属性が組み込まれています。コンフィグレーション MBean および実行時 MBean の双方を管理できます。詳細については、『WebLogic JMX Service プログラマーズ ガイド』を参照してください。
コード リスト 3-1 JMX を使用した JMS キューの作成
import java.util.Iterator;
import java.util.Set;
import javax.management.ObjectName;
import javax.management.QueryExp;
import javax.management.Attribute;
import javax.naming.Context;
import weblogic.jndi.Environment;
import weblogic.management.MBeanHome;
import weblogic.management.RemoteMBeanServer;
import weblogic.management.WebLogicObjectName;
import weblogic.management.configuration.JMSQueueMBean;
import weblogic.management.configuration.JMSServerMBean;
import weblogic.management.configuration.JMSDestinationMBean;
import weblogic.management.runtime.JMSServerRuntimeMBean;
public class JMSAddQueue {
// WebLogic ドメインの名前。実際のドメインの名前にあわせて //
// 変更してください //
private static String weblogicDomain = "mydomain";
// WebLogic サーバの名前。実際のサーバの名前にあわせて //
// 変更してください //
private static String weblogicServer = "myserver";
// 作成する新しい JMSQueue の名前 //
private static String jmsQueue = "JMSQueue-7";
public static void main(String[] args) {
try {
Environment env = new Environment();
env.setProviderUrl("t3://localhost:7001");
env.setSecurityPrincipal("weblogic");
env.setSecurityCredentials("weblogic");
Context ctx = env.getInitialContext();
MBeanHome home = (MBeanHome) ctx.lookup(MBeanHome.ADMIN_JNDI_NAME);
ctx.close();
WebLogicObjectName aObjectName = new
WebLogicObjectName("JMSServer1",
"JMSServer",
weblogicDomain);
JMSServerMBean jmsServer = (JMSServerMBean)home.getMBean(aObjectName);
// 新しい JMSQueueMBean を作成する
JMSDestinationMBean destination = (JMSQueueMBean)
home.createAdminMBean(jmsQueue,"JMSQueue");
destination.setJNDIName("JNDINAME-"+jmsQueue);
destination.setParent(jmsServer);
jmsServer.addDestination(destination);
// MBean サーバに問い合わせを行い、作成した Queue を検索する
QueryExp query = null;
RemoteMBeanServer bSvr = home.getMBeanServer();
Set queueNames = bSvr.queryNames(new ObjectName(weblogicDomain+":Type=JMSQueue,Name="+jmsQueue+",*"),query);
ObjectName name = (ObjectName)queueNames.iterator().next();
System.out.println("QUEUE MBEAN RETRIEVED: " + name);
// BytesMaximum 属性を、デフォルト値以外に
// 設定する
bSvr.setAttribute(name,new Attribute("BytesMaximum",new Long(10000)));
} catch (Exception e) {
e.printStackTrace();
}
}
}
以下の節では、WebLogic JMS で利用できる管理パフォーマンス チューニング機能を実装することによって、アプリケーションを最大限に活用する方法について説明します。
詳細については、Administration Console オンライン ヘルプの「JMS ファイル ストアのパフォーマンスの向上」を参照してください。
詳細については、Administration Console オンライン ヘルプの「メッセージのページングによるメモリの解放」を参照してください。
詳細については、Administration Console オンライン ヘルプの「JMS サーバおよび送り先のメッセージのフロー制御」を参照してください。
詳細については、Administration Console オンライン ヘルプの「メッセージ プロデューサのブロックによる割り当て例外の回避」を参照してください。
詳細については、Administration Console オンライン ヘルプの「期限切れメッセージの処理」を参照してください。
詳細については、Administration Console オンライン ヘルプの「分散送り先のチューニング」を参照してください。
JMS サーバ、接続、セッション、送り先、恒久サブスクライバ、メッセージ プロデューサ、メッセージ コンシューマ、サーバ セッション プールなどの JMS オブジェクトに関する統計が提供されます。JMS 統計は、Administration Console でモニタできます。
サーバの実行中は、JMS 統計は増え続けます。サーバを再起動するときにのみ、統計をリセットできます。WebLogic JMS のコンフィグレーションおよびモニタの詳細については、Administration Console オンライン ヘルプの「JMS : モニタ」を参照してください。
WebLogic JMS をコンフィグレーションすると、アプリケーションで JMS API を使用してメッセージの送受信ができるようになります。詳細については、「WebLogic JMS アプリケーションの開発」を参照してください。
以降の節では、サーバで障害が発生した場合に JMS アプリケーションを正常に終了させる方法、およびサーバで障害が発生した後に JMS データを移行する方法について説明します。
WebLogic Server の障害発生時に正常に終了するよう、JMS アプリケーションをプログラミングすることもできます。次に例を示します。
|
|
|
|
|
WebLogic JMS では、WebLogic Server のコアに実装される移行フレームワークを使用します。これにより、WebLogic JMS は移行要求に正しく応答できるようになり、WebLogic JMS サーバのオンラインとオフラインの切り替えが順序立って行われるようになります。これには、スケジューリングされた移行だけでなく、WebLogic Server の障害への応答としての移行も含まれます。
いったん適切にコンフィグレーションすると、JMS サーバとそのすべての送り先をクラスタ内の別の WebLogic Server へ移行できます。
新しくサーバを起動し、表 3-2 のタスクのうち 1 つ以上を実行することで、障害が発生した WebLogic Server から JMS データを回復できます。
注意 : クラッシュしているか、管理サーバからアクセスできないサーバ インスタンスからサービスを移行するときには、特別な考慮事項があります。移行を実行する時点で、以前アクティブだったサービスのホストに管理サーバからアクセスできない場合は、「現在アクティブなホストがない場合のサービスの移行」を参照してください。
|
|
|
|
|
注意 : JMS 永続ストアに格納されているメッセージ数が増加するにつれて、WebLogic Server の初期化に必要なメモリ量も増加します。WebLogic Server の再起動中にメモリ不足で初期化が失敗した場合は、Java 仮想マシン (JVM) のヒープ サイズを、現在 JMS 永続ストアに格納されているメッセージ数に比例するよう増加させてから、再起動してください。
新しく WebLogic Server を起動する方法の詳細については、Administration Console オンライン ヘルプの「サーバの起動と停止」を参照してください。 障害が発生したサーバの回復については、『WebLogic Server のコンフィグレーションと管理』の「障害が発生したサーバの回復」を参照してください。
移行可能サービスの定義の詳細については、『WebLogic Server クラスタ ユーザーズ ガイド』の「固定サービスの移行」を参照してください。
|
|
|