2 JMSリソースの構成の理解
WebLogic JMSの基本的な概念と機能、およびそれらと他のアプリケーション・コンポーネントおよびOracle WebLogic Serverとの連携の仕組みについて学習します。
この章の内容は次のとおりです。
JMSとOracle WebLogic Serverの概要
JMSのWebLogic Server実装は、WebLogic Serverプラットフォームに緊密に統合されたエンタープライズ・クラスのメッセージング・システムです。
JMS 2.0仕様(http://www.oracle.com/technetwork/java/jms/index.html
で入手可能)を完全にサポートしています。また、標準JMS APIより高度なWebLogic JMS拡張も数多く用意されています。
Java Message Serviceとは
エンタープライズ・メッセージング・システムを使用すると、アプリケーション同士がメッセージを交換することによって非同期的に通信できます。メッセージとは、異なるアプリケーション間の通信を調整するために必要な情報が含まれている、リクエスト、レポート、およびイベントです。メッセージで提供される抽象化の階層により、宛先システムについての詳細情報をアプリケーション・コードから切り離すことができます。
Java Message Service (JMS)は、業界メッセージング・プロバイダによって実装されるエンタープライズ・メッセージング・システムにアクセスするための標準APIです。具体的なJMSの特長は以下のとおりです。
-
メッセージング・システムを共有するJavaアプリケーション同士でメッセージを交換できます
-
メッセージを作成、送信、および受信するための標準インタフェースによりアプリケーションの開発が容易になります
WebLogic JMSは、プロデューサ・アプリケーションからメッセージを受信し、そのメッセージをコンシューマ・アプリケーションに配信します。WebLogic Serverを使用したJMS APIプログラミングの詳細は、Oracle WebLogic Server JMSアプリケーションの開発で、簡略化されたAPIプログラミング・モデルを参照してください。
WebLogic JMSのアーキテクチャと環境
図2-1にWebLogic JMSのアーキテクチャを示します。
WebLogic JMSアーキテクチャの主要コンポーネントは以下のとおりです。
-
JMSサーバーは環境関連の構成エンティティであり、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内のJMSキューおよびトピック・リソースの管理コンテナとして機能します。JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。ドメインごとに1つまたは複数のJMSサーバーを構成でき、1つのJMSサーバーでは1つまたは複数のJMSモジュールを管理できます。「JMSサーバーの概要」を参照してください
-
スタンドアロンのキューおよびトピック宛先、分散宛先、接続ファクトリなどの構成リソースを含み、
weblogic-jms.xsd
スキーマに準拠するXMLドキュメントによって定義されるJMSモジュール。「JMS構成リソースとは」を参照してください -
クライアントJMSアプリケーションは、宛先へのメッセージを生成するか、または宛先からのメッセージを消費します。
-
JNDI (Java Naming and Directory Interface)は、サーバー・ルックアップ機能を提供します。
-
WebLogic永続ストレージ(サーバー・インスタンスのデフォルト・ストア、ユーザー定義のファイル・ストア、またはJDBCでアクセス可能なユーザー定義ストア)。永続メッセージ・データを保持します。
ドメインの構成
一般に、WebLogic Serverドメイン構成ファイル(config.xml
)には、ドメインに必要な構成情報が記述されています。この構成情報は、環境関連の情報とアプリケーション関連の情報にさらに分類できます。環境関連の情報には、JMSサーバーのIDと定義、JDBCデータ・ソース、WebLogic永続ストア、サーバー・ネットワーク・アドレスなどがあります。通常、これらのシステム・リソースは、ドメインごとに一意です。
これらのシステム・リソースの構成と管理を行うのは、WebLogic管理者です。WebLogic管理者は、組織のシステム管理者またはMIS部門からこの情報を受け取ります。これらのタスクを実行するために、管理者はWebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)などの様々なコマンド・ライン・ツール、またはプログラムによる管理用のJMX APIを使用できます。
ドメイン環境に依存しないアプリケーション関連の定義の例としては、様々なJava EEアプリケーション・コンポーネント構成(EAR、WAR、JAR、RARの各ファイル、JMSおよびJDBCモジュールなど)があります。アプリケーション・コンポーネントは、アプリケーション開発チームによって開発およびパッケージ化され、さらにプログラム(コンパイル済みJavaコード)とその構成情報(記述子とも呼ばれ、そのほとんどはXMLファイルとして格納される)を持つ場合があります。ただし、JMSおよびJDBCモジュールの場合、コンパイル済みJavaコードは含まれません。あらかじめパッケージ化されたこれらのアプリケーションは、WebLogic Server管理者によってWebLogicドメインにデプロイされます。
アプリケーションをデプロイするプロセスによって、アプリケーション・コンポーネントと環境固有のリソース定義がリンクされます。たとえば、特定のアプリケーション・コンポーネントをホストするサーバー・インスタンス(ターゲット指定)や、JMSメッセージを保持するWebLogic永続ストアなどです。
最初のデプロイメントの完了後は、デプロイされたアプリケーションに対する管理者の権限は限定されます。たとえば、管理者はアプリケーションの適切なライフ・サイクルの保持(デプロイ、アンデプロイ、再デプロイ、削除など)とパラメータの調整(クライアントのニーズにあわせてアプリケーションのインスタンス数を増減するなど)しかできません。ライフ・サイクルとチューニング以外の変更は、アプリケーション開発チームによって行われます。
JMS構成リソースとは
宛先および接続ファクトリなどのJMS構成リソースは、モジュール記述子ファイルとしてWebLogicドメインの外に保持されます。これらのファイルは、weblogic-jms.xsd
スキーマに準拠しているXMLドキュメントで定義されます。
JMSモジュールにはJMSサーバーの定義は含まれません。「JMSサーバーの概要」で説明するように、JMSサーバーの定義はWebLogicドメインの構成ファイルに格納されます
JMSリソースは、旧リリースの場合と同様の方法で管理するシステム・モジュールか、またはアプリケーション・モジュールとして作成し、管理します。JMSアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションとともに(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。「JMSモジュールの概要」を参照してください
JMSサーバーの概要
JMSサーバーは、特定のJMSサーバーのターゲットとして指定されたJMSモジュール内の宛先リソースの管理コンテナとして機能する、環境関連の構成エンティティです。
JMSサーバーの最も重要な役割は、JMSサーバーの宛先が受信するすべての永続メッセージに使用される永続ストアに関する情報を管理し、また、JMSサーバーの宛先で作成される恒久サブスクライバの状態を管理することです。また、ターゲット宛先のコンテナとして、JMSサーバーに対して加えられた構成の変更または実行時の変更をすべての宛先に対して有効にできます。
JMSサーバーはドメインのconfig.xml
ファイルに保持され、クラスタ内の様々なWebLogic Serverインスタンスで複数のJMSサーバーを構成できます(独自の名前が付けられている場合に限ります)。クライアント・アプリケーションでは、JNDIツリーまたはjava:/comp/env
ネーミング・コンテキストを使用して接続ファクトリをルックアップし、接続を作成してJMSサーバーとの通信を確立します。各JMSサーバーでは、すべてのターゲット・モジュールの宛先に対するリクエストが処理されます。JMSサーバーによって処理されない宛先に対するリクエストは、適切なサーバー・インスタンスに転送されます。
WebLogic Server 9.x以降でのJMSサーバーの動作
現在のリリースのJMSサーバーでは、JMSサーバーの動作が一部の点で9.xより前のリリースと異なります。
-
宛先リソースはJMSモジュールの中にカプセル化されるので、構成ファイルでJMSサーバーの下にネストされません。しかし、JMSサーバーと宛先の間の下位ターゲット関係も保持されています。これは、JMSモジュール内のスタンドアロンの各宛先リソースが常に単一のJMSサーバーのターゲットになるからです。このように、JMSサーバーは依然として永続メッセージ、恒久サブスクライバ、メッセージ・ページング、およびそのターゲット宛先の割当て(オプション)を管理します。ドメイン内の各JMSサーバーに、複数のJMSモジュールをターゲット指定できます。
-
JMSサーバーは、サーバー・インスタンス内の複数のサブシステムとサービスで使用できるデフォルト永続ストアをサポートします(「永続ストア」を参照)。
-
「デフォルト・ストアを使用する」オプションを有効化することで、JMSサーバーはホスト・サーバーのデフォルト・ファイル・ストア内に永続メッセージを格納できます。旧リリースでは、ストアが構成されていない場合、永続メッセージは非永続メッセージに自動的に格下げされました。ただし、「デフォルト・ストアを使用する」オプションを無効化した場合、永続メッセージは非永続になります。
-
非推奨のJMSストア(JMSファイル・ストアとJMS JDBCストア)にかわって、JMSサーバーはユーザー定義のWebLogicファイル・ストアまたはJDBCストアをサポートします。これらのストアは、従来のJMSストアに比べて高いパフォーマンスと多くの機能を備えています(後方互換性を保持するため、従来のJMSストアもサポートされています)。
-
-
JMSサーバーは、進化したメッセージ・ページング・メカニズムをサポートします。メッセージ・ページングの詳細は、Oracle WebLogic Serverのパフォーマンスのチューニングで、メッセージのページングによるメモリーの解放を参照してください。
-
専用のページング・ストアの構成は不要になりました。ページングされるメッセージは、ユーザーのファイル・システム(ユーザー定義のディレクトリか、それが指定されていない場合はデフォルト・ページング・ディレクトリ)に格納されます。
-
メッセージの一時ページングは常に有効化され、「メッセージ・バッファ・サイズ」オプションの値によって制御されます。待ち状態ではない、ページングされないメッセージの合計サイズがこの値に達した場合、JMSサーバーはメッセージをページング・ディレクトリにページングすることによってメモリー使用量を減らそうとします。
-
-
1つのJMSサーバーによってホストされるすべての宛先でのメッセージの生成および消費処理を休止できます。これは、JMXでプログラムによって行うか、またはWebLogic Server管理コンソールから行います。「宛先でのメッセージ処理の制御」を参照してください
-
JMSサーバーは、WebLogic Serverを再起動せずにアンデプロイおよび再デプロイできます。
-
オフライン状態の共通分散トピック・メンバーにパブリッシュされた非永続メッセージは保存され、メンバーが再びオンラインになると使用可能になります。
9.0より前のリリースでは、JMSサーバーに永続ストアを構成していない場合や、永続ストアは定義されているが分散トピック(DT)メンバーに
storedEnabled=false
が設定されている場合、非永続メッセージは破棄され、DTメンバーが再びオンラインになっても使用可能になりません。アプリケーションがこれらのメッセージの破棄に依存している場合は、サーバーの配信タイムアウト
値を非常に低い値に設定することで、同様の動作を実現できます。これにより、オフラインDTメンバーが再びオンラインになるまでにメッセージを無視できます。WebLogic Serverリリース10.3.4.0以降で開発された新しいアプリケーションの場合、メッセージ・コンシューマとしてメッセージ・ドリブンBean (MDB)を設定し、パーティション化された分散トピックを使用することで、同様の機能を実現できます。『Oracle WebLogic Server JMSアプリケーションの開発』の上級パブリッシュ/サブスクライブ・アプリケーションの開発に関する項を参照してください。
JMSサーバーの構成の詳細は、「JMSサーバーの構成」を参照してください。
JMSモジュールの概要
JMSモジュールは、ドメイン環境から独立したアプリケーション関連の定義です。システム・モジュールまたはアプリケーション・モジュールのいずれかとして、JMSリソースを作成して管理できます。
JMSシステム・モジュールは、通常、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して構成され、ドメインのconfig.xml
ファイル内にそのモジュールへの参照が追加されます。JMSアプリケーション・モジュールは、Java EEモジュールのWebLogic固有の拡張機能であり、Java EEアプリケーションと共に(パッケージ化されたリソースとして)、またはグローバルに使用可能なスタンドアロン・モジュールとしてデプロイできます。
システム・モジュールとアプリケーション・モジュールの主な相違点は所有権です。システム・モジュールはWebLogic管理者によって所有および変更され、すべてのアプリケーションで利用可能です。アプリケーション・モジュールは、このJMSリソース・モジュールをアプリケーションのEARファイルにパッケージ化するWebLogic開発者によって所有および変更されます。
JMSリソースのモジュール形式のデプロイメントでは、エンタープライズ・アプリケーション・ファイル(EARファイルなど)またはスタンドアロンJMSモジュールを開いたり、JMSを手動で広範囲に再構成したりすることなく、アプリケーションと必要なJMS構成を、ある環境から別の環境に(たとえば、テスト環境から本番環境に)移行できます。
以下の節では、様々なタイプのJMSモジュールと、それらのモジュールに含められるリソースについて説明します。
JMSシステム・モジュール
WebLogic管理者は、通常、WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、(ターゲット) JMSモジュールの作成とデプロイ、およびモジュールの構成リソース(キュー、トピック、接続ファクトリなど)の構成を行います。
このように構成するJMSモジュールは、システム・モジュールと見なされます。JMSシステム・モジュールは管理者が所有し、管理者はいつでもリソースを削除、変更、または追加できます。システム・モジュールは、ドメインに構成されたサーバーおよびクラスタのターゲット指定に対して全面的に利用できます。つまり、同じターゲットにデプロイされているすべてのアプリケーションおよびクライアント・アプリケーションで利用できます。
JMSシステム・モジュールを作成する場合、ドメイン・ディレクトリのconfig\jms
サブディレクトリにJMSモジュール・ファイルが作成され、ドメインのconfig.xml
ファイルにJMSSystemResource
要素としてそのモジュールへの参照が追加されます。この参照には、JMSシステム・モジュール・ファイルへのパス、およびこのモジュールがデプロイされるサーバーとクラスタのリストが含まれます。
JMSモジュールは、weblogic-jms.xsd
スキーマに準拠します(「JMSスキーマ」を参照)。システム・モジュールは、WebLogic Management Extension (JMX)ユーティリティからもJMSSystemResourceMBeanとしてアクセス可能です。JMSシステム・モジュールのネーミング・ルールは、MyJMSModule
-jms.xml
です。
図2-2に、ドメインのconfig.xml
ファイルに記述されるJMSシステム・モジュールと、対応するconfig\jms
ディレクトリ内のモジュールの例を示します。
JMSシステム・モジュールの構成の詳細は、「基本JMSシステム・リソースの構成」を参照してください
JMSアプリケーション・モジュール(非推奨)
JMS構成リソースは、標準のJava EE記述子ベースのモジュールと同様に、デプロイ可能なアプリケーション・モジュールとしても管理できます。JMSアプリケーション・モジュールは、Java EEアプリケーションと共にパッケージ化されたモジュールとして(この場合、モジュール内のリソースは同梱されたアプリケーションでのみ利用可能(アプリケーション・スコープなど))、またはそのモジュール内のリソースへのグローバル・アクセスを提供するスタンドアロン・モジュールとしてデプロイできます。
通常、アプリケーション開発者が、エンタープライズ・レベルのIDEまたはXML記述子ファイルの編集に対応した開発ツールでアプリケーション・モジュールを作成し、それらのJMSモジュールをアプリケーションの一部としてパッケージ化して、デプロイ、管理、およびチューニングのためにアプリケーションをWebLogic管理者に渡します。
「ドメインの構成」で説明されているように、JMSアプリケーション・モジュールにはコンパイル済のJavaプログラムがパッケージの一部として含まれていないので、管理者またはアプリケーション開発者は必要に応じてJMSリソースを作成および管理できます。
JMSアプリケーション・モジュールの構成の詳細は、JMSアプリケーション・モジュールのデプロイメントの構成を参照してください。
ノート:
WebLogic JMSアプリケーション・モジュールのデプロイメントは、パッケージ化されたモジュールとスタンドアロン・モジュールも含めて非推奨になりました。JMSアプリケーション・モジュールのサポートは、今後のリリースではなくなります。必須のJMS構成は、システム・モジュールを使用して作成することをお薦めします。
JMSシステム・モジュールとアプリケーション・モジュールを比較する
WebLogic JMS構成および管理を理解する上でキーとなるのは、JMSリソースの作成者およびJMSリソースの作成方法が、リソースのデプロイと変更の方法を決定するという点にあります。JMSモジュールは、WebLogicの管理者とプログラマが構成できます。
システム・モジュールとは対照的に、デプロイされたアプリケーション・モジュールの所有者は、モジュールをデプロイした管理者ではなく、モジュールを作成およびパッケージ化した開発者となります。したがって、デプロイしたリソースに対しては、管理者の制御が及ぶ範囲がより制限されます。アプリケーション・モジュールをデプロイする場合、管理者はモジュールで指定されたリソース・プロパティの変更はできますが、リソースの追加や削除はできません。他のJava EEモジュールのように、アプリケーション・モジュールのデプロイメント構成の変更はモジュールのデプロイメント・プランに格納され、元のモジュール自体は変更されません。
表2-1に、JMSモジュールの種類と、それらがどのように構成および変更されるかを示します。
表2-1 JMSモジュール・タイプと構成および管理オプション
モジュールの種類 | 作成に使用するツール | モジュールの動的追加/削除 | JMXでのリモート変更 | デプロイメント・チューニング・プランによる変更(非リモート) | 管理コンソールによる変更 | スコープ指定 | デフォルト・サブ・モジュール・ターゲット指定 |
---|---|---|---|---|---|---|---|
システム |
管理コンソールまたはWLST |
はい |
はい |
いいえ |
はい。JMXを使用 |
グローバルおよびローカル |
いいえ |
アプリケーション |
IDEまたはXMLエディタ |
いいえ。再デプロイが必要 |
いいえ |
はい。デプロイメント計画を使用 |
はい。デプロイメント計画を使用 |
グローバル、ローカル、およびアプリケーション |
はい |
JMSアプリケーション・モジュールのデプロイメントの準備については、JMSアプリケーション・モジュールのデプロイメントの構成とOracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。
モジュールに構成できるJMSリソース
システム・モジュールまたはアプリケーション・モジュールの一部として、以下の基本構成リソースが定義されます。
-
キューおよびトピック宛先。「キューおよびトピック宛先の構成」を参照。
-
接続ファクトリ。「接続ファクトリの構成」を参照。
-
テンプレート。「JMSテンプレートの構成」を参照。
-
宛先キー。「宛先キーの構成」を参照。
-
割当て。「割当ての構成」を参照。
-
分散宛先。「分散宛先リソースの構成」を参照。
-
外部サーバー。「外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成」を参照。
-
JMSストア・アンド・フォワード(SAF)構成項目。「JMSストア・アンド・フォワード(SAF)」を参照してください。
これ以外のすべてのJMS環境関連リソースは、ドメイン構成リソースとして管理者が構成する必要があります。これには、以下のものが含まれます。
-
JMSサーバー(必須)。「JMSサーバーの概要」を参照してください
-
ストア・アンド・フォワード・エージェント(オプション)。「JMSストア・アンド・フォワード(SAF)」を参照してください。
-
パス・サービス(オプション)。「パス・サービス」を参照してください
-
メッセージング・ブリッジ(オプション)。「メッセージング・ブリッジ」を参照してください
-
永続ストア(オプション)。「永続ストア」を参照してください
JMSシステム・モジュールの構成の詳細は、「基本JMSシステム・リソースの構成」を参照してください
JMSスキーマ
JMSリソースのモジュラ構成モデルのサポートとして、WebLogic JMSオブジェクトのスキーマ、weblogic-jms.xsd
が用意されています。JMSリソース・モジュール(記述子)を作成する際は、モジュールをこのスキーマに準拠させる必要があります。IDEや他のツールでは、このスキーマに基づいてJMSリソース・モジュールを検証できます。
weblogic-jms.xsd
スキーマは、http://xmlns.oracle.com/weblogic/weblogic-jms/1.4/weblogic-jms.xsd
からオンラインで入手できます。
JMS相互運用モジュール(非推奨)
ノート:
JMS相互運用モジュールは、WebLogic Server 12.1.1では非推奨です。config.xml
にinterop-jms.xml
という名前のモジュールがある場合は、標準のシステム・モジュールに変換してください。「JMSシステム・モジュールの構成」を参照してください
JMS Interopモジュールは、特殊なタイプのJMSシステム・リソース・モジュールです。このモジュールは、このリリースのためのJMS構成アップグレードの結果として、および旧リリースからWebLogic JMX MBean APIを使用することによって作成および管理されます。
JMS Interopモジュールは、以下に示すように、JMSシステム・リソース・モジュールとは様々な点で異なります。
-
JMSモジュール記述子の名前は常に
interop-jms.xml
です。このファイルはドメインのconfig\jms
ディレクトリにあります。 -
他のJMSシステム・リソース・モジュールの所有者が主に管理者であるのに対し、Interopモジュールはシステムによって所有されます。
-
Interopモジュールは、ドメインのどこでもターゲット指定されます。
-
JMS Interopモジュールに存在するJMSリソースは、非推奨のJMX (MBean) APIを使用してアクセスおよび管理できます。
-
JMS InteropモジュールのMBeanは
JMSInteropModuleMBean
です。これはDomainMBean
の子MBeanであり、ドメイン内の他の子MBeanと同様にDomainMBean
からルックアップできます。
JMS Interopモジュールには、メッセージ順序単位や宛先割当てなどの、WebLogic Server 9.x以降の機能の多くも実装できます。ただし、WebLogic Server 9.x以降の機能のうち次の機能は実装できません。
-
共通分散宛先リソース
-
JMSストア・アンド・フォワード・リソース
ノート:
JMS Interopモジュールで現在のリリースの新しい機能を使用すると、WebLogic Server 9.xより前のバージョンのJMXクライアントとの互換性が損なわれる場合があります。
WebLogic JMSの他の環境関連システム・リソース
JMSサーバーおよびシステム・モジュールに加えて、管理者は次のアーティファクトのいずれかを構成する必要がある場合があります。
永続ストア
WebLogic永続ストアは、永続性を必要とするすべてのサブシステムとサービスに対し、組込みの高性能なストレージの仕組みを提供します。たとえば、永続JMSメッセージを格納したり、ストア・アンド・フォワード機能を使用して、メッセージを一時的に格納してから送信したりできます。ドメインの各WebLogic Serverインスタンスには、構成が不要で、システムのデフォルト・ストレージを使用する複数のサブシステムで同時に使用できるデフォルトの永続ストアがあります。なお、JMS実装に合せて専用のファイル・ベース・ストアまたはJDBCデータベース対応ストアを作成することもできます。JMSの永続ストアの構成の詳細は、Oracle WebLogic Serverサーバー環境の管理のWebLogic永続ストアの使用方法を参照してください。
JMSストア・アンド・フォワード
SAFサービスを使用すると、複数のWebLogic Serverインスタンスに分散されているアプリケーション間でメッセージを確実に配信できます。たとえば、SAFサービスを利用すると、ローカルのWebLogic Serverインスタンス上で動作するアプリケーション、またはローカルのWebLogic Serverインスタンスに接続するアプリケーションは、リモート・サーバー上の宛先にメッセージを確実に配信できます。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。
JMSモジュールはSAFサービスを使用して、ローカルのJMSメッセージ・プロデューサがリモートのJMSキューまたはトピックにメッセージを確実に送信できるようにします。Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理のJMSメッセージに対するSAFの構成を参照してください。
パス・サービス
WebLogic Serverパス・サービスは、分散キュー・メンバーまたはストア・アンド・フォワード・パスにメッセージを固定することによってメッセージ・グループとメッセージング・リソースの間のマッピングを格納するための永続マップです。パス・サービスの構成の詳細は、「WebLogicパス・サービスの使用」を参照してください。
メッセージング・ブリッジ
メッセージング・ブリッジを使用すると、2つのメッセージング製品間の転送メカニズムを構成することで、WebLogic JMSの異なる実装間、またはWebLogic JMSと別のメッセージング製品間の相互運用性を実現できます。メッセージング・ブリッジ・インスタンスと、ブリッジのソースおよびターゲット宛先インスタンスは、ドメインのconfig.xml
ファイルに保持されます。Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理のメッセージング・ブリッジの理解を参照してください。