| 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をデプロイする際に使用できるベスト・プラクティスと手順について説明します。このドキュメントは、デプロイメント用に自動化スクリプトやプログラムを記述する開発者ではなく、デプロイメントやトポロジをプランニングするデプロイ担当者または管理者を対象としています。
詳細は、付録A「デプロイメントAPIの使用」を参照してください。開発者がスクリプトまたはプログラムを記述する場合は、Oracle Fusion Middleware Oracle Service BusのJava APIリファレンスを参照してください。
この章では、次の項について説明します。
次の項では、一般的なデプロイメント・トポロジについて説明します。
本番システムには、複数の開発システムが存在することがあります。たとえば、エンタープライズESB本番システムの各部門がそれぞれ別個のプロジェクトを持ち、そのプロジェクト・チーム用の開発システムがある場合などです。一般に、開発システムにはQAシステムが関連付けられています。2つのシステムの関係は、1対1です。
一般に、ステージ・システムは本番システムに関連付けられています。2つのシステムの関係は、1対1です。ステージ・システムはできるだけ本番システムを反映するようになっています。通常、開発システム(またはQAシステム)と本番システム(またはステージ・システム)の関係は多対1です。
より複雑なデプロイメント・トポロジでは(大規模組織で部門ごとに開発システムがある)、スキーマ、変換、共有サービスなどの全社的な標準を共有プロジェクトに入れることができます。このシナリオに対処するには、共有プロジェクト用の別個の開発システムを作成し、各部門の開発システムに共有プロジェクトの読取り専用コピーを用意します。共有リソースが変更された場合、必要なリソースをインポートおよびエクスポートすることで、すべての部門システムが更新されます。
リソースをステージ・システムまたは本番システムにデプロイする際は、デプロイメントの失敗を招く可能性のあるセマンティク・エラーを回避するために、共有プロジェクトとともに、影響を受けるすべての部門プロジェクトをデプロイする必要があります。
時として、共有プロジェクトが複数の本番システムで共有されていることがあります。各部門に別個の本番システムがあり、それが企業のESBネットワークに相互接続されていて、スキーマなどの全社的なアセットがすべての本番システムで共有されている場合などです。
デプロイメントの標準的な単位は、プロジェクトと呼ばれます。プロジェクト・デプロイメントには2つのタイプがあります。
完全 - プロジェクト全体がデプロイされます。
増分 - 最後のデプロイメント以降のプロジェクトへの変更、または明示的に選択されたリソースのサブセットのみがデプロイされます。
増分デプロイメントは付加的なデプロイメントで、新規リソースおよび更新されたリソースのみがターゲット・システムにデプロイされます。プロジェクトで削除されたリソースは、ターゲット・システムからは削除されません。ただし、完全プロジェクト・デプロイメント時に削除されたプロジェクト・リソースは、ターゲット・システムからも削除されます。
|
注意: この動作は、インポート時にカスタマイズできます。たとえば、アラート宛先は本番システムで本番システム・オペレータによって定義されますが、開発システムにはこれらのアラート宛先が存在しません。このため、プロジェクトの完全デプロイメントを行う際に、アラート宛先を削除する必要がありません。 |
このドキュメントでは、主として、基本的なデプロイメント・タイプについて説明します。共有プロジェクトを使用するユースケースは、基本的なユースケースを拡張したものです。このドキュメントでは、スクリプトやプログラムによってリソースのエクスポートとインポートを自動化するユースケースについても説明します。
エクスポート、インポートおよび環境のカスタマイズは、システムに応じて、および企業のポリシーに応じて、デプロイ担当者、オペレータまたは管理者によって行われます。
開発システムからのエクスポートは、一般にデプロイ担当者によって行われます。管理者、オペレータまたはデプロイ担当者は、ステージ・システムから本番システムへのリソースのエクスポートとインポートを担当できます。
リソースのエクスポートとインポートは、Oracle Service Bus管理コンソールや、スクリプトまたはプログラム(開発者が作成可能)を使用して実行できます。
オペレータがシステムからのリソースのエクスポートを担当する場合、定義済の自動化スクリプトまたはプログラムを実行して、プロジェクト全体またはプロジェクト内の特定リソースをエクスポートできます。同様に、オペレータがシステムへのリソースのインポートを担当する場合、定義済の自動化スクリプトまたはプログラムを実行して、インポートを行うことができます。
管理者はカスタマイズ・ファイルを使用して、環境値やリソース内の参照を変更します。カスタマイズ・ファイルには、選択したリソース内で使用されているすべての環境値に対するカスタマイズを含めることができます(たとえば、EnvValueTypesclass内で定義された複合型の環境値)。さらに、リソース内での依存関係を持つリソース参照を変更するための、参照型のカスタマイズも含めることができます。
カスタマイズのタイプを表すカスタマイズ・スキーマ(Customization.xsd)は、Oracle Service Busインストールの次の場所にあります。
OSB_ORACLE_HOME\modules\com.bea.common.configfwk_version.jar
Oracle Service Bus管理コンソールからサンプル・カスタマイズ・ファイルを作成できます。カスタマイズ・ファイルには、プロジェクトまたはプロジェクト内の個々のリソースを含めることができます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のカスタマイズ・ファイルの作成に関する項を参照してください。
エクスポートまたはインポート・プロセスで環境の実際値を指定することで、作成したサンプル・カスタマイズ・ファイルを、必要な変更を加えるための開始点として使用できます。
デプロイメントの一環として、エクスポート・プロセスまたはインポート・プロセスで、ターゲット・システムで適用される値にあわせて、ソース・システム内のリソースの環境値を変更する必要があります。
環境値とは、多くの場合ドメイン間での構成の移動(テスト環境から本番環境への移動など)に伴って変化する値で、構成データに含まれる特定の事前定義されたフィールドです。環境値は、URL、URI、ファイル名、ディレクトリ名、サーバー名、電子メールなどのエンティティを表します。また、環境値は、アラート宛先、プロキシ・サービス、ビジネス・サービス、SMTPサーバーおよびJNDIプロバイダのリソース、UDDIレジストリ・エントリで検索できます。
一部の環境値は複合XMLオブジェクトであり、Oracle Service Bus管理コンソールの「検索置換」オプションでは検索と置換を実行できません。ただし、スクリプトからALSBConfigurationMBeanを使用して、これらの環境値を直接設定できます。ALSBConfigurationMBeanの詳細は、Oracle Fusion Middleware Oracle Service Bus Java APIリファレンスを参照してください。複合型の環境値は、APIで設定するほか、カスタマイズ・ファイルを使用して設定できます。
カスタマイズ・ファイルはXMLファイルで、任意のエディタで開いて、必要な環境値を置換できます。さらに、Oracle Service Bus管理コンソールまたカスタマイズ・ファイルで特定の環境値(複合XMLタイプでない)を検索して、新しい値と置換できます。これらの環境値を変数タイプまたはプロジェクトに基づいてフィルタリングして、検索範囲を調整できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の環境値の検索と置換に関する項を参照してください。
|
注意: 環境値の置換後、カスタマイズ・ファイルを実行する必要があります。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のカスタマイズ・ファイルの実行に関する項を参照してください。 |
環境値の置換は、インポートまたはエクスポート・プロセスの一部として行うことができます。
エクスポート担当者は、増分デプロイメントを実行できるかどうかを確認する必要があります。実行できる場合、特定の時間以降(最後のデプロイメント後など)に変更または作成されたすべてのリソースを検索するスクリプトを記述して、リソースをエクスポートできます。
エクスポート担当者がOracle Service Bus管理コンソールを使用して、選択したリソースのみをエクスポートする場合(増分デプロイメントで)、リソースの最終更新時のタイムスタンプを確認して、エクスポートが必要なリソースのみを選択できます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のリソースのエクスポートに関する項を参照してください。
リソースは、Oracle Service Bus管理コンソールからインポートするか、またはスクリプトを使用してインポートできます。Oracle Service Bus管理コンソールを使用してリソースをインポートする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のリソースのインポートに関する説明を参照してください。
スクリプトを使用する場合、スクリプトによってインポートJARがステージングされます。その後、ステージングされたインポートJARのデプロイ・プランをシステムから取得します。デプロイ・プランにはプロジェクト内のすべてのリソースを含める必要があります。また、これらのリソースをターゲット・システムで作成、削除、更新するのか、またはそのままの状態にするのかを指定する必要があります。一般にデプロイメント・プランは、環境固有のリソース(サービス・アカウントなど)をオーバーレイしないように、またはオペレータが管理するリソースをオーバーレイまたは削除しないように、スクリプトによってカスタマイズされます。
リソースのインポートまたはエクスポート時には、リソースをカスタマイズできます(環境値の置換を含む)。リソースのインポート時に、次の手順を実行します。
セッションを開始します。
必要なリソースをインポートします。
リソースをカスタマイズして、カスタマイズ・ファイルを実行します。
セッションをアクティブ化します。
インポート時に、環境変数を保持して、インポート時に作成されたリソースの環境値のみがカスタマイズ・ファイルでカスタマイズされるようにできます。
Oracle Service Busには、グローバル操作設定と、プロキシ・サービスとビジネス・サービスの操作値とアラート、の2つのタイプの操作値があります。グローバル操作設定は、システム・プロジェクト・フォルダの下にあるリソースです。グローバル操作設定リソースは、他のリソースと同じようにエクスポートできます。インポート時に、このリソースは更新のみ可能で、作成または削除はできません。
インポート時には、Oracle Service Bus管理コンソールで「操作値の保持」オプションを選択して、ターゲット・システムで操作値を保持できます。
|
注意: 時として、オペレータがSLAアラートのアラート宛先を定義することがあります。これらはオペレータが管理するリソースであり、デプロイメント時にオーバーレイまたは削除することはできません。 |
一般に、アクセス制御ポリシーは環境ごとに異なります。この場合、インポート時にアクセス制御ポリシーをオーバーレイしないオプションを指定して、インポート時にアクセス制御ポリシーが失われないようにします。ただし、正しいアクセス制御ポリシーがステージング環境で設定され、本番環境に適用されることもあります。このような場合、アクセス制御ポリシーはサービスとともにインポート/エクスポートされます。
理想を言えば、構成を完了するのに必要なOracle WebLogic Serverアーティファクトが不足している場合、デプロイメントは失敗すべきです。
インポート時にチェックされるものもあれば、インポート時にチェックされず(ビジネス・サービスのリクエスト・キューなど)、実行時エラーが発生するものもあります。
ベスト・プラクティスは、デプロイされたサービスおよびアラート宛先の環境値をデプロイメント・スクリプトで取得し、特定リソースがOracle WebLogic Serverにあるかどうかをチェックすることです。ない場合、デプロイメントは失敗します。管理者は、オペレータがスクリプトを再実行する前に、これらのリソースを定義する必要があります。
より限定的な方法として、アーティファクトをセッションにインポートし、セマンティク・エラーを探すこともできます。セマンティク・エラーは、Oracle Service Busで設計時にOracle WebLogic Serverリソースの存在をチェックする場合に発生します。
グローバル・リソースにはUDDIレジストリ・リソース、JNDIプロバイダ・リソース、およびSMTPサーバー・リソースがあります。これらのリソースは、通常、テスト環境では、ステージング環境や本番環境とは異なる値を使用します。テスト環境から本番環境にデプロイメントを移行する場合、次の方法のいずれかを使用します。
本番ドメインで、テスト環境と同じ名前で新しいグローバル・リソースを作成します。または、テスト環境からグローバル・リソースを直接インポートして、カスタマイズします(手動で作成するよりも時間がかかりません)。
同一環境リソース(SMTPサーバーなど)の名前が環境内で異なる場合があります。これは、インポート・スクリプトによって、インポート・プロセスの一部としてこれらのリソースへの参照をマッピングすることで対処できます。
テスト環境からアーティファクトをエクスポートするときに、グローバル・リソースを除外します。次にconfig.jarファイルだけインポートします。アラート宛先、JNDIプロバイダ、またはSMTPプロバイダを参照するconfig.jarファイルにリソースが含まれている場合、インポートが完了すると、これらの参照は所定の場所に配置されます。
ターゲット・システムに資格証明が上書きされないように、インポートに資格証明を保存するオプションを選択します。
または、すべてのアーティファクト(グローバル・リソースを含む)をエクスポートし、config.jarファイルをインポートするときに、グローバル・リソースを除外します。
Oracle Service Busリソースのデプロイメントで推奨される基本的なベスト・プラクティスの概要を、次に示します。
プロジェクトの名前は変更しないようにします。名前の変更が必要な場合は、次のデプロイメントを行う前に、デプロイメント、QA、ステージおよび各本番システムで同時に変更します。
環境固有のリソースの操作は、インポート時にフィルタで適切に除去されます。管理者はインポート・プロセスを開始する前に、このようなリソース(インポート・ファイルで参照される)をターゲット・システムで定義できます。新たな環境固有のリソースをデプロイして、インポート後に環境にあわせてカスタマイズすることもできます。
オペレータが管理する操作リソースが、インポートの影響を受けないようにします。インポート時にこうしたリソースを識別するために、ネーミング・ルールまたは専用フォルダを使用できます。
単一のカスタマイズ・ファイルにすべてのプロジェクト・リソースのカスタマイズが入っている場合、インポートされたリソースにのみカスタマイズを適用します。インポート時に環境値を保持して、インポート時に追加されたリソースにのみカスタマイズを適用することもできます。
エクスポート時に、エクスポート担当者は、リソースが削除、名前変更または削除されているかどうか、および最後のエクスポート以降、アーティファクトのプロジェクト再編成があったかどうかを確認する必要があります。これらの作業が行われていた場合は、完全デプロイメントを行う必要があります。行われていない場合、エクスポートが必要なリソースのみを選択して、増分デプロイメントを行うことができます。
環境間でグローバル・リソース(UDDIレジストリ、JNDIプロバイダ、SMTPサーバーなど)を移行するのに適した方法を使用します。
UDDIレジストリにデプロイされたサービスを使用する際には、特別に考慮すべき事項があります。この項では、UDDIにパブリッシュされた、またはUDDIからインポートされたプロキシ・サービスおよびビジネス・サービスに関する情報を説明します。UDDI本番レジストリを使用すると、本番システムへのインポートが複雑になるため、十分な注意が必要です。
環境に応じて、次のUDDIデプロイメント・トポロジを使用できます。
最も簡易なUDDIデプロイメントでは、リソースのパブリッシュと検出の両方を行う、単一の開発(設計)時レジストリを使用します。このレジストリは、承認コントロールを使用したガバナンスに使用されます。ただし、別個の設計時パブリッシュ・レジストリおよび検出レジストリを持つこともできます。設計時パブリッシュ・レジストリでの承認後、リソースを検出レジストリに昇格させることができます。
本番レジストリ・トポロジでは、単一の本番UDDIレジストリにすべての本番ビジネス・サービスとプロキシ・サービス、およびその場所(URL)が含まれます。本番レジストリは、すべての本番サービスの検出に使用されます。ただし、別個の本番パブリッシュ・レジストリおよび検出レジストリを持つこともできます。本番パブリッシュ・レジストリでの承認後、リソースを本番検出レジストリに昇格させることができます。
本番レジストリを持つ主な理由は、動的なエンドポイント管理が可能であることです。リソースの自動同期を有効にすることで、UDDIレジストリ内のビジネス・サービスの場所を変更し、それをOracle Service Bus本番システムに自動的に反映させることができます。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のUDDIを使用したサービスの自動同期に関する項を参照してください。
一般に、プロキシ・サービスはパブリッシュ・レジストリに自動的にパブリッシュされます。UDDIでの承認手順でサービスが却下された場合、UDDI承認者はそれを開発者に手動で通知します。開発者は適切な変更を行って、ステージ・システムおよび本番システムでサービスを再エクスポートする必要があります。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の自動パブリッシュの使用に関する項を参照してください。
本番ビジネス・サービスは本番検出レジストリからインポートされます。リソースの自動同期を有効にして、UDDIレジストリの変更内容がOracle Service Busに自動的に反映されるようにできます。ただし、ビジネス・サービスを本番レジストリから開発レジストリに手動でインポートする場合は、開発システムの値に準拠するように環境値を変更する必要があります。開発ビジネス・サービスはUDDIレジストリと自動的には同期されません。開発環境値は多くの場合、本番レジストリとは異なるためです。
もう1つのアプローチは、別個の開発および本番UDDIレジストリを持つことです。このトポロジでは、開発レジストリで承認手順を実行できます。追加の開発UDDIレジストリにより、サイクル内で承認が早めに行われるようになります。
プロキシ・サービスは、POJOコールアウトを使用してUDDIレジストリの動的な検索を実施し、必要な検索基準を満たすサービスを選択して、動的ルーティングのURLを取得することがあります。このシナリオでは、Oracle Service BusでダミーURLを持つダミー・サービスが定義され、このURLが検索後に実際の値と置き換えられます。このシナリオでは、環境ごとにUDDIレジストリが必要です。また、Oracle Service Busのダミー・ビジネス・サービスはどのUDDIサービスにもリンクされません。
このシナリオは、パフォーマンスと可用性に影響を及ぼします。このため、動的ルーティングに使用できるルーティング表のXQueryリソースを使用して、ビジネス・サービスとOracle Service Busとの自動同期を有効にするアプローチが適しています。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の動的ルーティングの使用に関する項を参照してください。
UDDIレジストリにデプロイされたサービスの使用で推奨されるベスト・プラクティスの概要を、次に示します。
特定のUDDIレジストリに関連するビジネス・サービスを特定のフォルダにまとめて、インポート時にこれらのリソースを容易に識別できるようにします。
そのUDDIレジストリを使用するすべてのシステムで、同じUDDIサーバー・リソース名を使用します。別個の開発および本番UDDIレジストリがある場合、別個のUDDIレジストリの開発および本番インスタンスに同じリソース名を使用します。これにより、サービスによるサーバーへの参照が、インポート中に自動的に解決されます。
開発および本番UDDIレジストリを使用する場合、2つのレジストリ間で同じサービス・キーを保持します。
一般に、本番プロキシ・サービスに対して自動パブリッシュ・オプションが有効化され、ビジネス・サービスに対して自動同期オプションが有効化されます。サービスをUDDIレジストリから開発システムに手動でインポートする場合、サービスには引き続きソース・レジストリのUDDIキー情報とレジストリ・リソースへの参照が含まれます。開発サービスはステージ・システムまたはQAシステムに通常の方法でインポートされます。ステージ・システムおよびQAシステムのサービスにも、UDDIキーおよびサービスのソース・レジストリへのレジストリ参照が含まれます。このため、これらのシステムで、「サービスが同期されていない」または「サービスを削除する必要がある」などのUDDI関連ステータス・メッセージが表示された場合は、無視してください。
2つのレジストリを使用する場合、開発レジストリと本番レジストリ内の同一サービスのキーが同じでないことがあります。同じキーを保持することが推奨されます。
ビジネス・サービスの形状が変化した場合は、新しい形状で新たなUDDIサービスを作成します。
Oracle Service Busで使用可能なUDDI関連リソースは、システム間でインポートまたはエクスポートできます。この項では、様々なUDDIデプロイメント・トポロジで考慮すべき情報を示します。すべてのトポロジにおいて、すべてのシステムで同じUDDIレジストリ・リソースが構成されています。ただし、ステージ・システムとQAシステムでは自動同期は有効化されません。
本番UDDIレジストリを使用する場合、いくつかの考慮事項があります。
UDDIには、サービスの情報のサブセットのみが含まれます。このため、サービスに関する情報の中には、通常のインポート、エクスポート・プロセスを通じて本番システムに移動するものもあれば、UDDIレジストリとの同期から本番システムに移動するものもあります。この情報は、インポート時に注意深く管理する必要があります。
サービスが設計時UDDIレジストリから開発システムに移動する際、本番UDDIレジストリ内の同等サービスを識別する方法があることが理想的です。これにより、インポート時に、サービスの情報を本番UDDIレジストリ内の同等サービスに確実にマージできます。
このシナリオでは、システム間で移動する際に、次の手順を実行する必要があります。
ビジネス・サービスをUDDIレジストリからデタッチします。
プロキシ・サービスの自動パブリッシュ・オプションを無効にします。これは、MBean APIを使用して、またはプロキシ・サービスの構成時にOracle Service Bus管理コンソールを使用して行います。
必要に応じて、サービスに変更を加えます。
リソースを現在のシステムからJARに手動でエクスポートして、次のシステムにインポートします。
リソースを本番システムにインポートする場合、次のいずれかのシナリオを使用できます。
新しいサービスをシステムにインポートする(インポートJAR内のサービスのUDDIキーとUDDIレジストリは同じ)。
新しいサービスをシステムにインポートする(インポートJAR内のサービスのUDDIキーとUDDIレジストリは異なる)。
既存のサービスをシステムにインポートする
新しいサービスを本番システムにインポート。インポートJAR内のサービスのUDDIキーとUDDIレジストリは同じ
このシナリオでは、サービスをシステムにインポートし、次のいずれかを実行します。
インポート・スクリプトを使用し、APIコールにより、現在のセッションで明示的にサービスのUDDI再同期を施行します。
Oracle Service Busによるバックグラウンド再同期のために、インポートしたサービスにマークを付けます。
このオプションの欠点は、再同期が完了するまで、UDDI関連サービスのフィールドが不正確な可能性があることです。ただし、自動同期が有効化されている場合、不正確な時間は短くなります。
新しいサービスを本番システムにインポート。インポートJAR内のサービスのUDDIキーとUDDIレジストリは異なる
このシナリオでは、サービスをシステムにインポートし、次のいずれかを実行します。
インポート・スクリプトで、APIコールにより、現在のセッションでサービスのUDDI再同期を明示的に施行します。サービスは、セッションがアクティブになった後で「同期保留」として表示されます。
UDDIレジストリで一致するUDDIサービスが見つからなかったという理由で、サービスに削除マークを付けます。リソースを適切にカスタマイズしてから、カスタマイズ・ファイルを実行します。後で、Oracle Service Bus管理コンソールを使用して、UDDIレジストリからサービスをデタッチします。
このアプローチの欠点は、UDDIの他に、本番環境値もカスタマイズ・ファイルに含める必要がある点です。
レジストリからサービスをデタッチした後、UDDIレジストリからUDDI関連情報をダウンロードし、必要に応じて自動同期を有効にできます。
既存のサービスの本番システムへのインポート
このシナリオでは、次のいずれかを実行します。
UDDIレジストリ(またはサービス・キーの面で同一のUDDIレジストリ)を使用する場合、インポート時に本番UDDIサービスをオーバーレイします。その後、APIコールにより、現在のセッションでサービスのUDDI再同期を施行できます。
インポート・スクリプトを使用して、このサービスの本番システムへのインポートをスキップします。これは、UDDI本番キーが異なる場合のみのオプションです。
ただし、サービスのインポートをスキップすると、サービスの非UDDIソース・データが不正確な可能性があります。このため、最新のサービスをインポートするかわりに、本番サービス定義でこれらの情報を直接更新する必要があります。
この項では、Oracle Virtual Assembly Builderを使用してOracle仮想環境(Oracle VM)にOracle Service Bus構成をデプロイする手順の概要を示します。
開始する前に、『Oracle Virtual Assembly Builderインストレーション・ガイド』および『Oracle Virtual Assembly Builderユーザーズ・ガイド』で説明されているように、Oracle Virtual Assembly Builderをインストールおよび構成します。『Oracle VM Managerインストレーション・ガイド』および『Oracle VM Serverインストレーション・ガイド』で説明されているように、Oracle VMをインストールおよび構成します。
インストールに次のコンポーネントが含まれていることを確認します:
Oracle Virtual Assembly Builder Studio
Oracle Virtual Assembly Builder Deployer
Oracle VM Manager
Oracle VMサーバー
仮想環境では、次のService Busデプロイメント・トポロジがサポートされています。
管理サーバーのみのトポロジ
管理サーバーおよび管理対象サーバー・トポロジ
クラスタ・トポロジ
また、仮想環境では次のService BusおよびSOA Suiteドメイン・トポロジもサポートされています。
管理サーバー、Service Bus管理対象サーバーおよびSOA Suite管理対象サーバー
Service Busのデプロイメント・トポロジについては、1.2項「Oracle Service Busデプロイメント・トポロジ」を参照してください。クラスタ・トポロジについては、名前参照に失敗しないように、静的IPアドレスでホストを構成します。
Oracle Virtual Assembly Builderを使用して仮想環境にOracle Service Bus構成をデプロイするには:
Service Busドメインを使用してWebLogic ServerにService Bus構成を作成またはデプロイします。
Service Busドメインで構成ファイルのアーカイブを有効にします。
詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの構成ファイルのアーカイブに関する説明を参照してください。
Oracle WebLogic Server管理コンソールを使用して、ドメインのOracle WebLogic Serverに関する側面を構成します。
たとえば、必須のデータ・ソースを作成および構成します。正しく構成されていることをテストします。
構成をエクスポートおよびバックアップします。
ドメインからService Bus構成を削除します。単なるアンデプロイはしないでください。それを削除する必要があります。
WebLogic Serverで信頼ストアを構成します。
|
注意: 現在サポートされている信頼ストアのタイプは、「デモIDとデモ信頼」のみです。WebLogic Serverの信頼ストアがカスタムIDまたはカスタム信頼の場合は、イントロスペクションの前にデモIDとデモ信頼に戻し、正しいキーストアまたは信頼ストアのタイプを各デプロイメント後に再構成する必要があります。 |
Service Busドメイン・ディレクトリから名前にスラッシュまたはバックスラッシュが入った一時ファイルを削除します。
次のいずれかを実行します。
Oracle Coherenceクラスタを使用しており、仮想マシンがDHCP IPアドレスを使用する場合は、Service Busがマルチキャスト・アドレス用に構成されていることを確認します(4.1項「手順1. 構成の前提条件への準拠」を参照してください)。
Oracle Coherenceクラスタを使用し、仮想マシンが静的IPアドレスを使用する場合、ユニキャスト・アドレスに既知のアドレス(WKA)を構成します。詳細は、付録C「静的IPアドレスを使用した仮想環境の構成」を参照してください。
現在ベース・ドメインにあるService Busプロジェクトをエクスポートします。エクスポートが完了してから、Service Busプロジェクトおよびリソース(UDDIレジストリ、JNDIプロバイダ、SMTPサーバーおよびプロキシ・サーバー・リソース)を削除します。
Service Busコンポーネントをエクスポートおよび削除する手順については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』(Eclipseを使用する場合)または『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』(Service Busコンソールを使用する場合)を参照してください。
Oracle Virtual Assembly Builder CLIコマンドまたはAssembly Builder StudioでWebLogic Serverイントロスペクション・プラグインを使用して、Service Busドメイン(Service Bus構成を削除したドメイン)の外部に新しいWebLogic Serverアセンブリを作成します。
コマンドライン・インタフェースおよびAssembly Builder Studioでの作業の手順は、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。
コマンドライン・インタフェースを使用する場合、次の手順を実行して、アセンブリを作成します。:
introspectWLSコマンドを使用して、ドメイン情報を取得します。
createAssemblyコマンドを使用して、空のアセンブリを作成します。
addToAssemblyコマンドを使用して、イントロスペクトされたアセンブリを新しいアセンブリに追加します。
createExternalResourcesコマンドを使用して、外部参照を外部リソース・エンドポイントにマッピングします。
クラスタ・トポロジにOHSをイントロスペクトする場合、connectEndpointsコマンドを使用して、Oracle HTTP Server (OHS)およびWLS間でのエンドポイント接続を作成します。
Oracle Virtual Assembly Builderを使用して、デプロイメント・テンプレートを作成し、アセンブリ・アーカイブをアップロードし、Oracle VMにアーカイブを登録して、アセンブリをデプロイします。このプロセス中に、データベースおよび認証プロバイダなどの外部リソースへリンクする必要がある場合があります。
これらの手順については、『Oracle Virtual Assembly Builderユーザーズ・ガイド』を参照してください。
アセンブリがデプロイされてから、仮想環境のデプロイ済のWebLogic ServerアセンブリにService Bus構成を手動でデプロイします。
|
注意: 仮想環境のWebLogic Serverインスタンスは、localhostではなく、仮想マシンのIPアドレスのみをリスニングしている可能性があります。その場合、Service Bus構成でlocalhostを使用するURIを変更する必要がある場合があります。 |
必要に応じて、前の手順でエクスポートしたService Busプロジェクトをインポートして、必須のリソースを再作成します。
