| Oracle® Fusion Middleware Oracle Service Busの管理 12c (12.1.3) E53003-05 |
|
 前 |
 次 |
この付録の内容は次のとおりです。
WSRPには、必須のコンポーネントが2つあります。1つはプロデューサであり、もう1つはコンシューマです。
WSRPプロデューサ(このドキュメントではプロデューサと表記)は、SOAP over HTTP仕様を使用して標準ベースのWebサービスを実装するリモート・アプリケーションです。プロデューサは、WebLogic Portalまたはサード・パーティによるWSRP実装を使用して作成できます。
WSRPコンシューマ(このドキュメントではコンシューマと表記)は、ポータル・アプリケーションです。通常、コンシューマ・アプリケーションは、ポータル設計時にプロデューサのWSDLドキュメントを参照し、コンシューマはプロデューサに直接アクセスします。
この項では、WSRPのアーキテクチャについて説明し、Oracle Service Busを追加してこのアーキテクチャを拡張する方法を示します。
次の図は、プロデューサ・アプリケーションとコンシューマ・アプリケーション間のWSRP SOAP要求および応答フローを示しています。
図D-1 プロデューサ・アプリケーションとコンシューマ・アプリケーション間の基本のリクエスト/レスポンス・フロー
次の図は、Service Busを使用してプロデューサとコンシューマを仲介することにより、サービス・レベル・アグリーメント(SLA)モニター機能を提供する方法を示しています。
図D-2 Oracle Service Busを使用して拡張されたWSRPのリクエスト/レスポンス・フロー
WSRP SOAPリクエスト/レスポンス・フローは次の順序で行われます。
インバウンド・リクエスト: コンシューマがService Busでプロキシ・サービスを呼び出します。
アウトバウンド・リクエスト: プロキシ・サービスがリクエスト(SOAP本体とトランスポート・ヘッダーを含むメッセージ)をプロデューサにルーティングします。
アウトバウンド・レスポンス: プロデューサがレスポンスをService Busに送信します。
インバウンド・レスポンス: プロキシ・サービスがレスポンスをコンシューマに送信します。レスポンスとは、SOAP本体とトランスポート・ヘッダーを含むメッセージです。
Service Busコンポーネントの実際の構成の詳細は、「WSRP対応Oracle Service Busの構成」を参照してください。
WSRP設計における2つの主要なコンポーネントは、サービスを記述するWSDLドキュメントと、メッセージング形式を記述するWSDLドキュメントです。
次の表では、WSDLドキュメントで提供される各種サービスについて説明しています。WSDLドキュメントは、プロデューサと表記しています。
表D-1 プロデューサ・サービス
| サービス | 説明 |
|---|---|
サービス記述 |
必須サービス。プロデューサがコンシューマに使用できるようにする、プロデューサとポートレットについて記述されます。 |
マークアップ |
必須サービス。リモート・ポートレットとのユーザーの対話を管理し、ポートレットのレンダリングに使用されるHTMLマークアップを返します。 |
登録 |
オプション・サービス。複雑なプロデューサでは必須です。これを使用してコンシューマがプロデューサに自己登録できます。 |
管理 |
オプション・サービス。複雑なプロデューサでポートレットのカスタマイズとポートレットのプリファレンスを管理するために提供されます。 |
マークアップ拡張機能 |
Oracle WebLogic Portalプロデューサでマークアップ・サービスのかわりに提供されます。マークアップ拡張機能では、HTMLマークアップ・コンテンツの送信でマルチ・パートMIMEメッセージを使用すると、メッセージ処理の効率が上がります。 |
各プロデューサは、少なくとも2つのサービス(サービス記述とマークアップなど)を実装します。単純なプロデューサは、これら2つのサービスのみを提供します。複雑なプロデューサは、この他に2つのサービス(登録と管理など)を提供します。また、WebLogic Portalプロデューサは、標準のマークアップ・サービスのかわりに使用できる拡張機能サービス(マークアップ拡張機能など)も実装します。
これらのサービスは、標準のWSDL形式で記述されます。プロデューサは、WSDLドキュメントの取得用に1つのURLを提供します。WSDLには、そのプロデューサが提供するすべてのサービスが記述されています。各サービスのエンド・ポイントによって、コンシューマがプロデューサとの通信にトランスポート・レベルのセキュリティ(HTTPs)を使用する必要があるかどうかが指定されます。
WSRPは、プロデューサとコンシューマの間で交換されるすべてのメッセージでSOAP over HTTPを使用します。SOAP本体で標準メッセージ形式を使用するだけでなく、WSRPでは、コンシューマは、少なくとも、SOAPActionヘッダー、Cookieヘッダー、および通常のHTTPヘッダー(Content-Typeなど)を設定する必要があります。プロデューサは、セッションCookieとアプリケーション固有のCookieを、レスポンスのHTTPトランスポート・ヘッダーで返します。コンシューマは、後続のリクエスト・メッセージでそのセッションCookieを返す必要があります。
Service Busのコンポーネントは、Oracle JDeveloperとOracle Service Busコンソールのどちらでも構成できます。
WSRP対応のService Busの構成には、次のタスクが含まれます。
コンシューマが特定のプロデューサに対応するWSDLドキュメントを取得するために呼び出すことができるサービスを実装する。
コンシューマのリクエストをプロデューサに渡し、レスポンスをコンシューマに返す詳細を実装する。
次の各項では、プロキシ・サービスを通じてWSRPサービスにリクエストを送信するように、Service Busコンポーネントを構成する方法について説明します。プロデューサで提供されるサービスや、Service Busコンポーネントの構成に使用する必要があるWSRPのその他の属性についても説明します。最後には、詳細度の高いプロデューサのモニタリングと、WSRPによるロード・バランシングおよびフェイルオーバーについての情報を示します。
Oracle WebLogic Portalを使用してWSRP対応ポータルを作成する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドを参照してください。
通常、コンシューマは、プロデューサに直接アクセスしてWSDLドキュメントを取得します。ただし、Service Busをプロキシ・サービスとして使用している場合、プロデューサへのすべてのアクセスはService Busを介して行われます。このため、コンシューマ用のプロキシ・サービスを実装します。このプロキシ・サービスは、プロデューサの実際のURLを呼び出してプロデューサWSDLファイルを取得します。次のようにプロキシ・サービスは結果を変換します。
プロデューサのエンドポイントのアドレスを、Service BusのIPアドレスとポート番号を参照するように再作成する。
エンドポイントURIを変更し、必要なモニター・レベルを反映したプロキシ・サービスを参照する(「WSRPアプリケーションのモニター」を参照)。
エンドポイントのプロトコルとポート番号を変更し、コンシューマとプロキシ・サービスの間でトランスポート・セキュリティを使用するかどうかを反映する。
プロデューサの作成時に、そのプロデューサがSSLを要求するように構成できます("secure=true")。また、Service Bus管理者は、Service Bus構成でコンシューマに対するセキュリティ要件を変更できます。たとえば、プロデューサがSSLを要求しない場合は、次の手順を実行して、コンシューマにSSLの使用を要求できます。
WSDLファイルを変更して、HTTP(s)を指定します。
HTTP(s)を使用するように、WSRPプロキシ・サービスを構成します。
このように構成すると、Service Busは、コンシューマからの安全なメッセージとプロデューサが使用する安全でないメッセージを自動的に橋渡しします。
WSDLファイルのコピーを取得した後、コンシューマはWSDLの定義を使用してサービス・リクエストを作成し、Service Busを使用してプロデューサに送信します。WSRPのリクエスト/レスポンス・プロセスの手順は次のとおりです。
コンシューマが、プロデューサ・サービスに対応するService Busプロキシ・サービスにメッセージを送信します。
プロキシ・サービスは、メッセージをパイプラインに送信します。このパイプラインは、メッセージを(そのままの状態で)実際のプロデューサ・サービスにルーティングする、単純なメッセージ・フローを実行します。
プロデューサはレスポンスを作成し、Service Busを介してコンシューマに送信します。
コンシューマは、プロデューサからのレスポンスを(そのままの状態で)受信します。
WSRP Webサービスはポートレットを公開します。それらのポートレットはHTTPのCookieとセッションに依存する場合があります。そのため、HTTPトランスポート・ヘッダー(SOAPActionやCookieなど)を伝播するには、Service Busを構成する必要があります。ただし、プロキシ・サービスとビジネス・サービスが同じトランスポートを使用するとはかぎらないため、デフォルトでは、Service Busは、プロキシ・サービスからビジネス・サービスにトランスポート・ヘッダーを渡しません。そのため、リクエスト・ヘッダーを着信リクエストから発信リクエストにコピーするように、パイプラインを構成する必要があります。同様に、ビジネス・サービスのレスポンス・ヘッダーも、プロキシ・サービスからコンシューマへのレスポンスにコピーする必要があります。
プロキシ・サービスとビジネス・サービスの間で、すべての転送ヘッダーをコピーすることもできますが、選択的に転送ヘッダーコピーすることでエラーを回避できます。Set-CookieヘッダーとCookieヘッダーをコピーする必要があります。Service Busは最終メッセージをアセンブルして送信するため、最終メッセージには、いくつかの独自のヘッダー(Content-Lengthなど)が必要になります。たとえば、メッセージ・フローでContent-Lengthヘッダーをプロキシ・サービスからビジネス・サービスにコピーすると、処理中にメッセージの長さが変化したためにエラーになることがあります。そのため、Service Busはこのヘッダーを独自のものにする必要があります。
WSRPアプリケーションをモニターすることによって、プロデューサの個々のサービスと処理の使用状況を追跡します。WSRPサービスのメッセージ・フローのオーバーヘッドは非常に少なく、プロキシ・サービスとプロデューサ間のマッピング、およびビジネス・サービスとプロデューサ間のマッピングは容易に構成できます。そのため、SLA要件を満たすには、プロキシ・サービスをモニターするだけで十分です。
Service Busでは、ビジネス・サービスに、同じWebサービスを提供する複数のエンドポイントを定義できます。複数のエンドポイントを定義すると、Service Busでは、エンドポイント間でリクエストのロード・バランスを自動的に分散できます。また、1つのエンドポイントがアクセスできなくなると、リクエストを自動的にフェイルオーバーすることもできます。
ポートレットは、アプリケーションにユーザー・インタフェースを公開する手段であるため、通常、そのポートレットに関連付けられたセッション・データを保持します。セッション・データを保持するために、ポートレットへのリクエストは、元のリクエストを処理したものと同じサーバー(またはクラスタ)に送信される必要があります。この要件により、ビジネス・プロセスがHTTPセッション固定性に対応するように構成されていないかぎり、Service Busを介したロード・バランシングは不適切になります。ビジネス・サービスの複数のエンドポイントは、通常、異なるサーバーまたはクラスタをターゲットとします。構成されたセッション固定性がなければ、セッションを保存する方法はありません。これは、別々のクラスタにある複数のサーバー間で通信が行われないからです。そのため、WSRPビジネス・サービスに複数のエンドポイントを定義しており、セッション固定性を有効にしていない場合は、ロード・バランシングのアルゴリズムをnoneに設定する必要があります。
特定の環境では、複数のエンドポイントを使用して冗長性を確保し、エンドポイントの1つが使用できなくなった場合に備えることができます。2つ目のエンドポイントでWSRPサービスを利用できます。ただし、最初のエンドポイントが使用できなくなった時点のセッション・データは、他のエンドポイントでは使用できません。このフェイルオーバー構成は、単純なプロデューサのみのオプションであり、複雑なプロデューサでは使用できません(「WSRP WSDLドキュメント」を参照)。複雑なプロデューサでは、サービス・リクエストを送信する前に、コンシューマでプロデューサに登録する必要があります。プロデューサは登録ハンドルを返します。コンシューマは、そのプロデューサへの各リクエストにこのハンドルを含める必要があります。ビジネス・サービスに複数のエンドポイントが定義されている場合、各エンドポイントに個別の登録ハンドルが必要です。
ただし、Service Busは、リクエストとリクエストの間はステートレスであるため、特定のエンドポイントに送信するための正しいハンドルのマッピングは保持されません。実際、登録リクエストは1つのエンドポイントに送信されるので、コンシューマは1つのプロデューサにのみ登録されます。このプロデューサを使用できない場合、Service Busはサービス・リクエストをそのビジネス・サービスに定義されている別のエンドポイントにルーティングします。この新しいプロデューサにはコンシューマが登録されていないため、リクエストはInvalidRegistrationエラーで失敗します。
この状態データを維持するために、登録ハンドルの管理にはService Bus以外のアプリケーションが必要になるため、登録要件では複雑なプロデューサに対して複数のエンドポイントを定義しないでください。単純なプロデューサは、登録サービスをサポートしないため、ビジネス・サービスに対して複数のエンドポイントを定義するフェイルオーバー構成が可能です(ただし、フェイルオーバーの際にセッション・データが失われます)。
複数のエンドポイントを持つHTTPビジネス・サービスでのロード・バランシングの場合、セッション固定性を使用するようにサービスを構成できます(セッション・アフィニティとも呼ばれます)。固定セッションを使用するときには、そのセッションで最初のリクエストを処理したサーバーによってすべてのメッセージが処理されます。セッション固定性はサーバーを再起動する必要なく、実行時に構成できます。
そのセッションで最初のリクエストが送信されると、それはロード・バランシング・アルゴリズムに基づいて最初のURIエンドポイントに送られます。セッションIDは最初のリクエストを処理するURIエンドポイントと結び付けられ、URI表のセッションはそのURIインデックスにマップされます。同じセッション内の後続のリクエストは、ロード・バランシング・アルゴリズムに基づき選択されたはずのURIエンドポイントのかわりに、そのURIエンドポイントに送られます。
セッション固定性はビジネス・サービスの構成に応じて次のように動作します。
メッセージは、ビジネス・プロセスの再試行構成に基づき、同じURIエンドポイントで再試行されます。最大再試行回数に達するとURIエンドポイントはオフラインとマークされ、Service Busは例外をスローします。
ビジネス・サービスのURIエンドポイントがメッセージ・フローから動的に構成される場合、セッション固定性が有効になっていてもセッションは固定されません。
URIエンドポイントがオフラインの場合、セッション固定性はそれ以上維持されません。
サービスのURI表がセッションの途中で変更され、インデックスがURI表から外れると、TransportExceptionがエラー・コードTransportManager.TRANSPORT_STATUS_APPLICATION_ERRORとともにスローされます。
セッション固定性を持つようにビジネス・プロセスを構成するときには、リクエスト用のCookieヘッダーをインバウンドからアウトバウンドに、およびレスポンス用のCookieヘッダーをアウトバウンドからインバウンドに必ず転送してください。
