| Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース1 (11.1.1.7) B61432-07 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース1 (11.1.1.7) B61432-07 |
|
前 |
次 |
この章では、クラスタ環境でOracle Service Busをデプロイするための構成に必要な作業について説明します。
クラスタ・ドメインのアーキテクチャを、3.2項「クラスタ・デプロイメントの設計」の説明に従ってプランニングしたら、Oracle Service Busをクラスタ環境に設定できます。そのためには、管理サーバーと管理対象サーバーを構成し、Oracle Service Busリソースをサーバーにデプロイする必要があります。インバウンドHTTPロード・バランシング機能が必要な場合は、ルーター(ハードウェアまたはソフトウェア)も必要です。Oracle WebLogic Serverインスタンスとクラスタのドメインの永続構成は、Oracle Service Busドメインのルート・ディレクトリのconfigディレクトリにあるXML構成ファイル(config.xml)に格納されます。
クラスタ・ドメインでOracle Service Busを設定およびデプロイするには、次の手順を実行します:
Oracle Service Busの非クラスタ環境へのデプロイについては、第2章「非クラスタ・デプロイメントの構成」を参照してください。
この項では、クラスタ環境で実行されるOracle Service Busを構成するための次の前提条件について説明します。
そのクラスタで使用する管理サーバーのIPアドレスを取得します。
1つのクラスタ内のすべてのOracle WebLogic Serverインスタンスは、構成およびモニターに同じ管理サーバーを使用します。サーバーをクラスタに追加する場合、各サーバーが使用する管理サーバーを指定する必要があります。
各クラスタにマルチキャスト・アドレスを割り当てます。
|
注意: Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成時に、マルチキャスト・アドレスの割当てが要求されます(4.2項「手順2. Oracle Service Busドメインの準備」を参照してください) マルチキャスト・アドレスは、クラスタ・メンバー間の通信に使用されます。クラスタリングされたサーバーは、1つの専用マルチキャスト・アドレスを共有する必要があります。ネットワーク上の各クラスタに対して、一意のマルチキャスト・アドレスとポート番号の組合せを割り当てる必要があります。ネットワーク上の2つのクラスタが同じマルチキャスト・アドレスを使用する場合、異なるポートを使用する必要があります。クラスタのマルチキャスト・アドレスが異なる場合は、同じポートを使用するか、またはデフォルトのポート( |
クラスタ内のサーバーのIPアドレスを定義します。アドレス定義には、次のように、いくつかの方法があります。
|
注意: Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成時に、サーバーのリスニング・アドレスの割当てが要求されます(4.2項「手順2. Oracle Service Busドメインの準備」を参照してください) |
クラスタ内のサーバーに対して1つのIPアドレスと異なるリスニング・ポート番号を割り当てる方法。
1つのIPアドレスとサーバーごとに異なるポート番号をクラスタ・サーバーに割り当てることにより、1つのマシンに、そのマシンをマルチ・ホーム・サーバー化することなくクラスタ環境を設定できます。
クライアントからこのようなIPアドレスにアクセスできるようにするには、次のいずれかの方法で、IPアドレスとポート番号でURLを構成します。
ipAddress:portNumber-portNumber - ポート番号が連番になっている場合。例:
127.0.0.1:7003-7005
ipAddress:portNumber+...+portNumber - ポート番号が連番ではない場合。例:
127.0.0.1:7003+7006+7008
ipAddress:portNumber,ipAddress:portNumber,... - 冗長で明示的な指定。例:
127.0.0.1:7003,127.0.0.1:7004,127.0.0.1:7005
クラスタ内の各マシン上で起動するOracle WebLogic Serverインスタンスごとに静的IPアドレスを割り当てる方法。
この方法では、複数のサーバーが1つのマシン上で実行されている場合、そのマシンはマルチ・ホーム・サーバーとして構成する必要があります。つまり、複数のIPアドレスが1つのコンピュータに割り当てられます。この場合は、クラスタ・アドレスをカンマ区切りのIPアドレスのリストの形にします。
たとえば、次のリストは、config.xmlファイルで指定されているクラスタ・アドレスの例です。MyClusterという名前のクラスタ内の、4つのサーバーのそれぞれに対して、静的IPアドレスが指定されています。
<Cluster ClusterAddress="127.0.0.1:7001,127.0.0.2:7001,127.0.0.3,127.0.0.4:7001" Name="MyCluster"/>
またDNSを使用してもサーバーを指定できます。
アドレス指定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』の「WebLogicクラスタの設定」にあるリスニング・アドレスの問題の回避に関する項を参照してください。
|
注意: テスト環境では、1台のマシンに複数のOracle WebLogic Serverインスタンスを割り当てることもできます。この場合、一部のOracle WebLogic Serverインスタンスを同一ノード上に異なるポート番号で配置し、他のOracle WebLogic Serverインスタンスを別の複数のノードに同一のポート番号で配置することができます。 |
クラスタ・ドメイン用の次のいずれかのデータベースを構成します。
Microsoft SQL Server
Oracle
|
注意: Oracle WebLogic ServerとともにインストールされるApache Derbyデータベースのローカル・コピーは、評価のみを目的としています。 |
データベースを本番用に適切に構成することが重要です。データおよびログ・メッセージを格納するための十分な領域を用意し、データベース管理のベスト・プラクティスに従う必要があります。
|
注意: 同時アクセス機能を使用するようにデータベースを構成できます。 |
特定のデータベースに関する最新情報については、製品のリリース・ノートを参照してください。
共用ファイル・システムを組み込みます。共用ファイル・システムは、高可用性が求められるあらゆるクラスタに不可欠です。ストレージ・エリア・ネットワーク(Storage Area Network : SAN)またはマルチ・ポート型のディスク・システムをお薦めします。
高可用性クラスタの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』にある「高度なJMSシステム・リソースの構成」のWebLogic JMSクラスタリングの構成に関する項を参照してください。
システム用のルーター(ハードウェアまたはソフトウェア)を構成します。ロード・バランシングは、組込みロード・バランシング機能かWebLogicプロキシ・プラグインのいずれか、または別個のロード・バランシング用ハードウェアを使用して実現されます。
ハードウェアおよびソフトウェア・ルーターについては、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』を参照してください。
|
注意: 1つまたは複数のファイアウォールを含めるようにドメインを設計する場合は、この他にも要件があります。ドメイン構成ファイルへのファイアウォール情報の追加方法については、4.2.1.1項「ドメイン構成へのプロキシ・サーバーまたはファイアウォール情報の追加」を参照してください。追加情報については、『Oracle Fusion Middleware Oracle WebLogic Serverのクラスタの使用』の「クラスタでの通信」を参照してください。 |
Oracle Service Busでは、クラスタの管理対象サーバー間でファイル、電子メール、およびFTPトランスポート処理のロード・バランシングを行います。クラスタのすべての管理対象サーバーが、ファイル、電子メール、FTPの各プロキシ・サービス構成で指定されたアーカイブ、ステージ、エラーの各ディレクトリにアクセスできるようにします。これらのディレクトリは、NFSなどの共有ファイル・システムに構成します。共有ファイル・システムを使用することで、ユーザーとプログラムはリモート・システムにあるファイルにローカル・ファイルと同じようにアクセスできます。
クラスタリングされたOracle WebLogic Serverインスタンスの設定の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使用』のWebLogicクラスタの設定に関する項を参照してください。
Oracle Service Busドメインを準備する際には、各管理対象サーバーの定義をドメイン構成ファイル(config.xml)に追加し、すべての管理対象サーバーをクラスタに割り当て、Oracle Service Busコンポーネントをドメイン上のサーバーに指定する必要があります。
クラスタリング・ドメインでOracle Service Bus環境を準備するには、次の項で説明する作業を行う必要があります。
Oracle Fusion Middleware構成ウィザードによるOracle Service Busドメインの作成の詳細は、Oracle Fusion Middleware Oracle Service Busインストレーション・ガイドの「Oracle Service Bus 11gのインストールと構成」を参照してください。
|
注意: Oracle Service Busを含めるために既存のWebLogic Serverのクラスタリングされたドメインを拡張する場合、新しい管理対象サーバー(osb_server1)を削除しないようにしてください。クラスタに新しいサーバーを追加する必要はありますが、起動する必要はありません。これにより、Service Busの構成がクラスタ内の既存の管理対象サーバーに伝播されることが保証されます。 ドメインおよびクラスタが拡張された後はosb_server1を削除できますが、ドメインを拡張している最中は削除しないようにしてください。 |
プロキシ・サーバーまたはファイアウォールの背後でWebサービスを使用する場合は、config.xmlファイルを編集して、そのプロキシ・サーバーまたはファイアウォールに関する情報を追加する必要があります。
プロキシ・サーバーまたはファイアウォールの情報をドメイン構成に追加するには、次の手順を実行します:
テキスト・エディタでconfig.xmlを開きます。
config.xmlファイルで、次のタグで始まる行を検索します。
<Cluster
次の3つの属性をCluster属性リストに追加します。
FrontendHTTPPort="proxyPort" FrontendHTTPSPort="proxySSLPort" FrontendHost="proxyServerHost"
たとえば、次のリストは、config.xmlファイルで指定されているクラスタ・アドレスとファイアウォールの例です。クラスタ名はMyCluster、プロキシ・サーバー名はMyProxyです。
<Cluster ClusterAddress="127.0.0.1:7001,127.0.0.2:7001,127.0.0.3,127.0.0.4:7001" FrontendHTTPPort="7006" FrontendHTTPSPort="7007" FrontendHost="MyProxy" MulticastAddress="127.0.0.5" MulticastPort="7010" Name="MyCluster"/>
変更内容を保存し、config.xmlファイルを閉じます。
Oracle Fusion Middleware構成ウィザードでJMSファイル・ストアを構成するとともに、JMSを使用するプロキシ・サービスおよびビジネス・サービスに、次のリソースを構成する必要があります。
JMSキューまたはトピック。Oracle Service Busでは、JMSを使用して実装されたプロキシ・サービスに自動的にJMSキューが構成されます。JMSを使用するすべてのビジネス・サービスおよび非JMSを使用して実装されたプロキシ・サービスには、JMSキューまたはトピックを構成する必要があります。
プロキシ・サービスでは、異なるドメインのリモート・キューからのメッセージを消費できます。この場合、Oracle Serviceでは自動的にキューが作成されません。プロキシ・サービス用のJMSキューを作成できるのは、キューが同じローカルOracle Service Busドメインにある場合に限ります。
JMS接続ファクトリ。JMSを使用して実装されたすべてのビジネス・サービスとプロキシ・サービスにJMS接続ファクトリを構成する必要があります。
JMSリソースの構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』の高度なJMSシステム・リソースの構成に関する項を参照してください。
Oracle Service Busでは、Oracle WebLogic Serverのセキュリティ機能を利用して、メッセージの機密性と整合性を確保し(メッセージ・レベルのセキュリティ)、クライアントとOracle WebLogic Serverの間の接続を保護し(トランスポート・レベルのセキュリティ)、認証と認可(アクセス制御)を行います。必要な作業については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。
|
注意: 各Oracle Service Busドメインに別々にセキュリティを構成する必要があります。Oracle Service Busでは、セキュリティ構成のエクスポートおよびインポートは行いません。 |
クラスタにSSLを構成するには、ドメインの作成時に行うか、またはOracle WebLogic Server管理コンソールを使用します。セキュリティ機能がマルチ・ノード・クラスタにデプロイされているドメインの場合は、クラスタ内の各マシンに対して、キーストア、サーバー証明書、秘密鍵なども構成する必要があります。各マシンに独立したキーストアを使用するか、すべてのマシンで利用可能な場合は単一のキーストアを使用します。
この項では、クラスタ・ドメインの管理対象サーバーに対する基本管理タスクについて説明します。
ノード・マネージャは、Oracle WebLogic Serverインスタンスの起動、停止、および移行に使用できるユーティリティです。Oracle WebLogic Server管理コンソールとともにノード・マネージャを使用して管理対象サーバーを起動するか、または、WLSTスクリプトを作成してノード・マネージャの機能を自動化できます。
|
ヒント: 起動されたサーバーでOracle Service Busクラスが使用できるように、 |
デフォルトでは、Oracle Fusion Middleware構成ウィザードでOracle Service Busクラスタ・ドメインが生成されるときに、次の処理が行われます。
ドメイン・シングルトン・マーカー・アプリケーション(domainsingletonmarker.ear)がクラスタの最初の管理対象サーバーに割り当てられます。データ集約を正しく実行するには、domainsingletonmarker.earが指定されたサーバーを最初に起動し、他の管理対象サーバーが起動するときに使用できるようにする必要があります。
PurgingMDB(msgpurger.ear)がクラスタの最初の管理対象サーバーに割り当てられます。メッセージ・パージを正しく実行するには、msgpurger.earが指定されたサーバーが使用可能であることが必要です。
ノード・マネージャの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverノード・マネージャ管理者ガイド』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。管理対象サーバーの起動方法と停止方法の概要については、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』の「サーバーの起動と停止」を参照してください。
起動が完了したら、Oracle Service Bus管理コンソールを使用してサーバーのステータスを確認できます。Oracle Service Bus管理コンソールを使用したサーバーの監視については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の「監視」で、サーバーの表示および配置に関する説明を参照してください。
クラスタ環境にOracle Service Bus構成をデプロイするときは、非クラスタ・デプロイメントと同じ手順に従います。デプロイメント手順については、2.4項「手順4. Oracle Service Bus構成のデプロイ」を参照してください。
|
注意: 非クラスタ環境から構成をインポートし、その構成にファイル、FTP、または電子メール・トランスポートを使用するプロキシ・サービスが含まれている場合、それらの各プロキシ・サービスに管理対象サーバーを指定する必要があります。管理対象サーバーのリストは、Oracle Service Busクラスタ・ドメイン内のOracle Service Bus管理コンソールのみに表示されます。 |
本番環境は、時間の経過や、アプリケーション使用の増加に伴って変化します。この項では、一般的な本番環境の変化に応じてドメインを更新する方法を説明します。
Oracle Service Busの使用が増加するに従って、Oracle Service Busクラスタに新しい管理対象サーバーを追加して容量を増やすことができます。詳細な手順は、『Oracle Fusion Middleware高可用性ガイド』のトポロジのスケール変更に関する項を参照してください。
トポロジをスケール変更した後で、次のトピックの指示に従い、ビジネスおよびプロキシ・サービスを更新します。
Oracle Service Bus構成に、JMSリクエスト/レスポンス機能を使用する1つまたは複数のビジネス・サービスがある場合、新しい管理対象サーバーをクラスタに追加した後、Oracle Service Bus管理コンソールを使用して次の手順も実行する必要があります。
「チェンジ・センター」で「作成」をクリックし、セッションを作成します。
「プロジェクト・エクスプローラ」を使用し、JMSリクエスト/レスポンスを使用するビジネス・サービスを検索して選択します。この種類のビジネス・サービスの「サービスの種類」には、「メッセージング・サービス」と表示されています。
「詳細の表示」ページの一番下で「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスがある場合、クラスタ・アドレスに新しいサーバーを追加します。
「ビジネス・サービスの編集 - サマリー」ページで「保存」をクリックします。
JMSリクエスト/レスポンスを使用する残りの各ビジネス・サービスに対して、前の手順を繰り返します。
チェンジ・センターで「アクティブ化」をクリックします。
ビジネス・サービスは拡張したドメインでの処理用に構成されました。
|
注意: ビジネス・サービスでJMS MessageID相関スキームを使用している場合、接続ファクトリ設定を編集して、管理対象サーバーをキューにマッピングする表にエントリを追加する必要があります。キューとトピックの宛先を構成する方法については、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』のJMSサーバーのターゲット指定に関する項を参照してください。 |
Oracle Service Bus構成に、クラスタ・アドレスを持つJMSエンドポイントを使用する1つまたは複数のプロキシ・サービスがある場合、新しい管理対象サーバーをクラスタに追加した後、Oracle Service Bus管理コンソールを使用して次の手順も実行する必要があります。
「チェンジ・センター」で「作成」をクリックし、セッションを作成します。
「プロジェクト・エクスプローラ」を使用し、クラスタ・アドレスを持つJMSエンドポイントを使用するプロキシ・サービスを検索して選択します。
「詳細の表示」ページの一番下で「編集」をクリックします。
エンドポイントURIにクラスタ・アドレスがある場合、クラスタ・アドレスに新しいサーバーを追加します。
「プロキシ・サービスの編集 - サマリー」ページで「保存」をクリックします。
クラスタ・アドレスを持つJMSエンドポイントを使用する残りの各プロキシ・サービスに対して、前の手順を繰り返します。
チェンジ・センターで「アクティブ化」をクリックします。
プロキシ・サービスは拡張されたドメインでの処理用に構成されました。
Oracle WebLogic Server管理ツールを使用して、Oracle Service Busクラスタから管理対象サーバーを削除できます。管理対象サーバーの削除を決定する前に、次のことを考慮する必要があります。
Oracle Service Bus構成に、クラスタから削除する管理対象サーバーにトランスポート・ポーラーを固定しているファイル、FTPまたは電子メール・トランスポートを使用するプロキシ・サービスがある場合、クラスタから管理対象サーバーを削除する前に、これらの各プロキシ・サービスに異なる管理対象サーバーを選択する必要があります。
ドメイン・シングルトン・マーカー・アプリケーションをホストする管理対象サーバーはクラスタから削除してはなりません。ドメイン・シングルトン・マーカー・アプリケーションをホストする管理対象サーバーに障害が発生した場合、手動で移行を行う必要があります。
メッセージ・レポーティング・パージャー・アプリケーションをホストする管理対象サーバーを削除する場合は、メッセージ・レポーティング・パージャーと関連するキュー(wli.reporting.purge.queue)のために別のマネージャ・サーバーを選択する必要があります。
次の手順では、管理対象サーバーに関連付けられているリソースを削除し、最終的に管理対象サーバー自体を削除します。影響を受けるリソースのほとんどは名前が_auto_xで終わり、xは削除する管理対象サーバーの番号を表します。たとえば、管理対象サーバー2のJMSレポート・プロバイダ・キューはwli.reporting.jmsprovider.queue_auto_2と呼ばれます。
|
注意: Oracle WebLogic Serverコンソールには、デフォルトでリソースの部分的なリストのみ表示されます。リソースの完全なリストを表示するには、「この表のカスタマイズ」をクリックし、「1ページごとの表示行数」の値を増やします。 |
クラスタから管理対象サーバーを削除する手順:
この項で説明した考慮事項を読んだ後で、クラスタ内のすべての管理対象サーバーを停止します。管理サーバーは実行したままにします。
Oracle WebLogic Serverコンソールにログインし、「チェンジ・センター」の「ロックして編集」をクリックします。
分散キューからすべての*_auto_xキュー・メンバーを削除します。
「ドメイン構造」ペインで、「サービス」→「メッセージング」→「JMSモジュール」を選択してJMSモジュールのリストを表示します。
「jmsResources」モジュールをクリックします。名前がdist_で始まる分散キューのリストが表示されます。たとえば、dist_QueueIn_autoなどです。
分散キューをクリックし、その「メンバー」タブに移動します。管理対象サーバーのキューを削除します。たとえば、管理対象サーバー2を削除している場合は、dist_QueueIn_auto分散キューからQueueIn_auto_2を削除します。
各分散キューについてこれらの手順を繰り返し、削除している管理対象サーバーの関連*_auto_xリソースを削除します。
すべての*_auto_xキューを削除します。
jmsResourcesモジュールのリソースのリストで、削除している管理対象サーバーのキューのうち、名前が*_auto_xで終わるキューをすべて削除します。たとえば、管理対象サーバー2を削除している場合は、wli.reporting.jmsprovider.queue_auto_2を削除します。
削除している管理対象サーバーの「サービス」→「メッセージング」→「JMSモジュール」→「WseeJmsModule」からすべての*_auto_xキューを削除します。たとえば、管理対象サーバー2を削除している場合は、DefaultCallbackQueue-WseeJmsServer_auto_2とDefaultQueue-WseeJmsServer_auto_2を削除します。
削除している管理対象サーバーのすべてのJMSサブデプロイメントを削除します。
「サービス」→「メッセージング」→「JMSモジュール」を選択します。
「configwiz-jms」モジュールをクリックし、「サブデプロイメント」タブをクリックします。
「ターゲット」列の*_auto_xターゲットに注目します。削除している管理対象サーバーの*_auto_xをターゲットとしているすべてのサブデプロイメントを削除します。
前の手順と同様に、削除している管理対象サーバーのjmsResourcesおよびWseeJmsModuleモジュールからすべての*_auto_xサブデプロイメントを削除します。
削除している管理対象サーバーをターゲットとしているすべてのJMSサーバーを削除します。
「サービス」→「メッセージング」→「JMSサーバー」を選択します。
削除している管理対象サーバーのすべての*_auto_x JMSサーバーを削除します。
削除している管理対象サーバーをターゲットとしているすべてのストア・アンド・フォワード・エージェントを削除します。
「サービス」→「メッセージング」→「ストア・アンド・フォワード・エージェント」を選択します。
削除している管理対象サーバーのすべての*_auto_xストア・アンド・フォワード・エージェントを削除します。
削除している管理対象サーバーをターゲットとしているすべての永続ストアを削除します。
「サービス」→「永続ストア」を選択します。
削除している管理対象サーバーのすべての*_auto_x永続ストアを削除します。
削除している管理対象サーバーのすべての移行可能なターゲットを削除します。
「環境」→「移行可能なターゲット」を選択します。
削除している管理対象サーバーのserver_name(移行可能)を削除します。たとえば、削除している管理対象サーバーの名前がosb_server2の場合は、osb_server2(移行可能)を削除します。
ALSBフレームワーク・スターター・アプリケーションから管理対象サーバーをターゲット解除します。
「ドメイン構造」ペインで、「デプロイメント」をクリックします。
「ALSBフレームワーク・スターター・アプリケーション」をクリックし、「ターゲット」タブをクリックします。
「ALSBフレームワーク・スターター・アプリケーション」チェック・ボックスを選択し、「ターゲットの変更」をクリックします。
デプロイメント・ターゲットとしての管理対象サーバーを削除します。
|
注意: 「クラスタのすべてのサーバー」ターゲット・オプションが選択されている場合は、管理対象サーバーのターゲットを解除する必要はありません。 |
クラスタから管理対象サーバーを削除します。
「環境」→「クラスタ」を選択し、クラスタの名前をクリックします。
「サーバー」タブをクリックし、クラスタから管理対象サーバーを削除します。
クラスタの「構成」→「一般」タブに移動します。
「クラスタ・アドレス」フィールドで、クラスタ・アドレスから管理対象サーバーを削除します。
「クラスタ・アドレス内のサーバー数」フィールドで、サーバーの数を1つ減らします。
管理対象サーバーを削除します。手順については、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの削除に関する項を参照してください。
残りの管理対象サーバーを再起動します。
ビジネス・サービスを変更する手順は、非クラスタ環境でもクラスタ環境でも同じです。ビジネス・サービスの変更方法については、2.5.1項「ビジネス・サービスの変更」を参照してください。
しかし、クラスタのビジネス・サービスへの変更をデプロイする手順は、ビジネス・サービスに行った変更の種類および同時にデプロイする他の変更の性質によって異なります。詳細は、次の項のインストール戦略に関する説明を参照してください。
ビジネス要件の変化に伴い、プロキシ・サービスの変更が必要になることがあります。このような変更はオンラインで動的に行うことも、部分的または完全にオフラインで行うこともできます。変更に後方互換性がある(つまり、インタフェースは変更しない)場合、Oracle Service Bus管理コンソールを使用してオンラインで動的に変更できます。他の種類の変更は、部分的または完全にオフラインで行う必要があり、システム管理の追加手順が必要です。
オンライン更新の実行については、2.5.3項「構成のオンライン更新」を参照してください。
プロキシ・サービス・インタフェースへの後方互換性がない変更を含む変更を行うには、完全なオフライン・デプロイメントが必要です。新しいバージョンをインストールするには、すべてのサーバーが作動中に次の手順を実行します。
すべてのインバウンド・メッセージを休止します。
非同期にバックログされたすべてのメッセージが処理されたことを確認します。
プロキシ・サービスで必要な変更を行い、テストして、プロキシ・サービスが要求どおり動作することを確認します。
インバウンド・メッセージの受信を再開します。
後方互換性とインストール戦略の詳細は、2.5.2項「新しいバージョンのプロキシ・サービスのインストール」を参照してください。
