| Oracle® Fusion Middleware Oracle Service Busでのサービスの開発 12c (12.2.1) E69914-01 |
|
 前 |
 次 |
この章では、Service BusプロジェクトおよびアプリケーションをOracle WebLogic Serverにデプロイするための手順について説明します。Oracle Service Busコンソール、JDeveloper、Fusion Middleware ControlおよびService BusデプロイメントAPIからService Busコンポーネントをデプロイできます。異なる環境へのデプロイおよび異なる環境からのデプロイでは、カスタマイズ・ファイルを使用してエンドポイントURIなどの環境値を更新できます。
この章の内容は次のとおりです。
デプロイメントは、Service Busリソースをパッケージ化し、それらをターゲット・アプリケーション・サーバーに転送するプロセスです。リソースは、次のような様々な方法によってデプロイできます。
Oracle Service Busコンソールでの現行セッションのアクティブ化。
JDeveloperでのデプロイ・コマンドの使用によるプロジェクトまたはアプリケーションのデプロイ。
JDeveloperでの構成JARファイルのアプリケーション・サーバーへのエクスポート。また、JDeveloperに含まれる統合アプリケーション・サーバーにデプロイすることで、アプリケーションおよびプロジェクトの実行、デバッグおよびテストが行えます。
Fusion Middleware Controlを使用した構成JARファイルのインポート。
Mavenプラグインを使用したMaven環境へのService Busサービスのデプロイ。詳細は、「Oracle Service Bus開発Mavenプラグインの使用」を参照してください。
WLSTコマンドを使用したセッションのアクティブ化および構成と環境値のインポート。詳細は、『Oracle Service Busの管理』のOracle Service BusデプロイメントAPIの使用に関する項を参照してください。
Service Busリソースのデプロイ後は、Fusion Middleware Controlを使用してランタイムでそれらのリソースをモニターおよび管理できます。詳細は、『Oracle Service Busの管理』を参照してください。
Service Bus構成をデプロイする方法に関係なく、デプロイする前に次の項を確認してください。
Service Bus構成をデプロイするには、Service Busリソースをデプロイする実行中のService Busドメインが必要です。このドメインは、実行中のデータベースに必須スキーマを保持している必要があります。Oracle Fusion Middleware構成ウィザードを使用したService Busドメインの作成の詳細は、『Oracle Fusion Middleware Oracle Service Busのインストールおよび構成』を参照してください。
デプロイ中のService Busリソースに競合があると、そのデプロイメントは失敗します。「競合の表示と解決」の説明に従い、リソースのアクティブ化またはエクスポートの前に、既存の競合を表示し、解決します。Service Busリソースに競合がある場合、JDeveloperからのデプロイまたはコンソールからのアクティブ化は失敗します。
Oracle Fusion Middleware構成ウィザードでのJMSファイル・ストアの構成とともに、JMSを使用するプロキシ・サービスおよびビジネス・サービスは次のリソースが必要です。
JMSコネクション・ファクトリ: JMSを使用して実装されたすべてのビジネス・サービスとプロキシ・サービスに、XAまたは非XAのJMS接続ファクトリを構成する必要があります。
JMSキューおよびトピック: キューが同じローカルService Busドメイン上にある場合、Service BusではJMSを使用して実装されたプロキシ・サービスに自動的にJMSキューが構成されます。JMSを使用するすべてのビジネス・サービス、リモート・キューからのメッセージを消費するプロキシ・サービス、および非JMSを使用して実装されたプロキシ・サービスには、JMSキューまたはトピックを構成する必要があります。
すべてのService Bus JMSリソースを単一のJMSモジュールにまとめるには、WebLogic Server管理コンソールを使用して、プロキシ・サービスのエンドポイントとして使用する宛先を含む新しいJMSモジュールを作成します。JMSリソースの構成の詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSリソースの構成方法に関する項を参照してください。
Service Busでは、WebLogic Serverのセキュリティ機能を利用して、メッセージの機密性と整合性を保証し(メッセージ・レベルのセキュリティ)、WebLogic Server、サービス・クライアント、およびビジネス・サービスの間の接続を保護し(転送レベルのセキュリティ)、認証と認可(アクセス制御)を行います。Oracle Service Busのセキュリティを構成する方法の詳細は、「セキュリティ」を参照してください。
注意:
各Service Busドメインに別々にセキュリティを構成する必要があります。Service Busでは、セキュリティ構成のエクスポートおよびインポートは行いません。
Oracle Service Busコンソールでは、変更をアクティブ化することで、作成したサービスをランタイムにデプロイします。アクティブ化した変更は、ただちに実行時環境で使用可能になります。また、Oracle Service Busコンソールを使用して、実行時にアクティブ化されるコンポーネントを更新することもできます。
Service Busドメインの構成と保護を終え、サービスに必要なJMSリソースを追加すると、Service Bus構成が入ったJARファイルをインポートできます。構成メタデータをインポートした後、ドメインの環境固有の情報を更新できます。セキュリティ関連の変更を除くService Bus構成へのすべての変更には、セッションが必要です。
構成JARファイルのコンテンツをデプロイするには:
WebLogic Scripting Tool (WLST)とService BusのdeploymentMBeanを使用して、プログラムで構成のインポートと更新を行うこともできます。詳細は、『Oracle Service Busの管理』のOracle Service BusデプロイメントAPIの使用に関する項を参照してください。
アプリケーションまたはプロジェクトをWebLogic Serverに最初にデプロイするときに、アプリケーション全体とすべてのプロジェクトがパブリッシュされます。その後のアプリケーションのデプロイメントでは、変更されたリソースのみがサーバーにパブリッシュされます。アプリケーション内のService Busリソースに競合があると、そのデプロイメントは失敗します。
JDeveloperで、Service Busアプリケーションがデプロイされるアプリケーション・サーバーへの接続を作成する必要があります。Service Busサービスをホストしている各アプリケーション・サーバーに対してこのタスクを1回実行するだけです。次のタイプのサーバーに接続できます。
スタンドアロン・サーバー: JDeveloperに管理されていないサーバー。スタンドアロン・サーバーには、Oracle Cloudの構成ウィザードとWebLogicサーバーを使用して作成したドメインが含まれます。スタンドアロン・サーバーへのデプロイにはデプロイ・コマンドのみを使用できます。デプロイ先のサーバーが実行されている必要があります。
統合サーバー: JDeveloperで管理でき、開発とテストでのみ使用されるサーバー。接続の設定時、JDeveloperによるサーバーのライフサイクルの管理を許可すると、実行コマンドまたはデプロイ・コマンドを使用してJDeveloperからサーバーに直接デプロイできます。JDeveloperでライフサイクルを管理しない場合は、サーバーを手動で起動および停止する必要があります。この場合、サーバーがすでに実行されていれば、実行コマンドのみをデプロイに使用できます。
アプリケーション・サーバー接続を作成するには:
デプロイメント・プロファイルにより、プロジェクトまたはアプリケーションをデプロイするアプリケーション・サーバーについての情報がJDeveloperに提供されます。このプロファイルのタイプは、選択したプロジェクトのみをデプロイするか、Service Busアプリケーション全体をデプロイするかを示します。Service Busは、作成する各Service Busプロジェクトにデフォルトのプロジェクト・デプロイメント・プロファイルを追加し、各Service Busアプリケーションにデフォルトのアプリケーション・デプロイメント・プロファイルを追加します。それぞれが異なるアプリケーション・サーバーにデプロイされる追加デプロイメント・プロファイルを定義できます。
デプロイメント・プロファイルの使用の詳細は、『Oracle JDeveloperによるアプリケーションの開発』のデプロイメント・プロファイルの作成および編集方法に関する項を参照してください。
デプロイメント・プロファイルを作成するには:
JDeveloperでは、Service Busのデプロイメントをカスタマイズできます。
選択したプロジェクトのみをWebLogic Serverにデプロイするか、選択したプロジェクトが配置されているアプリケーション全体をデプロイできます。プロジェクト・レベルのデプロイメントは、増分ではなく完全なプロジェクトとそのすべての依存関係をパブリッシュします。プロジェクトまたはアプリケーションをデプロイする場合、処理に使用するデプロイメント・プロファイルを選択します。使用するプロファイルによって、プロジェクトのみをデプロイするか、アプリケーション全体をデプロイするかが決定されます。各プロジェクトに生成されたデフォルト・プロファイルは、そのプロジェクトのみをデプロイします。
Service BusおよびJDeveloperでは現在、Oracle Cloudサーバーへの直接デプロイをサポートしています。Oracle Cloudサーバーへの接続の作成の詳細は、「WebLogic Serverへの接続の作成方法」を参照してください。
注意:
Runコマンド(選択したサーバーへのデプロイと、Service Busテスト・コンソールの起動)を使用したサーバーへのパブリッシュも可能です。統合型のサーバーでは、実行コマンドのみが使用可能です。詳細は、「テスト・コンソールへのアクセス」を参照してください。
始める前に
「WebLogic Serverへの接続の作成方法」の説明しているように、アプリケーション・サーバーに接続していることを確認します。デフォルトのデプロイメント・プロファイルを使用しない場合は、「デプロイメント・プロファイルの作成方法」で説明しているように、新しいプロファイルを作成します。
プロジェクトまたはアプリケーションをデプロイするには:
プロジェクトを一度デプロイすると、以降のデプロイメントで同じ構成を使用する場合はデプロイ・ウィザードをスキップできます。デプロイ・ウィザードをスキップすると、Service Busは前回のプロジェクトのデプロイ時と同じデプロイメント・プロファイルとデプロイ・ウィザードでの選択を使用します。
前回の構成を使用してデプロイするには:
デプロイメントに成功した場合、デプロイされたプロジェクトが次の場所に表示されます。
「アプリケーション・サーバー」→「server_connection_name」→「Service Bus」→「Service_Bus_server_name」の下の「リソース」ウィンドウ。
「server_connection_name」→「Service Bus」→「Service_Bus_server_name」の下のアプリケーション・サーバー・ナビゲータ。
これで、Oracle Enterprise Manager Fusion Middleware Controlからアプリケーションをモニターする準備ができました。詳細は、『Oracle Service Busの管理』を参照してください。
デプロイメントに失敗した場合、デプロイメント・ログ・ウィンドウに表示されるメッセージを確認して修正処理を行ってください。
ファイルをFusion Middleware Controlにインポートすることで、Service Bus構成JARファイルをデプロイできます。構成JARファイルには、以前別のService Bus環境からエクスポートされたService Busリソースが含まれます。エクスポートおよびインポート機能により、環境をまたいだプロジェクトおよびリソースの移動が容易になります。JARファイルのインポートでは、インポートしたリソースの操作設定および環境値を新しい環境に合せて更新する、個別の構成ファイルをインポートすることもできます。たとえば、構成ファイルではホスト名およびポート番号を更新したり、サービスのモニターを有効化または無効化できます。
Fusion Middleware Controlへのリソースのインポートの詳細は、『Oracle Service Busの管理』のOracle Service BusのFusion Middleware Controlへのインポートに関する項を参照してください。環境構成ファイルの詳細は、『Oracle Service Busの管理』の構成ファイルを使用した環境値と操作設定の更新に関する項を参照してください。
構成がデプロイされると、Service Busではシステムの構成情報を動的に変更できます。変更内容を有効にするためにサーバーを再起動する必要はありません。「コンソールからデプロイする方法」で説明している手順を使用して、リソースやプロジェクト、または複数の(関連する、あるいは関連しない)リソースを変更できます。手順2では、リソースを直接コンソール内で変更するか、オブジェクトのすべてまたはサブセットを構成JARファイルからインポートできます。
変更がまとめられ、すべてのサーバー(クラスタ環境を使用している場合は管理サーバーと管理対象サーバー)に送られます。このような変更によって、永続構成データが更新され、また、プロキシ・サービスやJMSキューの作成、XQueryのコンパイルなど、他の実行時タスクも実行されます。
図59-1は、システムでのメッセージの処理中に構成が更新された場合に、システムがメッセージをどのように処理するかを示します。表59-1は、図59-1に示されているサンプル・システムのリソースのバージョンを示します。
表59-1 サンプル・システムの最初の構成と更新された構成
| リソース | 最初のバージョン | 更新されたバージョン |
|---|---|---|
プロキシ・サービス |
X |
A |
MFL |
Y |
B |
XQuery |
W |
C |
この図のメッセージ処理では次の点に注意してください。
メッセージ1は、t1 (構成の更新時)にはすでにシステムに届いている
メッセージ1は、元(更新前)のリソース(X、Y、W)を使用して処理を完了する
メッセージ2は、新しい構成(リソースA、B、C)を使用して処理を開始して完了する
Service Busは、メッセージがプロキシ・サービスに届いた時点で使用可能なバージョンのプロキシ・サービスとアーティファクトを使用して、メッセージを実行しようとします。これにより、メッセージのアーティファクトの一貫性が保たれます。メッセージ・プロセッサが、メッセージに対してこの動作を保証できない場合は、誤って処理しないようにメッセージを拒否します。
この項では、実行中のService Busシステムで構成を更新するときに従うガイドラインと注意する必要のある制約について説明します。
Service Busによるメッセージの拒否が心配な場合は、再試行機能のあるJMS転送プロトコルを使用します。互換性のあるリソースでの処理をシステムが保証できないためにメッセージが拒否されることがありますが、そのようなメッセージがすべて再試行されます。
セキュリティ関連の構成を最初に更新してから、システム内のService Busリソースを更新します。セキュリティ構成変更は、特にアクティブ化のため、Service Busに表示される前にWebLogicサーバー・レベルで変更しておく必要があります。たとえば、SSLを使用するためにプロキシ・サービスを有効にするには、SSL関連のオプションをドメイン・レベルで構成する必要があります(SSLポートの有効化、ドメインの識別および信頼など)。セキュリティ・リソースの更新の詳細は、『Oracle WebLogic Serverセキュリティの管理』のセキュリティ管理の概要に関する項を参照してください。
更新内容は、システムを使用する既存のクライアントと互換性を持つ必要があります。「オンライン・プロキシ・サービスの変更」を参照してください。
クラスタの構成を更新する場合、管理対象サーバーごとに更新のタイミングが異なる可能性があります。結果として、メッセージを取得して処理する管理対象サーバーに応じて、メッセージを処理するプロキシ・サービスのバージョンが異なることがあります。これは、管理対象サーバー間のロード・バランシングに依存します。
オンライン・デプロイメントの際に、Service Busで正しいバージョンの参照リソースがメッセージ処理に使用されているかどうかを確認します。一時的に正しいバージョンの参照リソースが使用されていない場合は、エラーが返されます。ただし、呼び出されたサービスのインタフェース・アーティファクト(MFL、WSDLファイルなど)が変更されている場合、プロキシ・サービスのバージョンと相関しないアーティファクトのバージョンが一時的に確認されても、呼出しを行うプロキシ・サービスではエラーを返さない場合があります。
既存のエンタープライズ情報システム(EIS)インスタンスが徐々に少なくなり、新しいインスタンス(EISソフトウェアの新しいバージョン、新しいハードウェアなどで使用可能)がオンラインで提供される場合があります。このような場合、Service Bus管理者は、影響を受けるService Busサービスを変更して新しいEISインスタンスに適切に移行する必要があります。
Oracle Service Busコンソールを使用したビジネス・サービスのエンドポイントURIの変更については、「ビジネス・サービスのトランスポートの構成方法」を参照してください。
プロキシ・サービスを定義する大部分のメタデータは、新しい環境にデプロイする際に変更する必要はありませんが、次の情報の更新が必要になることがあります。たとえば、ファイル、FTPおよび電子メール・メッセージのタイプを持つプロキシ・サービスの定義では、クラスタでのポーリング実行時コンポーネントのデプロイメント用に単一の管理対象サーバーを指定する必要があります。
ビジネス要件の変化に伴い、プロキシ・サービスの変更が必要になることがあります。変更に後方互換性がある場合、Oracle Service Busコンソールを使用してオンラインで動的に変更を行い、新しいバージョンのプロキシ・サービスを作成できます。次のいずれかの条件を満たす場合、変更には後方互換性があります。
変更対象オブジェクトのインタフェースは変更しません。
新旧混在のクライアントがインタフェースを使用します。
必要な変更に後方互換性がない場合、オンラインで変更できるようにする2つの代替方法があります。
以前のバージョンとは異なる名前とURLを持つ新しいプロキシ・サービスを作成し、デプロイします。クライアントは新しいプロキシ・サービスにアクセスすることでアップグレードされます。この場合、プロキシ・サービスの新旧のバージョンを並行して実行し、新しいプロキシ・サービスに段階的に移行できます。
プロキシ・サービスのインタフェースを変更して新しいインタフェースと古いインタフェースの両方をサポートするようにし(たとえば、XMLスキーマchoiceを使用)、受信されるドキュメントに基づいてメッセージ・フローで異なるロジックを実行することで、後方互換性を強制的に実現します。クライアントは、引続き元のURLを使用してプロキシ・サービスにアクセスできます。
さらに、Service Busクラスタ・ドメインでは、後方互換性のないプロキシ・サービスのデプロイメントについてのシステム管理要件があります。詳細は、「クラスタへの新しいバージョンのプロキシ・サービスのインストール」を参照してください。
クラスタでService Busコンポーネントを更新する場合は、非クラスタ環境について考慮する必要もあります。オンライン更新の実行については、「オンライン構成の更新」を参照してください。
ビジネス・サービスを変更する手順は、非クラスタ環境でもクラスタ環境でも同じです。しかし、クラスタのビジネス・サービスへの変更をデプロイする手順は、ビジネス・サービスに行った変更の種類および同時にデプロイする他の変更の性質によって異なります。詳細は、次の項のインストール戦略に関する説明を参照してください。
ビジネス・サービスの変更方法については、「オンライン・ビジネス・サービスの変更」を参照してください。
プロキシ・サービスの変更はオンラインで動的に行うことも、部分的または完全にオフラインで行うこともできます。変更に後方互換性がある(つまり、インタフェースは変更しない)場合、Oracle Service Busコンソールを使用してオンラインで動的に変更できます。他の種類の変更は、部分的または完全にオフラインで行う必要があり、システム管理の追加手順が必要です。
プロキシ・サービス・インタフェースへの後方互換性がない変更を含む変更を行うには、完全なオフライン・デプロイメントが必要です。新しいバージョンをインストールするには、すべてのサーバーが作動中に次の手順を実行します。
後方互換性とインストール方針の詳細は、「オンライン・プロキシ・サービスの変更」を参照してください。
