相互運用性ソリューション ガイド
|
 |
 |
|
Web Services for Remote Portlets (WSRP) は、マークアップ フラグメントをリモート システムで生成してローカルのポータル アプリケーションで表示するメカニズムとして、よく使用されています。この節では、AquaLogic Service Bus を使用して、WSRP を使用するアプリケーションでサービス レベル アグリーメントをモニタする方法を説明します。
AquaLogic Service Bus Console (『AquaLogic Service Bus Console の使い方』を参照) を使用して AquaLogic Service Bus をコンフィグレーションします。WebLogic Portal での WSRP 対応ポータル作成の詳細については、『WebLogic Portal での WSRP の使用』を参照してください。
この節では、WSRP の基本アーキテクチャについて説明し、AquaLogic Service Bus を追加してこのアーキテクチャを拡張する方法を示します。
次の図は、プロデューサ アプリケーションとコンシューマ アプリケーション間の、基本の WSRP SOAP 要求および応答フローを示します。
図 6-1 プロデューサ アプリケーションとコンシューマ アプリケーション間の基本の要求/応答フロー
WSRP プロデューサによって SOAP Web サービスが実装されるため、次の図のように、Enterprise Service Bus (AquaLogic Service Bus など) をプロデューサとコンシューマの仲介者として使用して、サービス レベル アグリーメントのモニタ機能を実現できます。
図 6-2 AquaLogic Service Bus によって拡張された WSRP の要求/応答フロー
このアーキテクチャでは、WSRP SOAP 要求/応答フローは以下の順序で行われます。
この節の後の部分では、WSRP サービスのサービス要求を仲介するように AquaLogic Service Bus をコンフィグレーションする手順について説明します。プロデューサで提供されるサービスや、AquaLogic Service Bus の適切なコンフィグレーションのために使用する必要がある WSRP のその他の属性について説明します。また、プロデューサを詳しくモニタするために使用できるさまざまな戦略も示します。最後に、WSRP でのロード バランシングとフェイルオーバについても説明します。
このトピックでは、以下の WSRP 設計の概念について説明します。
次の表は、プロデューサで提供されるサービスの種類を示します。
各プロデューサは、少なくとも 2 つのサービス (サービス記述とマークアップ) を実装します。単純なプロデューサは、これら 2 つのサービスだけを提供します。 複雑なプロデューサは、この他に 2 つのサービス (登録と管理) を提供します。また、WebLogic Portal プロデューサは、標準のマークアップ サービスの代わりに使用できる拡張機能サービス (マークアップ拡張機能) も実装します。
これらのサービスは、標準の WSDL 形式で記述されます。プロデューサは、WSDL 取得用に 1 つの URL を提供します。WSDL には、そのプロデューサが提供するすべてのサービスが記述されています。各サービスのエンドポイントによって、コンシューマがプロデューサとの通信に転送レベルのセキュリティ (HTTPS) を使用する必要があるかどうかが指定されます。
WSRP は、プロデューサとコンシューマの間で送信されるすべてのメッセージで SOAP over HTTP を使用します。SOAP 本体で標準メッセージ形式を使用するだけでなく、WSRP では、要求メッセージに特定の転送ヘッダを設定する必要があります。少なくとも、コンシューマは、SOAPAction ヘッダ、クッキー ヘッダ、および通常の HTTP ヘッダ (Content-Type など) を設定する必要があります。プロデューサは、セッション クッキーとアプリケーション固有のクッキー (存在する場合) を、応答メッセージの HTTP 転送ヘッダで返します。コンシューマは、後続の要求メッセージでそのセッション クッキーを返す必要があります。
WSRP 対応 AquaLogic Service Bus のコンフィグレーションには、以下のタスクが含まれます。
通常、コンシューマは、プロデューサに直接アクセスして WSDL を取得します。ただし、AquaLogic Service Bus を使用してサービスを仲介する場合、プロデューサへのアクセスはすべて AquaLogic Service Bus を介して行われます。このため、コンシューマにプロキシ サービスを実装し、そのプロキシ サービスで、プロデューサの実際の URL を呼び出して WSDL を取得し、以下の方法で結果を変換する必要があります。
開発者がプロデューサを作成するときに、プロデューサで SSL が必要 ("secure=true") かどうかを指定できます。また、AquaLogic Service Bus 管理者は、AquaLogic Service Bus コンフィグレーションを使用して、コンシューマに対するセキュリティ要件を変更できます。たとえば、プロデューサが SSL を要求しないとします。このとき、AquaLogic Service Bus 管理者は、次のようにしてコンシューマに SSL の使用を要求することができます。
このようにコンフィグレーションすると、AquaLogic Service Bus は、コンシューマからの安全なメッセージとプロデューサが使用する安全でないメッセージを自動的に橋渡しします。
コンシューマは WSDL のコピーを取得した後、WSDL の定義を使用してサービス要求を作成し、AquaLogic Service Bus を介してプロデューサに送信します。WSRP の要求/応答プロセスの内容は以下のとおりです。
WSRP Web サービスはポートレットをエクスポーズします。それらのポートレットは HTTP のクッキーとセッションに依存する場合があります。このため、HTTP 転送ヘッダ (SOAPAction やクッキーなど) を伝播するように ALSB をコンフィグレーションする必要があります。ただし、デフォルトでは、AquaLogic Service Bus は、プロキシ サービスからビジネス サービスに転送ヘッダを渡しません。プロキシ サービスとビジネス サービスが同じ転送を使用するとは限らないためです。したがって、要求ヘッダを着信要求から発信要求にコピーするようにメッセージ フローをコンフィグレーションする必要があります。同様に、ビジネス サービスの応答ヘッダも、プロキシ サービスからコンシューマへの応答にコピーする必要があります。
すべての転送ヘッダをプロキシ サービスとビジネス サービスの間でコピーできますが、エラーを避けるために、コピーする転送ヘッダを選択してください。Set-Cookie ヘッダと Cookie ヘッダはコピーする必要があります。AquaLogic Service Bus は、送信する最終メッセージをアセンブルするエンティティであるため、ヘッダ情報の一部 (Content-Length など) は保持する必要があります。たとえば、メッセージ フローで Content-Length ヘッダをプロキシ サービスからビジネス サービスにコピーすると、処理中にメッセージの長さが変化したためにエラーになることがあります。
WSRP アプリケーションをモニタする場合、AquaLogic Service Bus 管理者が、必要なモニタ レベルを決定する必要があります。
実装するモニタ レベルは、AquaLogic Service Bus コンフィグレーションの複雑さに影響します。これによって、各プロデューサのために作成する必要があるプロキシ サービスまたはビジネス サービスのタイプと数が決まります。また、AquaLogic Service Bus 管理者は、プロキシ サービスとプロデューサ サービスの両方を監視するように選択できます。2 つのモニタのレベルを同じにする必要はありません。
プロデューサレベルのモニタは、要求される特定のサービスには関係なく、1 つのプロデューサに送信される要求の合計数を追跡します。そのため、プロデューサレベルのモニタは、AquaLogic Service Bus でのコンフィグレーションが最も簡単です。サービス タイプは重要ではないため、プロキシ サービスまたはビジネス サービスを、WSDL ベースで作成する必要がありません。代わりに、サービス タイプは [任意の SOAP サービス] としてコンフィグレーションできます。各プロデューサに、1 つのプロキシ サービスと 1 つのビジネス サービスのみが必要です。実装例については、「プロデューサレベルのモニタの例」を参照してください。
プロデューサレベルのモニタをコンフィグレーションするには、以下のタスクを実行します。
プロデューサレベルのモニタが適しているかどうかは、実装の特定の要件によって変わります。プロデューサレベルのモニタでは、プロデューサのサービスや操作によって経過時間に差がある場合でも、すべてのサービスや操作の平均時間が算出されます。ただし、プロデューサのサービスと操作によって特性が大きく異なることがあり、集約された計測値を検討しても意味がない場合があります。たとえば、マークアップ サービスは、WSRP の主要機能であり、登録サービスよりも大幅に長い実行時間が必要です。ただし、プロデューサレベルのモニタではこれらは区別されません。それでも、プロデューサレベルのモニタは、プロデューサの利用状況を測定するときや、プロデューサに深刻なパフォーマンスの問題がある場合には役立ちます。プロダクション システムでは、マークアップ サービスはさらに頻繁に使用される (ほぼ 99%) ため、やはりプロデューサ レベルでのサービス レベル アグリーメント (SLA) のモニタが役立つ場合があります。
操作レベルのモニタは、サービスの操作を個別に追跡します。プロキシ サービスの操作レベルのモニタは、非常に簡単に設定できます。ただし、ビジネス サービスに操作レベルのモニタをコンフィグレーションするには少し手間がかかります。幸い、WSRP サービスのメッセージ フローのオーバーヘッドは非常に少なく、プロキシ サービスとプロデューサのマッピング、およびビジネス サービスとプロデューサのマッピングは容易にコンフィグレーションできます。このため、多くの場合、SLA 要件を満たすにはプロキシ サービスを操作レベルでモニタするだけで十分です。実装例については、「操作レベルのモニタの例」を参照してください。
WSRP プロキシ サービスに操作レベルのモニタをコンフィグレーションするには、プロデューサが実装する各サービスに対してプロキシ サービスを作成します。
これらのプロキシ サービスは、SOAP バインディングを使用する標準 WSRP WSDL をベースにしている必要があります。ビジネス サービスは、プロデューサに対して 1 つだけ作成し、WSDL ベースではなく [任意の SOAP サービス] を使用するようにコンフィグレーションしてください。プロキシ サービスとビジネス サービスの間のメッセージ フローで SOAP 本体が変更されないようにしてください。ただし、すべての WSRP メッセージ フローと同じく、HTTP を介して要求ヘッダをクライアント要求から実際のプロデューサに渡す必要があります。同様に、プロデューサから返される応答 HTTP ヘッダは、メッセージ フローでコピーしてクライアントに返す必要があります。
プロデューサのビジネス サービスに操作レベルのモニタが必要な場合、プロデューサの WSDL に記述された各 Web サービスに対して個別のビジネス サービスを作成する必要があります。また、ビジネス サービスは、プロデューサの WSDL を使用して定義する必要があります。プロキシ サービスとビジネス サービスは 1 対 1 でマッピングされるため、メッセージ フローは、条件のない単純なルーティング ノード 1 つで十分です。
操作を正しくカウントするためには、使用する操作を AquaLogic Service Bus に認識させておく必要があります。通常は管理者が、ルート アクションでビジネス サービスを選択するときに、ドロップダウン メニューから 1 つの操作を選択します。ただし、クライアント メッセージで指定される操作はすべてのメッセージで同じではないため、ここでは 1 つの値をハードコード化すると機能しません。管理者は、ビジネス サービスがプロキシ サービスと同じ操作を使用することを保証する必要があります。これは、$operation 変数を使用して、ケースを選択するルーティング テーブル アクションを指定することで実現できますが、この方法はかなり手間がかかります。WSRP 標準では、すべての WSRP サービスに対して 14 の操作が定義されており、それぞれの操作で、転送ヘッダを伝播するためのトランスフォーメーションを含むルート アクションが必要となるためです。
幸い、さらに効率のよい方法があります。ビジネス サービスにルーティングするときに、ドロップダウン メニューから操作を選択するのではなく、管理者が要求アクションで別のトランスフォーメーションを使用し、$inbound/ctx:service/ctx:operation の値を $outbound/ctx:service に挿入する方法です。このトランスフォーメーションで、ビジネス サービスの操作が、プロキシ サービスに指定されていたのと同じ値に動的に設定されます。これにより、AquaLogic Service Bus はサービスのすべての操作を正確にカウントしてモニタすることができます。
AquaLogic Service Bus では、ビジネス サービスに、同じ Web サービスを提供する複数のエンドポイントを定義できます。複数のエンドポイントが定義されていると、AquaLogic Service Bus は、エンドポイント間で要求のロード バランスを自動的に調整できます。また、1 つのエンドポイントがアクセスできなくなると、要求を自動的にフェイルオーバすることもできます。ただし、WSRP ではこれらの機能の使用が一部制限されます。
ポートレットは、特定のアプリケーションにユーザ インタフェースを提供する手段です。このため、通常、ポートレットにはセッション データが関連付けられています。セッション データを保持するために、ポートレットへの要求は、元の要求を処理したのと同じサーバ (またはクラスタ) に送られる必要があります。この要件により、AquaLogic Service Bus でのロード バランシングは適していません。ビジネス サービスの複数のエンドポイントは、通常は異なるサーバまたはクラスタを対象とします。別のクラスタにあるサーバ間には通信がないため、セッションを保存できません。したがって、WSRP ビジネス サービスに複数のエンドポイントを定義した場合は、ロード バランシング アルゴリズムを [なし] に設定する必要があります。
特定の環境では、複数のエンドポイントを使用して冗長性を確保し、1 つのエンドポイントが使用できなくなった場合に備えることができます。この場合、2 つ目のエンドポイントで WSRP サービスを利用できます。ただし、最初のエンドポイントが使用できなくなった時点のセッション データを、他のエンドポイントで引き継ぐことはできません。
このフェイルオーバ コンフィグレーションは、単純なプロデューサでのみ使用できるオプションです (「WSRP WSDL」を参照)。複雑なプロデューサでは使用できません。複雑なプロデューサでは、コンシューマがサービス要求を送信する前にまずプロデューサに登録する必要があります。プロデューサは登録ハンドルを返します。コンシューマは、そのプロデューサへの各要求にこのハンドルを含める必要があります。ビジネス サービスに複数のエンドポイントが定義されている場合、各エンドポイントに個別の登録ハンドルが必要です。
ただし、AquaLogic Service Bus は、要求と要求の間はステートレスであるため、特定のエンドポイントに送信するための正しいハンドルのマッピングは保持されません。実際、登録要求は 1 つのエンドポイントに送信されるだけなので、コンシューマはその 1 つのプロデューサにのみ登録されます。そのプロデューサがクラッシュすると、AquaLogic Service Bus は、ビジネス サービスに定義された別のエンドポイントにサービス要求をルーティングしますが、コンシューマはその新しいプロデューサには登録されていないため、要求は「InvalidRegistration」エラーで失敗します。
したがって、登録ハンドルを管理するには、AquaLogic Service Bus 以外に、この状態データを保持するためのアプリケーションが必要です。エラー処理を実装するのは困難な場合があります。そのため、この登録要件により、複雑なプロデューサでは複数のエンドポイントを定義できません。単純なプロデューサは、登録サービスを必要としない (サポートしない) ため、ビジネス サービスに複数のエンドポイントを定義するフェイルオーバ コンフィグレーションが可能です。ただし、セッション データはフェイルオーバ時に失われます。
この節では、WSRP 相互運用の例を示します。内容は以下のとおりです。
WSRP 相互運用の例では、以下のコンポーネントとコンフィグレーションを想定しています。
platform:7001 でコンフィグレーションされたサンプル プラットフォーム ドメインalsb:7001 でコンフィグレーションされた AquaLogic Service Bus ドメインこの例で定義するコンフィグレーションをサポートする AquaLogic Service Bus コンフィグレーションについては、AquaLogic Service Bus/WSRP コード サンプルを参照してください。これは、BEA dev2dev (次の URL) の AquaLogic Service Bus コード サンプル ページにあります。
https://codesamples.projects.dev2dev.bea.com/
この例では、2 つのプロデューサに対して個別のコンフィグレーションが設定されています。実際には両方のサンプルのプロデューサは同一ですが、コンシューマにとっては異なるプロデューサになります。
サンプルの構造は、3 つのプロジェクトに分割されます。共通リソースを含むプロジェクトが 1 つと、2 つのサンプル プロデューサそれぞれのリソースを含むプロジェクトが 2 つです。
|
|
|
|
|
この基本的なコンフィグレーション例 (producerExample フォルダ) は、最も容易に実装できるコンフィグレーションです。このコンフィグレーションでは、プロデューサ全体のモニタ (「プロデューサレベルのモニタ」を参照) がサポートされ、プロデューサを構成するサービスや操作は考慮されません。
このプロデューサレベルのモニタのコンフィグレーションを実装するには、以下の作業を行います。
この節の後の部分では、このプロデューサレベルのモニタのコンフィグレーションを実装するために必要なタスクを説明します。
プロデューサレベルのモニタをコンフィグレーションするための最初の手順は、プロデューサの WSDL を取得してそれをコンシューマに返すために必要なリソースを作成することです。WSDL にはプロデューサのサービスのエンドポイントが含まれるため、実際のサーバの IP アドレスとポートを隠すようにエンドポイントを変換する必要があります。つまり、アドレスは AquaLogic Service Bus サーバを参照する必要があり、URI は、プロキシ サービスが定義するこのプロデューサの URI と一致する必要があります。
プロデューサから WSDL を取得するビジネス サービスを作成します。このリソースはプロデューサに固有であるため、producerExample プロジェクトに作成する必要があります。次の表に、このビジネス サービスのプロパティを示します。
|
|
||
プロデューサの WSDL に記述されたすべてのエンドポイント アドレスを、AquaLogic Service Bus サーバのアドレスとプロキシ サービスの URI の値を表すように変換する必要があります。プロデューサの WSDL にはそれぞれ 4 つまたはそれ以上のポートが定義されている場合があるため、エンドポイント位置の構成を簡略化するために XQuery 式を作成すると便利です。XQuery 式は次の 3 つの文字列変数を入力として受け取り、連結して SOAP アドレス要素を形成します。
次の表に、wsrp プロジェクトでのクエリの定義を示します。
|
|
この後のコンフィグレーション タスク (「手順 1.4 : 共通プロキシ サービスを作成する」を参照) で、何も実行しないサービスが必要になります。このサービスを作成するには、wsrp プロジェクト フォルダにリソース名 nullSvc として新しいプロキシ サービスを定義します。このサービスではすべてデフォルトを受け入れます。このプロキシ サービスをコンフィグレーションすると、この例で必要な 1 つのエコー ノードのみを含むメッセージ フローが作成されます。
プロデューサから WSDL を取得するためにコンシューマが使用するプロキシ サービスを作成します。このプロキシ サービスは、この基本サンプルで作成されるすべてのプロデューサ コンフィグレーションに対応します。この節の例は提案に過ぎません。実装によっては特定の要件に合わせて別の方法が望ましい場合があります。このプロキシ サービスは 1 つのプロデューサに固有のものではないため、wsrp プロジェクト フォルダに作成する必要があります。
この手順で使用する方法では、管理者が各プロデューサに名前を付ける必要があります。この名前は、WSDL 取得用 URL の一部になります。プロキシ サービスのメッセージ フローが URL から名前を抽出し、そのプロデューサ固有のビジネス サービスの場所を探し、WSDL を取得します。その後、WSDL を変換して AquaLogic Service Bus を指すようにエンドポイントを再作成します。プロキシ サービスのエンドポイント URI は、/producerWSDL としてコンフィグレーションされ、コンシューマが WSDL を取得するために使用する URL は次のようになります。
producerName は、管理者がプロデューサに割り当てた名前です。この例では、プロデューサ名は producerExample です。
次の表に、このプロキシ サービスのコンフィグレーションを示します。
このプロキシ サービスのメッセージ フローは、1 つのパイプライン ペアと 1 つのルート ノードで構成されます。パイプライン ペアの要求側は 1 つのステージで構成され、そのジョブは、プロデューサ名を URL から抽出してコンテキスト変数に割り当てることです。アクションは次のとおりです。
メッセージ フローの応答側は、すべてのトランスフォーメーションを実行するステージです。置換アクションを実行して WSDL を変換する前に、次のように AquaLogic Service Bus サーバのベース URL をコンテキスト変数に割り当てて、トランスフォーメーションのたびに指定しなくてもよいようにします。
プロデューサは 4 つのポートを実装できるため、プロキシ サービスは各ポートを変換する必要があります。プロデューサが特定のポートを実装していない場合、XQuery トランスフォーメーションでは何も行われません。1 つのエンドポイントでこのプロデューサのすべての WSRP トラフィックを処理するように定義するので、置換アクションでは、前に作成した addr XQuery リソース (「手順 1.2 : URL を構成するための XQuery 式を作成する」を参照) を使用して、エンドポイントを値に変換します。
4 つの置換アクションは、次のコード リストのように定義されます。name の値は、表のバインディング名で置換されます。
最初の置換アクションに、次のユーザ ネームスペース定義を追加する必要があります。
注意 : BEA ツールで作成されたプロデューサでは、拡張機能サービス (urn:WLP_WSRP_v1_Markup_Ext_Binding_SOAP) が実装されます。このポートはこの例では使用されません。このポートのエンドポイントは変更しなくても問題ありません。
このメッセージ フローのルート ノードは、$producerName に基づいてケースを選択するルーティング テーブルで構成されます。認識されている各プロデューサ (この例では producerExample という 1 つのプロデューサだけを使用) にケースを追加し、名前が一致すると、ケースがそれぞれ適切なビジネス サービスにルーティングされて WSDL を取得するようにします。この例では次のディレクティブを使用します。
不明なプロデューサ名が指定されたケースを処理するには、次のように、操作のないサービス (「手順 1.3 : 操作のないプロキシ サービスを作成する」で定義) にルーティングするデフォルト ケースを追加します。
デフォルト nullSvc にルーティングする
この例では、次のような応答アクションをデフォルト ケースに追加して、HTTP 404 ステータス コードを返します。
プロデューサの WSDL を取得するために必要なリソースを作成したら、通常の WSRP サービス要求を AquaLogic Service Bus で処理するためのコンフィグレーション リソースを作成します。最も簡単なコンフィグレーションでは、1 つのプロキシ サービスと 1 つのビジネス サービスを作成し、それらのサービスをメッセージ フローでリンクさせ、WSRP が必要とする転送ヘッダを伝播します。
WSRP で必要な最小のビジネス サービスは、WSDL ベースではありません。代わりに、任意の SOAP メッセージを受け入れるビジネス サービスを作成します。この方法ではコンフィグレーションが単純化され、WSRP で使用されるすべてのポート タイプを 1 つのビジネス プロセスで処理できます。この方法の短所はモニタの機能が制約されることです。次の設定を使用してビジネス サービスをコンフィグレーションします。
プロキシ サービスを定義する最も便利な方法は、前の手順で定義した既存のビジネス サービスから作成する方法です。このようにすると、適切なタイプ (ビジネス サービスでコンフィグレーションされたのと同じタイプ、すなわち [任意の SOAP サービス]) でプロキシ サービスが作成され、メッセージを条件なしで適切なビジネス サービスにルーティングする基本的なメッセージ フローも構成されます。このメッセージ フローは後の手順で編集する必要があります。次の設定を使用してプロキシ サービスをコンフィグレーションします。
|
|
||
WSRP は正常に機能するために、転送ヘッダで渡されるデータに依存します。特に、プロデューサは、応答ヘッダで任意のセッション クッキーをコンシューマに返し、コンシューマがそれ以降の要求にはそのセッション クッキーを指定することを想定します。同様に、プロデューサは、コンシューマが SOAPAction 要求ヘッダに要求操作を指定することを想定します。
デフォルトでは、AquaLogic Service Bus は、転送ヘッダを着信要求から発信要求または発信応答から着信応答にコピーしません。このため、メッセージ フローで、必要なヘッダをビジネス サービスに伝播し、ビジネス サービスから必要なヘッダを伝播する必要があります。このようなトランスフォーメーションがすべての WSRP サービスで必要になるため、適切なヘッダを抽出する 2 つの共通 XQuery リソース (要求ヘッダ用と応答ヘッダ用) を定義しておくと便利です。
rqstHeaders クエリは、$in 変数からすべての転送ヘッダ (Content-Length 以外) を抽出します。AquaLogic Service Bus がメッセージ本体のフォーマットを変更することがあり、長さが要求メッセージと正確に一致しなくなります。本体が変更された場合 (フォーマット変更など) は、元の要求の長さをコピーすると転送エラーが発生することがあります。
着信要求ヘッダを発信ビジネス サービスにコピーするには、次の置換要求アクションをメッセージ フローに追加します。
要求側と同様に、応答側でも、プロデューサが返す応答から Content-Length ヘッダ以外のすべてのヘッダを抽出する共通の XQuery リソースを定義します。
ルート ノードの次のような置換応答アクションで、必要なヘッダを伝播します。
プロデューサレベルの例の単純なコンフィグレーションが完了したら、セッションで行われた変更をアクティブ化します。テストをコンフィグレーションするには、以下の手順を実行します。
AquaLogic Service Bus をコンフィグレーションするときは、どのコンポーネントのモニタも明示的に有効になっていません。モニタを有効にする手順は、WSRP サービスでも、AquaLogic Service Bus の他の Web サービスでも同じです。目的のコンポーネントごとに、モニタの管理ページの [モニタを有効化] ボックスを選択 (チェック) し、集約間隔を設定します。該当する場合は、アラート ルールの設定を検討します。これらの変更をアクティブ化したら、AquaLogic Service Bus Console のダッシュボードからコンフィグレーションをモニタできます。
詳細なモニタ コンフィグレーションの例 (operationExample フォルダ) では、プロデューサのすべてのサービスと操作をモニタするように AquaLogic Service Bus をコンフィグレーションします (「操作レベルのモニタ」を参照)。プロデューサレベルのモニタの例で説明したすべての概念 (「プロデューサレベルのモニタの例」を参照) は、この例にも当てはまります。コンフィグレーション タスクを簡略化するために、プロデューサレベルのモニタのコンフィグレーションから特定の要素をコピーします。操作レベルのモニタの例では、プロデューサレベルのモニタの例と同じプロデューサ アプリケーションを使用します。
この例とプロデューサレベルのモニタの例との根本的な違いは、操作レベルのモニタ コンフィグレーションでは、使用するビジネス サービスとプロキシ サービスの両方が、WSRP 標準で定義された WSDL ベースであるということです。この例では、WSRP サービスを記述したり、メッセージ フローを拡張して操作レベルのモニタをサポートしたりするために、リソースをさらに定義します。
この節の後の部分では、この操作レベルのモニタのコンフィグレーションを実装するために必要なタスクを説明します。
すべての WSRP WSDL 定義ファイルと、その定義が依存している XML スキーマ ファイルをインポートします。すべてのファイルは、この例に対応するサンプル コードの一部として用意されていますが、標準リソースの場所は次の表のとおりです。
BEA Portal で生成されたプロデューサは、追加ポートを定義して標準 WSDL を拡張し、MIME 添付を使用してメッセージを送信できるようにします。この拡張についての説明はこの例で扱う範囲から外れますが、プロデューサの WSDL が拡張リソースを参照する場合は、その定義が必要です。この例では、オプションのタスクで、プロデューサで使用される WSDL のリソースを作成します。これらの WSDL リソースと XML Schema リソースを作成したら、各リソースの参照を編集して他のリソースとの依存関係を解決します。
プロデューサレベルのモニタの例では、1 つのビジネス サービスを作成してプロデューサのすべてのメッセージを処理しました。この方法が機能したのは、ビジネス サービスが WSDL に関連付けられていなかったためです。
操作レベルのモニタの例では、プロデューサが実装するポート タイプごとに WSDL バインディングを使用します。1 つのビジネス サービスには 1 つの WSDL ポートまたはバインディングしか関連付けられないため、それぞれに対して個別のビジネス サービス リソースを作成する必要があります。単純なプロデューサでは、必須のマークアップとサービス記述のインタフェースしか実装されませんが、複雑なプロデューサでは、管理と登録のインタフェースも実装されます。これらのサービスの作成方法は同じです。次の表のようにサービス名とサービス タイプが異なります。
各サービスについて、少なくとも次の表に示す属性を設定します。
この操作レベルのモニタの例のプロキシ サービスは、プロデューサレベルのモニタの例で作成したプロキシ サービスに非常によく似ていますが、以下の重要な違いがあります。
前の例と同じく、既存の operationExample/base ビジネス サービスをモデルとしてプロキシ サービスを作成します。これによって自動的に、ビジネス サービスと同じ WSDL バインディングがプロキシ サービスのベースとなり、ビジネス サービスへの条件なしのルート アクションを含むメッセージ フローが作成されます。エンドポイント URI については、ポート タイプの略称をプロデューサ名に付ける (たとえば、/operationExampleBase) などして任意に指定できます。
通常は、WSDL ベースのサービスにルーティングするルート アクションで、呼び出す操作を (ドロップダウン メニューから選択して) 指定します。ただし、各 WSRP ポートで複数の操作が実装されるため、操作ごとのケースを含むルーティング テーブルがコンフィグレーションに必要です。各ケースには、転送ヘッダを伝播するための同じトランスフォーメーションが必要です。
この方法ですべてのトランスフォーメーションを作成するにはかなり手間がかかります。幸い、さらに便利な方法があります。ドロップダウン メニューを使用する代わりに、もう 1 つのトランスフォーメーションを使用してプロキシ サービスからビジネス サービスに操作をコピーします。次のような挿入アクションをメッセージ フローの要求アクションに追加して、このトランスフォーメーションをコンフィグレーションします。
変数 outbound の ./ctx:service の最後の子として $inbound/ctx:service/ctx:operation を挿入する
これ以外のビジネス サービス用のプロキシ サービスは、同じ手順を繰り返して作成できます。ただし、すべてのトランスフォーメーションを手動で再作成せずにすむ簡単な方法もあります。たとえば、サービス記述サービス用のプロキシ サービスを作成するには、以下の手順を実行します。
operationExample/base プロキシ サービスをモデルとして新しいプロキシ サービスを作成します。この例に従い、エンドポイント URI には /operationExampleDesc を使用します。プロデューサレベルのモニタの例と同様に、プロデューサから WSDL を取得し、実際のプロデューサのエンドポイントを隠すように変換するサービスを作成します。作成するリソースは、プロデューサレベルのモニタのサンプルで作成したものと非常によく似ていますが、この例では各プロデューサのプロキシの URI が異なります。この節の後の部分では、プロデューサの WSDL を取得するリソースを作成する方法について説明します。
この例でプロデューサの WSDL を取得するために使用するビジネス サービスは、プロデューサレベルのモニタの例で使用したリソースと同じです (「手順 1.1 : ビジネス サービスを作成する」を参照)。
wsrp/producerWSDL (「手順 1.4 : 共通プロキシ サービスを作成する」を参照) をモデルとしてプロキシ サービス (名前は wsrp/getWSDL) を作成します。応答パイプラインのステージを編集して、指定のエンドポイント URI を前に作成したプロキシに一致させるトランスフォーメーションを実行するように、各置換アクションを変更します。この例で作成したプロキシの名前は、プロデューサ名にサービス タイプの略称を付けたものです。前に作成した addr XQuery リソース (「手順 1.2 : URL を構成するための XQuery 式を作成する」を参照) は、拡張子引数を受け入れ、URI の位置を構成します。次の表のように、引数を適切な値に変更してください。
最後に、ルート ノードのルーティング テーブルを編集して、各ケースがシステムで認識されているプロデューサに対応するようにします。
コンフィグレーションが完了したら、正しく機能するかどうかを確認するためにテストします。コンフィグレーションをテストする手順は、プロデューサレベルのモニタの例と似ています (「手順 3 : コンフィグレーションをテストする」を参照)。1 つだけ異なるのは、プロデューサから WSDL を取得するための URL です。次のようになります。
http://alsb:7001/getWSDL/operationExample
|
|
|