| Oracle® Fusion Middleware Oracle Service Bus管理者ガイド 11g リリース1(11.1.1.5.0) B61436-03 |
|
 前 |
Web Services for Remote Portlets (WSRP)は、ローカルのポータル・アプリケーションで表示するマークアップ・フラグメントをリモート・システムで生成するために使用されるメカニズムです。この章では、WSRPを使用するアプリケーションでOracle Service Busがサービス・レベル合意(SLA)モニター機能を提供するしくみについて説明します。
この項では、以下のトピックを取り上げます。
WSRPでは以下の2つのコンポーネントが不可欠です。
WSRPプロデューサ(このドキュメントではプロデューサと表記)は、SOAP over HTTP仕様を使用して標準ベースのWebサービスを実装するリモート・アプリケーションです。プロデューサは、WebLogic Portalまたはサード・パーティによるWSRP実装を使用して作成できます。
WSRPコンシューマ(このドキュメントではコンシューマと表記)は、ポータル・アプリケーションです。通常、コンシューマ・アプリケーションは、ポータル設計時にプロデューサのWSDLを参照し、コンシューマはプロデューサに直接アクセスします。
この項では、WSRPのアーキテクチャについて説明し、Oracle Service Busを追加してこのアーキテクチャを拡張する方法を示します。
図I-1は、プロデューサ・アプリケーションとコンシューマ・アプリケーション間のWSRP SOAPリクエストおよびレスポンス・フローを示します。
図I-1 プロデューサ・アプリケーションとコンシューマ・アプリケーション間の基本のリクエスト/レスポンス・フロー
図I-2は、Oracle Service Busを使用してプロデューサとコンシューマを仲介することにより、サービス・レベル・アグリーメント(SLA)モニター機能を提供する方法を示します。Oracle Service Busは、この方法で使用できます。
図I-2 Oracle Service Busによって拡張されたWSRPのリクエスト/レスポンス・フロー
WSRP SOAPリクエスト/レスポンス・フローは以下の順序で行われます。
インバウンド・リクエスト: コンシューマがOracle Service Busでプロキシ・サービスを呼び出します。
アウトバウンド・リクエスト: プロキシ・サービスがリクエスト(SOAP本体とトランスポート・ヘッダーを含むメッセージ)をプロデューサにルーティングします。
アウトバウンド・レスポンス: プロデューサがレスポンスをOracle Service Busに送信します。
インバウンド・レスポンス: プロキシ・サービスがレスポンスをコンシューマに送信します。レスポンスとは、SOAP本体とトランスポート・ヘッダーを含むメッセージです。
この項の後の部分では、プロキシ・サービスを介してWSRPサービスのリクエストを送信するようにOracle Service Busを構成する方法について説明します。プロデューサで提供されるサービスや、Oracle Service Busの構成のために使用する必要があるWSRPのその他の属性について説明します。また、プロデューサを詳しくモニターする方法についても説明します。最後に、WSRPでのロード・バランシングおよびフェイルオーバーについても説明します。
この項では、以下のWSRP設計の概念について説明します。
表I-0は、WSDLで提供されるサービスの種類を示します。WSDLは、「プロデューサ」と表記しています。
表I-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を返す必要があります。
Oracle Service Bus管理コンソールはOracle Service Busの構成に使用されます。Oracle WebLogic Portalを使用したWSRP対応ポータルの作成の詳細は、Oracle Fusion Middleware Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドを参照してください。
WSRP対応Oracle Service Busの構成には、以下のタスクが含まれます。
コンシューマが特定のプロデューサに対応するWSDLを取得するために呼び出すことができるサービスの実装
コンシューマのリクエストをプロデューサに渡し、レスポンスをコンシューマに返す詳細の実装
この章では、以下のタスクについて説明します。
通常、コンシューマは、プロデューサに直接アクセスしてWSDLを取得します。しかし、Oracle Service Busをプロキシ・サービスとして使用している場合、プロデューサへのすべてのアクセスはOracle Service Busを介して行われます。このため、コンシューマ用のプロキシ・サービスを実装します。このプロキシ・サービスは、プロデューサの実際のURLを呼び出してプロデューサWSDLを取得します。次のようにプロキシ・サービスは結果を変換します。
プロデューサのエンドポイントのアドレスを、Service BusのIPアドレスとポートを参照するように再作成する
エンドポイントURIを変更し、必要なモニター・レベルを反映したOracle Service Busプロキシ・サービスを参照する(I.4.3項「WSRPアプリケーションのモニター」を参照してください)。
エンドポイントのプロトコルとポートを変更し、コンシューマとOracle Service Busプロキシ・サービスの間でトランスポート・セキュリティを使用するかどうかを反映する
開発者がプロデューサを作成するときに、プロデューサでSSLが必要("secure=true")かどうかを指定できます。また、Oracle Service Bus管理者は、Oracle Service Bus構成を使用して、コンシューマに対するセキュリティ要件を変更できます。たとえば、プロデューサがSSLを要求しない場合は、Oracle Service Bus管理者は、次のようにしてコンシューマにSSLの使用を要求することができます。
WSDLを変更してHTTP(s)を指定する
プロキシ・サービスをWSRP対応にし、HTTP(s)を使用するように構成する
このように構成すると、Oracle Service Busは、コンシューマからの安全なメッセージとプロデューサが使用する安全でないメッセージを自動的に橋渡しします。
コンシューマは、WSDLのコピーを取得した後、WSDLの定義を使用してサービス・リクエストを作成し、Oracle Service Busを介してプロデューサに送信します。WSRPのリクエスト/レスポンス・プロセスの手順は以下のとおりです。
コンシューマが、プロデューサ・サービスに対応するOracle Service Busプロキシ・サービスにメッセージを送信します。
プロキシ・サービスは、メッセージを(そのままの状態で)実際のプロデューサ・サービスにルーティングする単純なメッセージ・フローを実行します。
プロデューサはレスポンスを作成し、Oracle Service Busを介してコンシューマに送信します。
コンシューマは、プロデューサからのレスポンスを(そのままの状態で)受信します。
WSRP Webサービスはポートレットを公開します。それらのポートレットはHTTPのCookieとセッションに依存する場合があります。そのため、HTTPトランスポート・ヘッダー(SOAPActionやCookieなど)を伝播するには、Oracle Service Busを構成する必要があります。ただし、プロキシ・サービスとビジネス・サービスが同じ転送を使用するとは限らないため、デフォルトでは、Oracle Service Busは、プロキシ・サービスからビジネス・サービスに転送ヘッダーを渡しません。そのため、要求ヘッダーを着信要求から発信要求にコピーするように、メッセージ・フローをコンフィグレーションする必要があります。同様に、ビジネス・サービスの応答ヘッダーも、プロキシ・サービスからコンシューマへの応答にコピーする必要があります。
すべてのトランスポート・ヘッダーをプロキシ・サービスとビジネス・サービスの間でコピーできますが、エラーを避けるために、コピーするトランスポート・ヘッダーを選択してください。Set-CookieヘッダーとCookieヘッダーをコピーする必要があります。最終メッセージは、いくつかのヘッダー(Content-Lengthなど)を保持する必要があります。これは、Oracle Service Busは最終送信メッセージをアセンブルするエンティティであるためです。たとえば、メッセージ・フローでContent-Lengthヘッダーをプロキシ・サービスからビジネス・サービスにコピーすると、処理中にメッセージの長さが変化したためにエラーになることがあります。そのため、Oracle Service Busはヘッダーを保持する必要があります。
WSRPアプリケーションをモニターすることによって、プロデューサの個々のサービスと処理の使用状況を追跡します。WSRPサービスのメッセージ・フローのオーバーヘッドは非常に少なく、プロキシ・サービスとプロデューサ間のマッピング、およびビジネス・サービスとプロデューサ間のマッピングは容易に構成できます。そのため、SLA要件を満たすには、プロキシ・サービスをモニターするだけで十分です。
WSRPアプリケーションのモニターの詳細は、第46章「実行時のOracle Service Busのモニター」を参照してください。
Oracle Service Busでは、ビジネス・サービスに、同じWebサービスを提供する複数のエンドポイントを定義できます。複数のエンドポイントを定義すると、Oracle Service Busでは、エンドポイント間で要求のロード・バランスを自動的に調整できます。また、1つのエンドポイントがアクセスできなくなると、要求を自動的にフェイルオーバーすることもできます。ただし、WSRPではこれらの機能の使用が一部制限されます。
ポートレットは、アプリケーションにユーザー・インタフェースを提供する手段です。そのため、通常、ポートレットには、セッション・データが関連付けられています。セッション・データを保持するために、ポートレットへのリクエストは、元のリクエストを処理したものと同じサーバー(またはクラスタ)に送信される必要があります。この要件により、Oracle Service Busでのロード・バランシングは適していません。ビジネス・サービスの複数のエンドポイントは、通常、異なるサーバーまたはクラスタを対象とします。別のクラスタ内に存在するサーバー間では通信は行われないため、セッションを保持する方法はありません。そのため、WSRPビジネス・サービスに複数のエンドポイントを定義している場合、ロード・バランシングのアルゴリズムはnoneに設定する必要があります。
特定の環境では、複数のエンドポイントを使用して冗長性を確保し、エンドポイントの1つが使用できなくなった場合に備えることができます。2つ目のエンドポイントでWSRPサービスを利用できます。ただし、最初のエンドポイントが使用できなくなった時点のセッション・データは、他のエンドポイントでは使用できません。
このフェイルオーバー構成は、単純なプロデューサでのみ使用できるオプションです(I.3.1項「WSRP WSDL」を参照)。複雑なプロデューサでは使用できません。複雑なプロデューサでは、サービス要求を送信する前に、コンシューマでプロデューサに登録する必要があります。プロデューサは登録ハンドルを返します。コンシューマは、そのプロデューサへの各要求にこのハンドルを含める必要があります。ビジネス・サービスに複数のエンドポイントが定義されている場合、各エンドポイントに個別の登録ハンドルが必要です。
ただし、Oracle Service Busは、リクエストとリクエストの間はステートレスであるため、特定のエンドポイントに送信するための正しいハンドルのマッピングは保持されません。実際、登録リクエストは1つのエンドポイントに送信されるので、コンシューマは1つのプロデューサにのみ登録されます。このプロデューサを使用できない場合、Oracle Service Busはサービス・リクエストをそのビジネス・サービスに定義されている別のエンドポイントへルーティングします。しかし、この新しいプロデューサにはコンシューマが登録されていないため、リクエストはInvalidRegistrationエラーで失敗します。
登録ハンドルの管理では、この状態データを保持するために、Oracle Service Bus以外のアプリケーションが必要になります。そのため、この登録要件により、複雑なプロデューサに複数のエンドポイントを定義できません。単純なプロデューサは、登録サービスをサポートしないため、ビジネス・サービスに複数のエンドポイントを定義するフェイルオーバー・コンフィグレーションが可能です。
この項では、WSRP 2.0相互運用の例について説明します。
この項では、以下のトピックを取り上げます。
WSRP相互運用の例では、以下のコンポーネントと構成を想定しています。
WebLogic Platform 10.3
WebLogic Portal 10.3
Oracle Service Bus 10gR3
platform:7001で構成されたサンプル・プラットフォーム・ドメイン
alsb:7001で構成されたOracle Service Busドメイン
サンプル・ポータル・アプリケーション・コンシューマ
サンプル・プロデューサ
サンプルの構造は、2つのプロジェクトに分割されます。共通リソースを含むプロジェクト、およびサンプル・プロデューサのリソースを含むプロジェクトです。
表I-2 WSRP相互運用の例のプロジェクト
| フォルダ | 説明 |
|---|---|
|
wsrp |
プロデューサ固有ではない共通のリソースを含みます。 |
|
operationExample |
最も高レベルのモニターをサポートする詳細な例。フォルダには、プロデューサ固有のリソースが含まれます。I.5.3項「モニターの例」を参照してください。 |
モニター構成の例(operationExample folder内)では、プロデューサのすべてのサービスと操作をモニターするように、Oracle Service Busを構成します。
モニター構成では、使用するビジネス・サービスとプロキシ・サービスが、WSRP標準で定義されているWSDLに基づいています。この項では、次のトピックについて説明します。
すべてのWSRP WSDL定義ファイルと、その定義が依存しているXMLスキーマ・ファイルをインポートします。ファイルはすべて、この例に対応するサンプル・コードの一部として用意されています。標準リソースの場所は表I-3のとおりです。
表I-3 WSDLリソース定義
| リソース名 | 種類 | 場所 |
|---|---|---|
|
xml-2.0 |
XMLスキーマ |
http://platform:7001/producer/producer/wsrp-2.0/markup?WSDL/xml.xsd |
|
wsrp-2.0-types |
XMLスキーマ |
http://platform:7001/producer/producer/wsrp-2.0/markup?WSDL/wsrp-2.0-types.xsd |
|
wsrp-2.0-interfaces |
WSDL |
http://platform:7001/producer/producer/wsrp-2.0/markup?WSDL/wsrp-2.0-interfaces.wsdl |
|
wsrp-2.0-bindings |
WSDL |
http://platform:7001/producer/producer/wsrp-2.0/markup?WSDL/wsrp-2.0-bindings.wsdl |
|
wsrp-2.0-wsdl |
WSDL |
http://platform:7001/producer/producer/wsrp-2.0/markup?WSDL |
BEA Portalで生成されたプロデューサは、追加ポートを定義して標準WSDLを拡張し、MIME添付を使用してメッセージを送信できるようにします。プロデューサのWSDLが拡張リソースを参照する場合は、拡張リソースの定義が必要です。この例では、オプションのタスクで、プロデューサで使用されるWSDLのリソースを作成します。これらのWSDLリソースとXMLスキーマ・リソースを作成した後、各リソースの参照を編集して他のリソースとの依存関係を解決します。
このモニターの例では、プロデューサが実装するポート・タイプごとにWSDLバインディングを使用します。1つのビジネス・サービスには1つのWSDLポートまたはバインディングしか関連付けられないため、ビジネス・サービスごとに個別のビジネス・サービス・リソースを作成する必要があります。単純なプロデューサでは、必須のマークアップとサービス記述のインタフェースしか実装されませんが、複雑なプロデューサでは、管理と登録のインタフェースも実装されます。これらのサービスの作成方法は同じです。ただし、表I-4に示すように、サービス名とサービスのタイプが異なります。
表I-4 ビジネス・サービスの構成
| サービス名 | サービス・タイプ |
|---|---|
|
base |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port="WSRPBaseService" |
|
desc |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port=" WSRPServiceDescriptionService" |
|
mgmt |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port=" WSRPPortletManagementService |
|
reg |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port=" WSRPRegistrationService" |
サービスごとに要求される属性は、表I-5に示すとおりです。
表I-5 ビジネス・サービスのサービス属性
| 名前 | 値 | コメント |
|---|---|---|
|
プロトコル |
HTTP |
プロデューサがsecure= |
|
ロード・バランシング・アルゴリズム |
なし |
|
|
エンドポイントURI |
サービス記述: http://host*:port+/producer/producer/wsrp-2.0/serviceDescription マークアップ: http://host*:port+/producer/producer/wsrp-2.0.0/markup 登録: http://host*:port+/producer/producer/wsrp-2.0/registration ポートレット管理: http://host*:port+/producer/producer/wsrp-2.0/portletManagement |
複数のエンドポイントは、WSRPプロデューサに定義する必要があります。 |
このモニターの例では、次のようにプロキシ・サービスを構成しています。
ビジネス・サービスがWSDLベースであるため、プロキシ・サービスも同じWSDLをベースにしている必要があります。
ビジネス・サービスごとに1つのプロキシ・サービスを作成するが、各プロキシ・サービスのURIは異なる必要があります。
呼び出される操作を構成で指定する必要があります。
プロキシ・サービスを作成するには:
ベースになるWSRPサービスにプロキシ・サービスを作成します。
前の例と同様に、既存のoperationExample/baseビジネス・サービスをモデルとして使用し、プロキシ・サービスを作成します。このモデルによって、ビジネス・サービスと同じWSDLバインディングをベースとするプロキシ・サービスが作成され、ビジネス・サービスへの条件なしのルート・アクションを含むメッセージ・フローが作成されます。エンドポイントURIについては、ポート・タイプの略語をプロデューサ名に付ける(たとえば、/operationExampleBase)など、任意に使用できます。
メッセージ・フローを編集し、コンシューマとプロデューサ間でリクエスト・トランスポート・ヘッダーとレスポンス・トランスポート・ヘッダーをコピーするのに必要な、同じトランスフォーメーションを追加します。
WSRPは、正常に機能するために、トランスポート・ヘッダーで渡されるデータに依存します。特に、プロデューサは、レスポンス・ヘッダーで、コンシューマがそれ以降のリクエストに指定すると想定するセッションCookieをコンシューマに返します。同様に、プロデューサは、コンシューマがSOAPActionリクエスト・ヘッダーにリクエスト操作を指定することを想定します。
デフォルトでは、Oracle Service Busは、トランスポート・ヘッダーをインバウンド・リクエストからアウトバウンド・リクエストに、またはアウトバウンド・レスポンスからインバウンド・レスポンスにコピーしません。メッセージ・フローで、必要なヘッダーをビジネス・サービスに伝播し、ビジネス・サービスから必要なヘッダーを伝播する必要があります。
|
注意: トランスポートからすべてのヘッダーを取得するには、Oracle Service Busプロキシの「トランスポート構成」ページにある「すべてのヘッダーを取得」フィールドで、「はい」を選択します。詳細については、20.2.3項「「トランスポート構成」ページ」を参照してください。メッセージ・フローのルート・ノードで、リクエスト・アクションとレスポンス・アクションにトランスポート・ヘッダーを追加し、「パイプラインを介してすべてのヘッダーを渡す」オプションを有効にします。詳細については、22.7項「トランスポート・ヘッダー・アクションの追加」を参照してください。content-lengthがコピーされていないことがOracle Service Busによって自動的に確認されます。 |
図I-3に示すように、Oracle Service Bus管理コンソールを使用してビジネス・サービスへのルーティングを構成するとき、ルート・ノードを編集して低レベルXQuery処理を避けるには、「インバウンド操作のアウトバウンドでの使用」チェック・ボックスを選択する方法もあります。
このトランスフォーメーションで、ビジネス・サービスの操作がプロキシ・サービスに指定されていたのと同じ値に動的に設定されます。これにより、Oracle Service Busを使用してサービスのすべての操作をカウントしてモニターできるようになります。
これ以外のビジネス・サービス用のプロキシ・サービスは、同じ手順を繰り返して作成できます。ただし、すべてのトランスフォーメーションを手動で再作成せずに済む簡単な方法もあります。
たとえば、サービス記述サービス用のプロキシ・サービスを作成するには、以下の手順を実行します。
作成したoperationExample/baseプロキシ・サービスをモデルとして新しいプロキシ・サービスを作成します。この例に従い、エンドポイントURIには/operationExampleDescを使用します。
「サマリー」ページで、全般的な構成の「編集」リンクをクリックします。WSDLバインディングがBaseポートを使用して作成されています。このバインディングがWSRPServiceDescriptionServiceポートを参照するように変更します。
メッセージ・フローを編集します。ルート・アクションがbaseビジネス・サービスを参照しています。descサービスへのルート・アクションを変更します。
|
注意: トランスポート・ヘッダー・アクションを使用して、低レベルXQuery操作を最小化し、プロキシ・サービスの構成を簡略化します。詳細については、22.7項「トランスポート・ヘッダー・アクションの追加」を参照してください。 |
サービスごとのプロキシ・サービス構成は、表I-6に示すとおりです。
表I-6 プロキシ・サービスの構成
| サービス名 | サービス・タイプ |
|---|---|
|
proxyBase |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port="WSRPBaseService" |
|
proxyDesc |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port=" WSRPServiceDescriptionService" |
|
proxyMgmt |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port=" WSRPPortletManagementService" |
|
proxyReg |
WSDL port: operationExample-2.0/wsrp-2.0-wsdl, port=" WSRPRegistrationService" |
プロキシ・サービスごとに要求される属性は、表I-7に示すとおりです。
プロデューサからWSRP 2.0固有のWSDLを取得し、実際のプロデューサのエンドポイントを隠すように変換するサービスを作成します。この例では、各プロデューサのプロキシのURIが異なります。また、この項では、プロデューサのWSDLを取得するためにリソースを作成する方法について説明します。
プロデューサからWSDLを取得するためにビジネス・サービスを作成します。このリソースはプロデューサ固有であるため、operationExampleプロジェクト内に作成する必要があります。表I-8は、ビジネス・サービスのプロパティを示します。
表I-8 ビジネス・サービスの構成プロパティ
| 名前 | 値 | コメント |
|---|---|---|
|
サービス名 |
wsdlSvc 2.0 |
任意の名前を付けることができます。 |
|
サービス・タイプ |
任意のXMLサービス |
コンシューマは通常、HTTP GETリクエストを使用してプロデューサからWSDLを取得します。GETをサポートするのはXMLサービスのみです。 |
|
プロトコル |
HTTP |
HTTP |
|
ロード・バランシング・アルゴリズム |
なし |
優先なし。 |
|
エンドポイントURI |
http://platform:7001/producer/producer/wsrp-2.0/markup?WSDL |
複数のエンドポイントを指定してWSDLを取得できますが、それによる追加の用途や利点はありません。 |
|
HTTPリクエスト・メソッド |
GET |
プロデューサのWSDLにあるすべてのエンドポイント・アドレスを、Oracle Service Busサーバーのアドレスとプロキシ・サービスのURIの値を表すように変換する必要があります。プロデューサの各WSDLにはポートが4つ以上定義されている可能性があるため、XQuery式を作成してエンドポイント位置の構成を簡略化する必要があります。XQuery式は次の3つの文字列変数を入力として受け取り、連結してSOAPアドレス要素を形成します。
Oracle Service BusサーバーのベースURL
プロデューサを示す名前
プロデューサのポートを区別するための拡張子
表I-9に、wsrpプロジェクトでの問合せの定義を示します。
何も実行しないサービスを作成します。このサービスを作成するには、wsrpプロジェクト・フォルダにリソース名nullSvcとして新しいプロキシ・サービスを定義します。このサービスではすべてデフォルトを受け入れます。このプロキシ・サービスを構成すると、1つのエコー・ノードを含むサービスのメッセージ・フローが作成されます。
プロデューサからWSDLを取得するためにコンシューマが使用するプロキシ・サービスを作成します。このプロキシ・サービスは、このサンプルで作成されるすべてのプロデューサ・コンフィグレーションに対応します。この項の例は提案に過ぎません。実装固有の要件に基づいた別の方法が必要になります。このプロキシ・サービスは、1つのプロデューサに固有のものでないため、wsrpプロジェクト・フォルダ内に作成する必要があります。
この手順で使用する方法では、管理者が各プロデューサに名前を割り当てる必要があります。この名前は、WSDL取得用URLの一部になります。
プロキシ・サービスのメッセージ・フローがURLから名前を抽出し、その名前を使用してそのプロデューサ固有のビジネス・サービスを検索し、WSDLを取得します。その後、WSDLを変換してOracle Service Busへのエンドポイントを再作成します。
プロキシ・サービスのエンドポイントURIは、/getWSDLとして構成され、コンシューマがWSDLを取得するために使用するURLは次のようになります。
http://alsb:7001/getWSDL/<producerName>
<producerName>は、管理者がプロデューサに割り当てた名前です。この例では、プロデューサはoperationExampleです。
表I-10は、プロキシ・サービスgetWSDL2.0の構成のプロパティを示します。
表I-10 プロキシ・サービスの構成プロパティ
| プロパティ名 | 値 |
|---|---|
|
サービス名 |
getWSDL2.0 任意の名前を付けることができます。 |
|
サービス・タイプ |
任意のXMLサービス |
|
プロトコル |
HTTP |
|
エンドポイントURI |
/getWSDL2.0 |
このプロキシ・サービスのメッセージ・フローは、1つのパイプライン・ペアと1つのルート・ノードで構成されます。パイプライン・ペアのリクエスト側は1つのステージで構成され、そのジョブは、プロデューサ名をURLから抽出してコンテキスト変数に割り当てることです。アクションは次のとおりです。
Assign $inbound/ctx:transport/ctx:request/http:relative-URI to variable producerName
メッセージ・フローのレスポンス側は、すべてのトランスフォーメーションを実行するステージです。置換アクションを実行してWSDLを変換する前に、次のようにOracle Service BusサーバーのベースURLをコンテキスト変数に割り当てて、トランスフォーメーションのたびに指定しなくてもよいようにします。
Assign "http://alsb:7001/" to variable nonSecureBaseURL
レスポンス・パイプラインのステージを編集して、指定のエンドポイントURIを前に作成したプロキシに一致させるトランスフォーメーションを実行するように、各置換アクションを変更します。この例で作成したプロキシの名前は、プロデューサ名にサービスのタイプの略称を付けたものです。前に作成したaddr XQueryリソースは、拡張子引数を受け入れ、URIの位置を構成します。表I-11のように、引数を適切な値に変更してください。
表I-11 URIの位置を構成する拡張子の設定
| @binding | addrのサービス引数 |
|---|---|
WSRP_v2_Markup_Binding_SOAP |
"Base" |
WSRP_v2_ServiceDescription_Binding_SOAP |
"Desc" |
WSRP_v2_PortletManagement_Binding_SOAP |
"Mgmt" |
WSRP_v2_Registration_Binding_SOAP |
"Reg" |
WLP_WSRP_v2_Markup_Ext_Binding_SOAP |
"Ext" |
表num_xref、I.2項の「プロデューサ・アプリケーションとコンシューマ・アプリケーション間の基本のリクエスト/レスポンス・フロー」にあるサービス引数のマッピングと同様に、name:を$producerNameにマッピングし、BaseURLを$nonSecureBaseURLにマッピングする必要があります。
5つの置換アクションは、次のコード・リストのように定義されます。nameの値は、表のバインディング名で置換されます。
Replace ./*[local-name()="definitions"]/*[local-name()="service"]/*[local-name()="port"][ends-with(attribute::binding,"name")]/*[local-name()="address" Replace entire node name WSRP_v2_Markup_Binding_SOAP WSRP_v2_ServiceDescription_Binding_SOAP WSRP_v2_PortletManagement_Binding_SOAP WSRP_v2_Registration_Binding_SOAP
最初の置換アクションに、表I-12のユーザー・ネームスペース定義を追加する必要があります。
表I-12 置換アクションのユーザー・ネームスペース定義
| 接頭辞 | ネームスペース |
|---|---|
|
wsdl |
http://schemas.xmlsoap.org/wsdl/ |
|
soap |
http://schemas.xmlsoap.org/wsdl/soap/ |
このメッセージ・フローのルート・ノードは、$producerNameに基づいてケースを選択するルーティング・テーブルで構成されます。認識されている各プロデューサにケースを追加し、名前が一致すると、ケースがそれぞれ適切なビジネス・サービスにルーティングされてWSDLを取得するようにします。この例では次のディレクティブを使用します。
= "operationExample" Route to wsdlSvc
不明なプロデューサ名が指定されたケースを処理するには、次のように、操作のないサービスにルーティングする デフォルト・ケース を追加します。
Default Route to nullSvc
この例では、次のようなレスポンス・アクションをデフォルト・ケースに追加して、HTTP 404ステータス・コードを返します。
Insert <http:http-response-code>404</http:http-response-code> as last child of ./ctx:transport/ctx:response in variable inbound Reply With Failure
ルート・ノードのルーティング・テーブルを編集して、ケースがシステムで認識されているプロデューサに対応するようにします。
getWSDL2.0プロキシ・サービスのメッセージ・フローは、1つのパイプライン・ペアと1つのルート・ノードで構成されます。このプロキシ・サービスのメッセージ・フローを定義するには、次の操作を行います。
パイプライン・ペアを作成します。
パイプライン・ペアのリクエスト側を編集します。
パイプライン・ペアのリクエスト側は1つのステージで構成され、そのジョブは、プロデューサ名をURLから抽出してコンテキスト変数に割り当てることです。これを行うには、割当てアクションを次のように追加します。
変数producerNameに$inbound/ctx:transport/ctx:request/http:relative-URIを割り当てる
パイプライン・ペアのレスポンス側を編集します。
メッセージ・フローのレスポンス側は、すべてのトランスフォーメーションを実行するステージです。
トランスフォーメーションのたびにOracle Service BusサーバーのベースURLを指定しなくてもよいように、ベースURLをコンテキスト変数に割り当てる割当てアクションを次のように作成します。
変数nonSecureBaseURLにhttp://alsb:7001/を割り当てる
前の手順で作成した対応するプロキシ・サービスを指すように、レスポンスWSDLのURLを変更する置換アクションを作成します。置換アクションは、次の方法で追加します。
置換アクションを追加します。
Xpathで、次を指定します。
./*[local-name()="definitions"]/*[local-name()="service"]/*[local-name()="port"][ends-with(attribute::binding,"WSRP_v2_Markup_Binding_SOAP")]/*[local-name()="address"][starts-with(attribute::location,"http:")]
テキスト・ボックスで変数bodyを指定します。
式で、(WSRP 1.0構成の一部として前の手順で追加した)XQueryリソースaddrを選択し、svcをBase-2.0、baseURLを$nonSecureBaseURL、nameを$producerNameにそれぞれ設定します。
「ノード全体を置換」オプションを選択します。
次の表に示すように、残りの置換アクションを作成します。
| XPathにおける属性バインディング | addr Xqueryのサービス引数 |
|---|---|
WSRP_v2_Markup_Binding_SOAP |
"Base-2.0" |
WSRP_v2_ServiceDescription_Binding_SOAP |
"Desc-2.0" |
WSRP_v2_PortletManagement_Binding_SOAP |
"Mgmt-2.0" |
WSRP_v2_Registration_Binding_SOAP |
"Reg-2.0" |
パイプライン・ペアにルート・ノードを追加します。このメッセージ・フローのルート・ノードは、$producerNameに基づいてケースを選択するルーティング・テーブルで構成されます。認識されている各プロデューサにケースを追加し、名前が一致すると、ケースがそれぞれ適切なビジネス・サービスにルーティングされてWSDLを取得するようにします。この例では次のディレクティブを使用します。
= "operationExample" Route to wsdlSvc-2.0
不明なプロデューサ名が指定されたケースを処理するには、次のように、操作のないサービスにルーティングするデフォルト・ケースを追加します。
Default Route to nullSvc
この例では、次のようなレスポンス・アクションをデフォルト・ケースに追加して、HTTP 404ステータス・コードを返します。
<http:http-response-code>404</http:http-response-code>を、変数inboundの./ctx:transport/ctx:responseの最後の子として挿入します。
Reply With Failure
ルート・ノードのルーティング・テーブルを編集して、ケースがシステムで認識されているプロデューサに対応するようにします。
プロデューサを使用するために、コンシューマは自身のWSDLを使用してプロデューサを登録する必要があります。デフォルトでは、WSDLはWSRPバージョン1.0を使用します。コンシューマがWSRPバージョン2.0を使用するには、WSRPバージョン2.0を使用するプロデューサWSDLをコンシューマが使用できるようにする必要があります。一般に、デフォルトのプロデューサWSDL (WSRP 1.0を使用するWSDL)は、WSRPバージョン2.0を使用するWSDLへのリンクを含みます。このリンクにより、コンシューマはWSRPバージョン2.0のWSDLを使用できます。
getWSDLプロキシ・サービスは、WSRPバージョン1.0を使用するプロデューサのWSDLを提供します。このWSDLは、WSRPバージョン2.0を使用する同じプロデューサのWSDLのURLを含みます。これは、プロデューサのWSDLの直接URLです。直接URLを使用するかわりに、getWSDL2.0プロキシ・サービスを使用するOracle Service Busを介してWSDLにアクセスする必要があります。これは、次の方法で行います。
WSRP 2.0を使用するWSDLのURLを構成するXQueryリソースを作成します。
リソース名: import
Xquery:
declare variable $baseURL external;
declare variable $name external;
declare variable $svc external;
<import location="{concat($baseURL, $svc, $name )}" namespace="urn:oasis:names:tc:wsrp:v2:wsdl" xmlns="http://schemas.xmlsoap.org/wsdl/" />
getWSDLプロキシ・サービスのメッセージ・フローのレスポンス側に置換アクションを追加します。この置換アクションは、getWSDL2.0プロキシ・サービスのエンドポイントURIへのレスポンスでWSDLのURLを置き換えます。これは、次の方法で行います。
置換アクションを追加します。
Xpathで、次を指定します。
./*[local-name()="definitions"]/*[local-name()="import"][ends-with(attribute::location,"/producer/wsrp-2.0/markup?WSDL")]
テキスト・ボックスで、変数bodyを指定します。
式で、XQueryリソースimportを選択し、svcをgetWSDL2.0、baseURLを$nonSecureBaseURL、nameを$producerNameにそれぞれ設定します。
「ノード全体を置換」オプションを選択します。
構成が完了したら、次のように確認します。
通常のブラウザ・ウィンドウに次のURLを入力して、WSDLを取得します。
http://alsb:7001/getWSDL/operationExample
エンドポイントWSRPのすべてのエンドポイントURL (BEA拡張機能サービス以外)が、Oracle Service Busサーバーのプロキシ・サービスの値を正しく参照するように変更されていることを確認します。
このURLをプロデューサのWSDLのアドレスとして指定して、ポータル・コンシューマ・アプリケーションにリモート・ポートレットを作成します。
リモート・ポートレットを作成するには、EclipseまたはPortal Administration Toolを使用します。WSDL取得時に入力するURLが異なる点を除き、このポートレットを作成する手順は、Oracle Service Busが仲介しないポートレットの作成手順と同じです。
コンシューマ・ポータルが完成したら、アプリケーションを実行します。
選択したOracle Service Busコンポーネントのモニターを有効にします。
Oracle Service Bus管理コンソールを使用して、プロデューサが処理するすべてのWSRPサービスおよび操作に関するメッセージ件数やパフォーマンス統計を詳しく表示します。
