| Oracle® Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース(11.1.1.3) B61432-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Service Busデプロイメント・ガイド 11g リリース(11.1.1.3) B61432-01 |
|
前 |
次 |
Oracle Service Busには、本番システムへのリソースのデプロイメントを自動化する強力な機能があります。また、様々なデプロイメント・ユースケースをすべてサポートしています。
このドキュメントでは、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 Fusion Middleware Oracle Service Bus管理者ガイド』のリソースのインポートに関する項を参照してください。
スクリプトを使用する場合、スクリプトによってインポートJARがステージングされます。その後、ステージングされたインポートJARのデプロイ・プランをシステムから取得します。デプロイ・プランにはプロジェクト内のすべてのリソースを含める必要があります。また、これらのリソースをターゲット・システムで作成、削除、更新するのか、またはそのままの状態にするのかを指定する必要があります。一般にデプロイメント・プランは、環境固有のリソース(サービス・アカウントなど)をオーバーレイしないように、またはオペレータが管理するリソースをオーバーレイまたは削除しないように、スクリプトによってカスタマイズされます。
リソースのインポートまたはエクスポート時には、リソースをカスタマイズできます(環境値の置換を含む)。リソースのインポート時に、次の手順を実行します。
セッションを開始します。
必要なリソースをインポートします。
リソースをカスタマイズして、カスタマイズ・ファイルを実行します。
セッションをアクティブ化します。
インポート時に、環境変数を保持して、インポート時に作成されたリソースの環境値のみがカスタマイズ・ファイルでカスタマイズされるようにできます。
サービス・アカウント、サービス・キー・プロバイダ、SMTPサーバー、JNDIサーバー、UDDIサーバーなどのリソースには資格証明が含まれるため、基本的に環境固有であり、管理者の管理下に置かれます。これらのリソースはターゲット・システムで定義し、環境内で移動しないようにする必要があります。
完全プロジェクト・デプロイメントにおいても、環境固有リソースはターゲット・システムで更新できません。インポート・ファイル内に、ターゲット・システムに存在しない環境固有リソースへの参照がある場合、推奨されるベスト・プラクティスは、インポートを中止し、これらのリソースを定義した後にインポートを再実行することです。
また、環境固有リソースをインポートするが、インポート時に資格証明をオーバーレイしない(資格証明を保持する)オプションを有効にする、という方法がとられることもあります。初回インポート後、管理者は資格証明を正しい値に手動で変更できます。
同一環境リソース(SMTPサーバーなど)の名前が環境内で異なる場合があります。これは、インポート・スクリプトによって、インポート・プロセスの一部としてこれらのリソースへの参照をマッピングすることで対処できます。
Oracle Service Busには、グローバル操作設定と、プロキシ・サービスとビジネス・サービスの操作値とアラート、の2つのタイプの操作値があります。グローバル操作設定は、システム・プロジェクト・フォルダの下にあるリソースです。グローバル操作設定リソースは、他のリソースと同じようにエクスポートできます。インポート時に、このリソースは更新のみ可能で、作成または削除はできません。
インポート時には、Oracle Service Busコンソールで「操作値の保持」オプションを選択して、ターゲット・システムで操作値を保持できます。
|
注意: 時として、オペレータがSLAアラートのアラート宛先を定義することがあります。これらはオペレータが管理するリソースであり、デプロイメント時にオーバーレイまたは削除することはできません。 |
一般に、アクセス制御ポリシーは環境ごとに異なります。この場合、インポート時にアクセス制御ポリシーをオーバーレイしないオプションを指定して、インポート時にアクセス制御ポリシーが失われないようにします。ただし、正しいアクセス制御ポリシーがステージング環境で設定され、本番環境に適用されることもあります。このような場合、アクセス制御ポリシーはサービスとともにインポート/エクスポートされます。
理想を言えば、構成を完了するのに必要なOracle WebLogic Serverアーティファクトが不足している場合、デプロイメントは失敗すべきです。
インポート時にチェックされるものもあれば、インポート時にチェックされず(ビジネス・サービスのリクエスト・キューなど)、実行時エラーが発生するものもあります。
ベスト・プラクティスは、デプロイされたサービスおよびアラート宛先の環境値をデプロイメント・スクリプトで取得し、特定リソースがOracle WebLogic Serverにあるかどうかをチェックすることです。ない場合、デプロイメントは失敗します。管理者は、オペレータがスクリプトを再実行する前に、これらのリソースを定義する必要があります。
より限定的な方法として、アーティファクトをセッションにインポートし、セマンティク・エラーを探すこともできます。セマンティク・エラーは、Oracle Service Busで設計時にOracle WebLogic Serverリソースの存在をチェックする場合に発生します。
Oracle Service Busリソースのデプロイメントで推奨されるベスト・プラクティスの概要を、次に示します。
プロジェクトの名前は変更しないようにします。名前の変更が必要な場合は、次のデプロイメントを行う前に、デプロイメント、QA、ステージおよび本番の各システムで同時に変更します。
環境固有のリソースの操作は、インポート時にフィルタで適切に除去されます。管理者はインポート・プロセスを開始する前に、このようなリソース(インポート・ファイルで参照される)をターゲット・システムで定義できます。新たな環境固有のリソースをデプロイして、インポート後に環境にあわせてカスタマイズすることもできます。
オペレータが管理する操作リソースが、インポートの影響を受けないようにします。インポート時にこうしたリソースを識別するために、ネーミング・ルールまたは専用フォルダを使用できます。
単一のカスタマイズ・ファイルにすべてのプロジェクト・リソースのカスタマイズが入っている場合、インポートされたリソースにのみカスタマイズを適用します。インポート時に環境値を保持して、インポート時に追加されたリソースにのみカスタマイズを適用することもできます。
エクスポート時に、エクスポート担当者は、リソースが削除、名前変更または削除されているかどうか、および最後のエクスポート以降、アーティファクトのプロジェクト再編成があったかどうかを確認する必要があります。これらの作業が行われていた場合は、完全デプロイメントを行う必要があります。行われていない場合、エクスポートが必要なリソースのみを選択して、増分デプロイメントを行うことができます。
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ソース・データが不正確な可能性があります。このため、最新のサービスをインポートするかわりに、本番サービス定義でこれらの情報を直接更新する必要があります。
