|
|
この節では、WSRP 2.0 相互運用の例を示します。WSRP 1.0 相互運用の例については、BEA AquaLogic Service Bus 2.6 ドキュメントの「WSRP 相互運用の例」を参照してください。
WSRP 相互運用の例では、以下のコンポーネントとコンフィグレーションを想定しています。
サンプルの構造は、2 つのプロジェクトに分割されます。共通リソースを含むプロジェクト、およびサンプル プロデューサのリソースを含むプロジェクトです。
モニタ コンフィグレーションの例 (operationExample folder 内) では、プロデューサのすべてのサービスと操作をモニタするように、Oracle Service Bus をコンフィグレーションします。
モニタ コンフィグレーションでは、使用するビジネス サービスとプロキシ サービスが、WSRP 標準で定義されている WSDL に基づいています。この節では、次のトピックについて説明します。
すべての WSRP WSDL 定義ファイルと、その定義が依存している XML スキーマ ファイルをインポートします。ファイルはすべて、この例に対応するサンプル コードの一部として用意されています。標準リソースの場所は表 3-2 のとおりです。
BEA Portal で生成されたプロデューサは、追加ポートを定義して標準 WSDL を拡張し、MIME 添付を使用してメッセージを送信できるようにします。プロデューサの WSDL が拡張リソースを参照する場合は、拡張リソースの定義が必要です。この例では、オプションのタスクで、プロデューサで使用される WSDL のリソースを作成します。これらの WSDL リソースと XML スキーマ リソースを作成した後、各リソースの参照を編集して他のリソースとの依存関係を解決します。
このモニタの例では、プロデューサが実装するポート タイプごとに WSDL バインディングを使用します。1 つのビジネス サービスには 1 つの WSDL ポートまたはバインディングしか関連付けられないため、ビジネス サービスごとに個別のビジネス サービス リソースを作成する必要があります。単純なプロデューサでは、必須のマークアップとサービス記述のインタフェースしか実装されませんが、複雑なプロデューサでは、管理と登録のインタフェースも実装されます。これらのサービスの作成方法は同じです。ただし、表 3-3 に示すように、サービス名とサービスのタイプが異なります。
サービスごとに要求される属性は、表 3-4 に示すとおりです。
このモニタの例では、次のようにプロキシ サービスをコンフィグレーションしています。
前の例と同様に、既存の operationExample/base ビジネス サービスをモデルとして使用し、プロキシ サービスを作成します。このモデルによって、ビジネス サービスと同じ WSDL バインディングをベースとするプロキシ サービスが作成され、ビジネス サービスへの条件なしのルート アクションを含むメッセージ フローが作成されます。エンドポイント URI については、ポート タイプの略語をプロデューサ名に付ける (たとえば、/operationExampleBase) など、任意に使用できます。
SOAPAction 要求ヘッダに要求操作を指定することを想定します。
デフォルトでは、Oracle Service Bus は、転送ヘッダを着信要求から発信要求に、または発信応答から着信応答にコピーしません。メッセージ フローで、必要なヘッダをビジネス サービスに伝播し、ビジネス サービスから必要なヘッダを伝播する必要があります。
| 注意 : | 転送からすべてのヘッダを取得するには、Oracle Service Bus プロキシの [転送コンフィグレーション] ページにある [すべてのヘッダを取得] フィールドで [はい] を選択します。詳細については、『Oracle Service Bus Console の使い方』の「転送コンフィグレーション ページ」を参照してください。 |
| 注意 : | メッセージ フローのルート ノードで、要求アクションと応答アクションに転送ヘッダを追加し、[パイプラインを介してすべてのヘッダを渡す] オプションを有効にします。詳細については、『Oracle Service Bus Console の使い方』の「転送ヘッダ アクションの追加」参照してください。content-length がコピーされていないことが Oracle Service Bus によって自動的に確認されます。 |
このトランスフォーメーションで、ビジネス サービスの操作がプロキシ サービスに指定されていたのと同じ値に動的に設定されます。これにより、Oracle Service Bus を使用してサービスのすべての操作をカウントしてモニタできるようになります。
これ以外のビジネス サービス用のプロキシ サービスは、同じ手順を繰り返して作成できます。ただし、すべてのトランスフォーメーションを手動で再作成せずに済む簡単な方法もあります。
たとえば、サービス記述サービス用のプロキシ サービスを作成するには、以下の手順を実行します。
operationExample/base プロキシ サービスをモデルとして新しいプロキシ サービスを作成します。この例に従い、エンドポイント URI には /operationExampleDesc を使用します。WSRPServiceDescriptionService ポートを参照するように変更します。desc サービスへのルート アクションを変更します。| 注意 : | 転送ヘッダ アクションを使用して、低レベル XQuery 操作を最小化し、プロキシ サービスのコンフィグレーションを簡略化します。詳細については、Oracle Service Bus Console のオンライン ヘルプの転送ヘッダの節を参照してください。 |
サービスごとのプロキシ サービス コンフィグレーションは、表 3-5 に示すとおりです。
プロキシ サービスごとに要求される属性は、表 3-7 に示すとおりです。
プロデューサから WSRP 2.0 固有の WSDL を取得し、実際のプロデューサのエンドポイントを隠すように変換するサービスを作成します。この例では、各プロデューサのプロキシの URI が異なります。また、この節では、プロデューサの WSDL を取得するためにリソースを作成する方法について説明します。
プロデューサから WSDL を取得するためにビジネス サービスを作成します。このリソースはプロデューサ固有であるため、operationExample プロジェクト内に作成する必要があります。表 3-7 は、ビジネス サービスのプロパティを示します。
プロデューサの WSDL にあるすべてのエンドポイント アドレスを、Oracle Service Bus サーバのアドレスとプロキシ サービスの URI の値を表すように変換する必要があります。プロデューサの各 WSDL にはポートが 4 つ以上定義されている可能性があるため、XQuery 式を作成してエンドポイント位置の構成を簡略化する必要があります。XQuery 式は次の 3 つの文字列変数を入力として受け取り、連結して SOAP アドレス要素を形成します。
表 3-8 に、wsrp プロジェクトでのクエリの定義を示します。
何も実行しないサービスの作成このサービスを作成するには、wsrp プロジェクト フォルダにリソース名 nullSvc として新しいプロキシ サービスを定義します。このサービスではすべてデフォルトを受け入れます。このプロキシ サービスをコンフィグレーションすると、1 つのエコー ノードを含むサービスのメッセージ フローが作成されます。
プロデューサから WSDL を取得するためにコンシューマが使用するプロキシ サービスを作成します。このプロキシ サービスは、このサンプルで作成されるすべてのプロデューサ コンフィグレーションに対応します。この節の例は提案に過ぎません。実装固有の要件に基づいた別の方法が必要になります。このプロキシ サービスは、1 つのプロデューサに固有のものでないため、wsrp プロジェクト フォルダ内に作成する必要があります。
/getWSDL としてコンフィグレーションされ、コンシューマが WSDL を取得するために使用する URL は次のようになります。
http://alsb:7001/getWSDL/<producerName>
<producerName> は、管理者がプロデューサに割り当てた名前です。この例では、プロデューサは operationExample です。
表 3-9 は、プロキシ サービス getWSDL2.0 コンフィグレーションのプロパティを示します。
このプロキシ サービスのメッセージ フローは、1 つのパイプライン ペアと 1 つのルート ノードで構成されます。パイプライン ペアの要求側は 1 つのステージで構成され、そのジョブは、プロデューサ名を URL から抽出してコンテキスト変数に割り当てることです。アクションは次のとおりです。
変数 producerName に $inbound/ctx:transport/ctx:request/http:relative-URI を割り当てる
メッセージ フローの応答側は、すべてのトランスフォーメーションを実行するステージです。置換アクションを実行して WSDL を変換する前に、次のように Oracle Service Bus サーバのベース URL をコンテキスト変数に割り当てて、トランスフォーメーションのたびに指定しなくてもよいようにします。
変数 nonSecureBaseURL に "http://alsb:7001/" を割り当てる
応答パイプラインのステージを編集して、指定のエンドポイント URI を前に作成したプロキシに一致させるトランスフォーメーションを実行するように、各置換アクションを変更します。この例で作成したプロキシの名前は、プロデューサ名にサービスのタイプの略称を付けたものです。前に作成した addr XQuery リソースは、拡張子引数を受け入れ、URI の位置を構成します。表 3-10 のように、引数を適切な値に変更してください。
表 3-10 「URI の位置を構成する拡張子の設定」にある「サービス引数」のマッピングと同様に、「name:」を「$producerName」にマッピングし、「BaseURL」を「$nonSecureBaseURL」にマッピングする必要があります。
5 つの置換アクションは、次のコード リストのように定義されます。name の値は、表のバインディング名で置換されます。
./*[local-name()="definitions"]/*[local-name()="service"]/*[local-name()="port"][ends-with(attribute::binding,"name")]/*[local-name()="address" を置換する
WSRP_v2_ServiceDescription_Binding_SOAP
WSRP_v2_PortletManagement_Binding_SOAP
WSRP_v2_Registration_Binding_SOAP
最初の置換アクションに、表 3-11 のユーザ ネームスペース定義を追加する必要があります。
このメッセージ フローのルート ノードは、$producerName に基づいてケースを選択するルーティング テーブルで構成されます。認識されている各プロデューサにケースを追加し、名前が一致すると、ケースがそれぞれ適切なビジネス サービスにルーティングされて WSDL を取得するようにします。この例では次のディレクティブを使用します。
= "operationExample" wsdlSvc にルーティングする
デフォルト nullSvc にルーティングする
変数 inbound の ./ctx:transport/ctx:response の最初の子として <http:http-response-code>404</http:http-response-code> を挿入する
失敗時に返信する
getWSDL2.0 プロキシ サービスのメッセージ フローは、1 つのパイプライン ペアと 1 つのルート ノードで構成されます。このプロキシ サービスのメッセージ フローを定義するには、次の操作を行います。
パイプライン ペアの要求側は 1 つのステージで構成され、そのジョブは、プロデューサ名を URL から抽出してコンテキスト変数に割り当てることです。これを行うには、割り当てアクションを次のように追加します。
変数 producerName に $inbound/ctx:transport/ctx:request/http:relative-URI を割り当てる
メッセージ フローの応答側は、すべてのトランスフォーメーションを実行するステージです。
変数 nonSecureBaseURL に http://alsb:7001/ を割り当てる
./*[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:")]Base-2.0、baseURL を $nonSecureBaseURL、name を $producerName にそれぞれ設定します。$producerName に基づいてケースを選択するルーティング テーブルで構成されます。認識されている各プロデューサにケースを追加し、名前が一致すると、ケースがそれぞれ適切なビジネス サービスにルーティングされて WSDL を取得するようにします。この例では次のディレクティブを使用します。
= "operationExample" wsdlSvc-2.0 にルーティングする
<http:http-response-code>404</http:http-response-code> を、変数 inbound の ./ctx:transport/ctx:response の最初の子として挿入します。
プロデューサを使用するために、コンシューマは自身の 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 にアクセスする必要があります。これは、次の方法で行います。
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 を置き換えます。これは、次の方法で行います。./*[local-name()="definitions"]/*[local-name()="import"][ends-with(attribute::location,"/producer/wsrp-2.0/markup?WSDL")]getWSDL2.0、baseURL を $nonSecureBaseURL、name を $producerName にそれぞれ設定します。
http://alsb:7001/getWSDL/operationExample
リモート ポートレットを作成するには、Workshop for WebLogic または Portal Administration Tool を使用します。WSDL 取得時に入力する URL が異なる点を除き、このポートレットを作成する手順は、Oracle Service Bus が仲介しないポートレットの作成手順と同じです。
|