|
|
この節では、WSRP 相互運用の例を示します。内容は以下のとおりです。
WSRP 相互運用の例では、以下のコンポーネントとコンフィグレーションを想定しています。
この例で定義されているコンフィグレーションをサポートする AquaLogic Service Bus コンフィグレーションについては、AquaLogic Service Bus/WSRP コード サンプルを参照してください。これは、以下に示す BEA dev2dev の AquaLogic Service Bus コード サンプル ページにあります。
この例では、ALSB 2.5 dev2dev コード サンプルに対応するコンフィグレーションについて説明します。
サンプルの構造は、2 つのプロジェクトに分割されます。共通リソースを含むプロジェクト、およびサンプル プロデューサのリソースを含むプロジェクトです。
モニタ コンフィグレーションの例 (operationExample folder 内) では、プロデューサのすべてのサービスと操作をモニタするように、AquaLogic Service Bus をコンフィグレーションします。
モニタ コンフィグレーションでは、使用するビジネス サービスとプロキシ サービスが、WSRP 標準で定義されている WSDL に基づいています。例では、WSRP サービスを記述したり、メッセージ フローを拡張したりして、操作レベルのモニタをサポートするために、追加のリソースを定義します。この節の後の部分では、モニタのコンフィグレーションを実装するために必要なタスクを説明します。
すべての WSRP WSDL 定義ファイルと、その定義が依存している XML スキーマ ファイルをインポートします。ファイルはすべて、この例に対応するサンプル コードの一部として用意されています。標準リソースの場所は次の表のとおりです。
BEA Portal で生成されたプロデューサは、追加ポートを定義して標準 WSDL を拡張し、MIME 添付を使用してメッセージを送信できるようにします。この拡張についての説明はこの例で扱う範囲から外れますが、プロデューサの WSDL が拡張リソースを参照する場合は、その定義が必要です。この例では、オプションのタスクで、プロデューサで使用される WSDL のリソースを作成します。これらの WSDL リソースと XML スキーマ リソースを作成した後、各リソースの参照を編集して他のリソースとの依存関係を解決します。
このモニタの例では、プロデューサが実装するポート タイプごとに WSDL バインディングを使用します。1 つのビジネス サービスには 1 つの WSDL ポートまたはバインディングしか関連付けられないため、それぞれに対して個別のビジネス サービス リソースを作成する必要があります。単純なプロデューサでは、必須のマークアップとサービス記述のインタフェースしか実装されませんが、複雑なプロデューサでは、管理と登録のインタフェースも実装されます。これらのサービスの作成方法は同じです。ただし、次の表に示すように、サービス名とサービスのタイプが異なります。
各サービスについて、少なくとも次の表に示す属性を設定します。
このモニタの例では、次のようにプロキシ サービスをコンフィグレーションしています。
前の例と同様に、既存の operationExample/base ビジネス サービスをモデルとして使用し、プロキシ サービスを作成します。これによって、自動的に、ビジネス サービスと同じ WSDL バインディングがプロキシ サービスのベースとなり、ビジネス サービスへの条件なしのルート アクションを含むメッセージ フローが作成されます。エンドポイント URI については、ポート タイプの略語をプロデューサ名に付ける (たとえば、/operationExampleBase) など、任意に使用できます。
SOAPAction 要求ヘッダに要求操作を指定することを想定します。
デフォルトでは、AquaLogic Service Bus は、転送ヘッダを着信要求から発信要求に、または発信応答から着信応答にコピーしません。このため、メッセージ フローで、必要なヘッダをビジネス サービスに伝播し、ビジネス サービスから必要なヘッダを伝播する必要があります。このようなトランスフォーメーションがすべての WSRP サービスで必要になるため、適切なヘッダを抽出する 2 つの共通 XQuery リソース (要求ヘッダ用と応答ヘッダ用) を定義しておくと便利です。
rqstHeaders クエリは、$in 変数からすべての転送ヘッダ (Content-Length 以外) を抽出します。AquaLogic Service Bus がメッセージ本体のフォーマットを変更することがあるため、長さが要求メッセージと正確に一致しません。本体が変更された場合 (フォーマット変更など) は、元の要求の長さをコピーすると転送エラーが発生することがあります。
着信要求ヘッダを発信ビジネス サービスにコピーするには、次の置換要求アクションをメッセージ フローに追加します。
変数 outbound の ./ctx:transport/ctx:request/tp:headers を xqTransform() で置換する |
ノードのコンテンツを置換 |
変数マッピング (wsrp/rqstHeaders) : |
in: $inbound |
要求側と同様に、応答側でも、プロデューサが返す応答から Content-Length ヘッダ以外のすべてのヘッダを抽出する共通の XQuery リソースを定義します。
ルート ノードの次のような置換応答アクションで、必要なヘッダを伝播します。
変数 inbound の ./ctx:transport/ctx:response/tp:headers を xqTransform() で置換する |
ノードのコンテンツを置換 |
変数マッピング (wsrp/rspncHeaders) : |
out: $outbound |
通常は、WSDL ベースのサービスにルーティングするルート アクションで、呼び出す操作を (ドロップダウン メニューから選択して) 指定します。ただし、各 WSRP ポートで複数の操作が実装されるため、操作ごとのケースを含むルーティング テーブルがコンフィグレーションに必要です。各ケースには、転送ヘッダを伝播するために同じトランスフォーメーションが必要です。
この方法ですべてのトランスフォーメーションを作成するのは、かなり単調な作業になる場合があります。幸い、もっと便利な方法があります。ドロップダウン メニューを使用する代わりに、もう 1 つのトランスフォーメーションを使用してプロキシ サービスからビジネス サービスに操作をコピーします。次のような挿入アクションをメッセージ フローの要求アクションに追加して、このトランスフォーメーションをコンフィグレーションします。
変数 outbound の ./ctx:service の最後の子として $inbound/ctx:service/ctx:operation を挿入する |
これ以外のビジネス サービス用のプロキシ サービスは、同じ手順を繰り返して作成できます。ただし、すべてのトランスフォーメーションを手動で再作成せずにすむ簡単な方法もあります。たとえば、サービス記述サービス用のプロキシ サービスを作成するには、以下の手順を実行します。
operationExample/base プロキシ サービスをモデルとして新しいプロキシ サービスを作成します。この例に従い、エンドポイント URI には /operationExampleDesc を使用します。WSRPServiceDescriptionService ポートを参照するように修正します。desc サービスにルーテイングするように修正します。
プロデューサから WSDL を取得し、実際のプロデューサのエンドポイントを隠すように変換するサービスを作成します。この例では、各プロデューサのプロキシの URI が異なります。この節の後の部分では、プロデューサの WSDL を取得するためにリソースを作成する方法について説明します。
プロデューサから WSDL を取得するためにビジネス サービスを作成します。このリソースはプロデューサに固有であるため、operationExample プロジェクトに作成する必要があります。次の表に、このビジネス サービスのプロパティを示します。
プロデューサの WSDL にあるすべてのエンドポイント アドレスを、AquaLogic Service Bus サーバのアドレスとプロキシ サービスの URI の値を表すように変換する必要があります。プロデューサの WSDL にはそれぞれ 4 つまたはそれ以上のポートが定義されている場合があるため、エンドポイント位置の構成を簡略化するために XQuery 式を作成すると便利です。XQuery 式は次の 3 つの文字列変数を入力として受け取り、連結して SOAP アドレス要素を形成します。
次の表に、wsrp プロジェクトでのクエリの定義を示します。
以降のコンフィグレーション タスクで、何も実行しないサービスが必要になります。このサービスを作成するには、wsrp プロジェクト フォルダにリソース名 nullSvc として新しいプロキシ サービスを定義します。このサービスではすべてデフォルトを受け入れます。このプロキシ サービスをコンフィグレーションすると、この例で必要な 1 つのエコー ノードのみを含むサービスのメッセージ フローが作成されます。
プロデューサから WSDL を取得するためにコンシューマが使用するプロキシ サービスを作成します。このプロキシ サービスは、この基本サンプルで作成されるすべてのプロデューサ コンフィグレーションに対応します。この節の例は提案に過ぎません。実装によっては特定の要件に合わせて別の方法が望ましい場合があります。このプロキシ サービスは 1 つのプロデューサに固有のものではないため、wsrp プロジェクト フォルダに作成する必要があります。
この手順で使用する方法では、管理者が各プロデューサに名前を割り当てる必要があります。この名前は、WSDL 取得用 URL の一部になります。プロキシ サービスのメッセージ フローが URL から名前を抽出し、そのプロデューサ固有のビジネス サービスを検索し、WSDL を取得します。その後、WSDL を変換して AquaLogic Service Bus へのエンドポイントを再作成します。プロキシ サービスのエンドポイント URI は、/getWSDL としてコンフィグレーションされ、コンシューマが WSDL を取得するために使用する URL は次のようになります。
http://alsb:7001/getWSDL/producerName
producerName は、管理者がプロデューサに割り当てた名前です。この例では、プロデューサ名は operationExample です。
次の表に、このプロキシ サービスのコンフィグレーションを示します。
このプロキシ サービスのメッセージ フローは、1 つのパイプライン ペアと 1 つのルート ノードで構成されます。パイプライン ペアの要求側は 1 つのステージで構成され、そのジョブは、プロデューサ名を URL から抽出してコンテキスト変数に割り当てることです。アクションは次のとおりです。
変数 producerName に $inbound/ctx:transport/ctx:request/http:relative-URI を割り当てる
メッセージ フローの応答側は、すべてのトランスフォーメーションを実行するステージです。置換アクションを実行して WSDL を変換する前に、次のように AquaLogic Service Bus サーバのベース URL をコンテキスト変数に割り当てて、トランスフォーメーションのたびに指定しなくてもよいようにします。
変数 nonSecureBaseURL に "http://alsb:7001/" を割り当てる
応答パイプラインのステージを編集して、指定のエンドポイント URI を前に作成したプロキシに一致させるトランスフォーメーションを実行するように、各置換アクションを変更します。この例で作成したプロキシの名前は、プロデューサ名にサービスのタイプの略称を付けたものです。前に作成した addr XQuery リソースは、拡張子引数を受け入れ、URI の位置を構成します。次の表のように、引数を適切な値に変更してください。
表「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_v1_ServiceDescription_Binding_SOAP
WSRP_v1_PortletManagement_Binding_SOAP
WSRP_v1_Registration_Binding_SOAP
最初の置換アクションに、次のユーザ ネームスペース定義を追加する必要があります。
このメッセージ フローのルート ノードは、$producerName に基づいてケースを選択するルーティング テーブルで構成されます。認識されている各プロデューにケースを追加し、名前が一致すると、ケースがそれぞれ適切なビジネス サービスにルーティングされて WSDL を取得するようにします。この例では次のディレクティブを使用します。
= "operationExample" wsdlSvc にルーティングする
不明なプロデューサ名が指定されたケースを処理するには、次のように、操作のないサービスにルーティングするデフォルト ケースを追加します。
この例では、次のような応答アクションをデフォルト ケースに追加して、HTTP 404 ステータス コードを返します。
変数 inbound の ./ctx:transport/ctx:response の最初の子として <http:http-response-code>404</http:http-response-code> を挿入する
失敗時に返信する
最後に、ルート ノードのルーティング テーブルを編集して、ケースがシステムで認識されているプロデューサに対応するようにします。
コンフィグレーションが完了したら、正しく機能するかどうかを確認するためにテストします。コンフィグレーションは以下の手順でテストします。
http://alsb:7001/getWSDL/operationExample
リモート ポートレットを作成するには、WebLogic Workshop または Portal Administration Tool を使用します。WSDL 取得時に入力する URL が異なる点を除き、このポートレットを作成する手順は、AquaLogic Service Bus が仲介しないポートレットの作成手順と同じです。
  
|
