ユーザーズ ガイド
|
 |
 |
|
BEA AquaLogic Service Bus テスト コンソールは、システムの設計の検証およびテストに使用する、ブラウザ ベースのテスト環境です。これは、AquaLogic Service Bus Console の拡張機能です。コンソールで、テストするオブジェクト (プロキシ サービス、ビジネス サービス、XQuery、XSLT、MFL リソース) のコンフィグレーション、テストの実行、および結果の表示を行うことができます。場合によっては、コードをトレースして、特定のトレース ポイントでのメッセージの状態を調べることができます。設計時テストを行うことで、コンフィグレーションをプロダクション環境にデプロイする前に設計上の問題を割り出すことができます。テスト コンソールでは、システムの特定部分を切り分けてテストしたり、システムを 1 つの単位としてテストしたりできます。
テスト コンソールを呼び出して、すべてのプロキシ サービスまたはビジネス サービス、およびこれらのサービスで使用される特定のリソースをテストできます。インライン XQuery テストを実行することもできます。
AquaLogic Service Bus Console では、プロセスのどの部分をテストするかに応じて、いくつかの方法でテスト コンソールを起動できます。テスト コンソールは次の場所から呼び出すことができます。
他のプロキシ サービスまたはビジネス サービスを呼び出すプロキシ サービスや、呼び出される側のサービスを実行してテストできます。サービスで使用されるリソースをテストできます。サービスをテストするときは、テスト コンソールからサービスへ、またはサービスからテスト コンソールへ渡される情報に注意する必要があります。
プロキシ サービスをテストするには、セッションをアクティブ化しておく必要があります。プロキシ サービスのテストは、リソース ブラウザまたはプロジェクト エクスプローラから実行できます。以下のタイプのプロキシ サービスをテストできます。
直接呼び出しは、同じ AquaLogic Service Bus ドメイン内にあるプロキシ サービスをテストするときに使用します。[直接呼び出し] オプションでは、メッセージは直接プロキシ サービスに送信され、転送レイヤを経由しません。[直接呼び出し] オプションを使用すると、デフォルトでトレースが有効になり、テスト コンソールでメッセージ フローを診断したりトラブルシューティングしたりすることができます。デフォルトでは、プロキシ サービスのテストは [直接呼び出し] オプションを使用して行われます。
[直接呼び出し] オプションを使用してプロキシ サービスをテストする場合、テスト コンソールに入力するコンフィグレーション データは、プロキシ サービスを呼び出すクライアントから渡されるとプロキシ サービスが想定するデータにする必要があります。つまり、テスト コンソールは、プロキシ サービスを呼び出すクライアントの役割を果たします。
次の図は、直接呼び出しの仕組みを示します。メッセージは転送レイヤを経由せず、直接プロキシ サービス (P1) に配信されます。
直接呼び出しの方法は、プロキシ サービスの内部メッセージ フロー ロジックをテストする場合に最も適しています。テスト データは、ディスパッチされた時点の想定されるメッセージの状態をシミュレーションする必要があります。このテスト アプローチと、テスト コンソールの [転送] セクションにあるカスタム (着信) 転送ヘッダの設定を使用して、サービスの呼び出しを正確にシュミレーションします。
プロキシ サービスを間接呼び出しでテストする場合 (つまり、[直接呼び出し] オプションを選択しない場合)、メッセージは転送レイヤを経由してプロキシ サービスに送信されます。転送レイヤは、テストの際に、メッセージ ヘッダまたはメタデータの処理を実行します。これによって、プロキシ サービスからプロキシ サービスへの呼び出しの実行時パスが呼び出されます。
次の図は、間接呼び出しの仕組みを示します。メッセージはまず転送レイヤで処理され、次にプロキシ サービス (P1) に送信されます。
このテスト方法は、両方のプロキシ サービスが同じ JVM で実行されている際に、プロキシ サービスからプロキシ サービスへのインタフェースをテストする場合にお勧めします。このテスト アプローチと、テスト コンソールの [転送] パネルにあるカスタム (発信) 転送ヘッダの設定を使用して、サービスの呼び出しを正確にシュミレーションします。テスト コンソールの転送設定の詳細については、「テスト コンソールの転送設定」を参照してください。
間接呼び出しでは、テストに入力するコンフィグレーション データは、プロキシ サービス (たとえば、他のプロキシ サービスのルート ノードやサービス コールアウト アクション) から送信されるデータです。間接呼出しのシナリオでは、テスト コンソールは、別のサービスへのルーティングまたはコールアウトを行うプロキシ サービスの役割を果たします。
プロキシ サービスをテストする場合、テスト コンソールはネットワークを介して HTTP 要求を送信しないため、転送レベルのアクセス制御は適用されません。
(このような転送レベルのアクセス制御は、Web アプリケーション レイヤで行われます。つまり、AquaLogic Service Bus Console の転送レイヤを使用して間接呼び出しが行われても、HTTP 要求はネットワークを介して送信されず、この転送レベルのアクセス制御は適用されません。) AquaLogic Service Bus Console のアーキテクチャについては、BEA AquaLogic Service Bus の『概念とアーキテクチャ』の「概要」を参照してください。
転送設定については、「テスト コンソールでのランタイムによる転送設定の使用方法」を参照してください。
サービスをテストするには、セッションをアクティブ化しておく必要があります。以下のタイプのビジネス サービスをテストできます。
ビジネス サービスをテストする場合、メッセージは必ず転送レイヤを経由してルーティングされます。[直接呼び出し] オプションは使用できません。サービスをテストするためにテスト コンソールに指定するコンフィグレーション データは、プロキシ サービスのルート ノードやサービス コールアウト アクションなどからビジネス サービスに送信されると想定されるメッセージの状態を表すデータです。テスト コンソールでビジネス サービスをテストする場合、テスト コンソールは呼び出し元プロキシ サービスの役割を果たします。
テスト コンソールを使用して BASIC 認証方式の HTTP (S) ビジネス サービスをテストする場合、テスト コンソールは、ビジネス サービスのサービス アカウントのユーザ名/パスワードを使用して認証を行います。同様に、認証の必要な JMS、電子メール、または FTP ビジネス サービスをテストする場合、テスト コンソールは、そのビジネス サービスに関連付けられたサービス アカウントを使用して認証を行います。
次の図に示すシナリオでは、クライアントがプロキシ サービス (P1) を呼び出します。メッセージ フローは、ビジネス サービス B1、プロキシサービス P2、プロキシ サービス P3 の順に呼び出してから、メッセージをクライアントに返します。インタフェースを番号で示しています。
このシナリオには、有効なテスト方法がいくつもあります。次のテスト方法をお勧めします。
プロキシ サービスのメッセージのトレースでは、メッセージ フローの複数のポイントでメッセージ コンテキストと発信通信が検証されます。メッセージが検証されるポイントは、AquaLogic Service Bus によって事前定義されています。AquaLogic Service Bus は、ステージ、エラー ハンドラ、およびルート ノードのトレースを定義しています。
トレースのステージごとに、メッセージ コンテキストに発生した変更と、そのステージの実行中に呼び出されたすべてのサービスが含まれます。トレースには次の情報が含まれます。
- 新しいすべての変数の名前とその値 (+ をクリックすると値が表示されます)。
- 削除されたすべての変数の名前。
- 値が変更されたすべての変数の名前 (+ 記号をクリックすると新しい値が表示されます)。
outbound、header、body、および attachment 変数の値が含まれます。outbound 変数の値、要求および応答メッセージの両方の header、body、および attachment 変数の値が含まれます。ルート ノードについても、ステージと同様の情報が含まれます。ルート ノードの場合、トレースには以下の情報カテゴリが含まれます。
この例では、手順のベースとして AquaLogic Service Bus サンプル ドメインにあるプロキシ サービスの 1 つを使用します。
サンプル ドメインの起動方法と、そのドメインで提供されるサンプルの実行方法については、BEA WebLogic Service Bus の『サンプル』を参照してください。このシナリオ例では、融資申し込みの検証サンプルに関連付けられている、loanGateway3 というプロキシ サービスを使用します。
loanGateway3 のメッセージ フローを、次の図に示します。この図の validate loan application ステージとルート ノードのコンフィグレーションに注釈を付けてあります。
図 4-4 プロキシ サービス (LoanGateway3) のメッセージ フロー
テスト コンソールを使用して、AquaLogic Service Bus サンプル ドメインにあるこのプロキシ サービスをテストするには、以下の手順を実行します。
コード リスト 4-1 LoanGateway3 のテスト メッセージ
<loanRequest xmlns:java="java.normal.client">
<java:Name>Name_4</java:Name>
<java:SSN>SSN_11</java:SSN>
<java:Rate>4.9</java:Rate>
<java:Amount>2500</java:Amount>
<java:NumOfYear>20.5</java::NumOfYear>
<java:Notes>Name_4</java:Notes>
</loanRequest>
トレース結果を、図 4-4 に示されたメッセージ フローのノードと比較します。
を選択します。[
validate loan application ステージでメッセージが処理された結果、$body と $inbound が変更されました。これらの変更は、メッセージ フローの最後に表示されます。fault コンテキスト変数 ($fault) のコンテンツが表示される (この例では、integer 型以外の値 (20.5) をコード リスト 4-1 の <java:NumOfYear> 要素に入力し、検証エラーが発生)。この融資申し込みのシナリオの詳細については、BEA AquaLogic Service Bus の『チュートリアル』の「チュートリアル 3. 融資申し込みの検証」を参照してください。
異なるパラメータを入力してサービスをテストするか、AquaLogic Service Bus Console のプロジェクト エクスプローラでメッセージ フローの動作を変更して再度テストを行い、結果を確認してみてください。
アクティブ セッション内、またはセッション外でリソースをテストできます。テストできるリソースは次のとおりです。
MFL (メッセージ フォーマット言語) ドキュメントは、バイナリ データのレイアウトを記述するために使用する特別な XML ドキュメントです。
MFL リソースは、以下のトランスフォーメーションをサポートします。
どちらのトランスフォーメーションも、それぞれ 1 つの入力だけを受け入れ、1 つの出力を返します。
次の例では、テスト コンソールでテストされる XML 入力ファイルを説明します。MFL ファイルをテストするためにテスト コンソールを呼び出すと、サンプル XML データが生成されます。サンプル XML を使用してテストを実行します。この場合、テストが成功すると、入力 XML ドキュメントのメッセージ コンテンツがバイナリ フォーマットに変換されます。次の「例」では、MFL、テスト XML、およびテスト結果データを説明します。
<?xml version='1.0' encoding='windows-1252'?>
<!DOCTYPE MessageFormat SYSTEM 'mfl.dtd'>
<MessageFormat name='StockPrices' version='2.01'>
<StructFormat name='PriceQuote' repeat='*'>
<FieldFormat name='StockSymbol' type='String' delim=':' codepage='windows-1252'/>
<FieldFormat name='StockPrice' type='String' delim='|' codepage='windows-1252'/>
</StructFormat>
</MessageFormat>
次のコード リストでは、コード リスト 4-2 の MFL ファイルをテストするためにテスト コンソールで生成される XML 入力が記述されています。
<StockSymbol>StockSymbol_31</StockSymbol>
<StockPrice>StockPrice_17</StockPrice>
テスト コンソールで、[実行] をクリックしてテストを実行します。結果は、次のコード リストのように、Stock symbol と stockPrice がバイナリ フォーマットで表示されます。
00000000: 53 74 6F 63 6B 53 79 6D 62 6F 6C 5F 33 31 3A 53 StockSymbol_31:S
00000010: 74 6F 63 6B 50 72 69 63 65 5F 31 37 7C .... .. tockPrice_17|...
AquaLogic Service Bus では、eXtensible Stylesheet Language Transformation (XSLT) を使用して XML から XML へのマッピングを記述します。XSL トランスフォーメーションは、プロキシ サービスのメッセージ フローで XQuery 式を編集する場合に使用することができます。
XSLT リソースをテストするには、入力 XML ドキュメントを指定する必要があります。テストの結果、テスト コンソールに出力 XML ドキュメントが表示されます。ドキュメントに、トランスフォーメーションで使用するパラメータを作成できます。XSLT パラメータは、値としてプリミティブ型または XML ドキュメントをとります。XSL トランスフォーメーションからパラメータの型を識別することはできません。テスト コンソールの [XSLT リソース テスト] ページの [入力およびパラメータ] セクションで、ドキュメントに定義した XSLT パラメータにバインドする値を入力する必要があります。
XQuery は、データが物理的に XML に格納されるか、XML として表示されるかに関係なく、XML の構造を使用して、さまざまな種類のデータに対するクエリをインテリジェントに表現できます。
XQuery トランスフォーメーションは複数の入力をとる場合があります。返される出力は 1 つです。XQuery トランスフォーメーションに想定される入力は、定義済みの各 XQuery 外部変数にバインドする変数値です。XQuery 入力変数の値は、プリミティブ型の値 (string 型、integer 型、date 型)、XML ドキュメント、またはこれらの型のシーケンスで指定できます。出力の値は、プリミティブ型の値 (string 型、integer 型、date 型)、XML ドキュメント、これらの型のシーケンスになります。
XQuery は型付きの言語で、外部変数ごとに型が決まっています。型は以下のグループに分類できます。
想定される型が単純型である場合は、テスト コンソールに 1 行の編集ボックスが表示されます。想定されるデータが XML である場合は、複数行の編集ボックスが表示されます。変数に型がない場合は、両方の組み合わせの入力が使用されます。テスト コンソールに [[] XML として] フィールドが表示され、ここで変数の型を宣言できます。この型に基づいて、テスト コンソールの入力が表示されます。これによって、入力するデータの型が分かりやすくなっています。
たとえば、次の図は、int、XML、および型なしの 3 つの変数を持つ XQuery を示します。
テスト コンソールでは、3 つの変数がすべて [変数] セクションに表示されます。型なし変数については、デフォルトで XML がチェックされています。これが最も一般的なケースです。これらの変数をコンフィグレーションする必要があります。
図 4-7 テスト コンソールでの XQuery 変数のコンフィグレーション
XQuery エディタから XQuery 式をテストすることもできます。
インライン XQuery テストを実行する場合は、ブラウザのポップアップ ブロッカーを無効にする必要があります。Internet Explorer ブラウザでツールバーを使用している場合、ポップアップをブロックするようにコンフィグレーションされているすべてのツールバーについても、オプション メニューでポップアップ ブロッカーを無効にする必要があります。
テスト コンソールでインライン XQuery テストを実行した場合、[戻る] ボタンを使用して前のページに戻り、もう一度テストを実行できます。ただし、インライン XQuery を変更してからもう一度テストを実行する場合、変更を有効にするには、テスト コンソールを閉じて開きなおす必要があります。
テスト コンソールは、Web サービス セキュリティ (WSS) で保護されたプロキシ サービスとビジネス サービスのテストをサポートします。WS-Security アサーションを含む WS-Policy が割り当てられた SOAP サービスは、WSS で保護されます。具体的には、WS-Security アサーションを含む有効な要求または応答 WS-Policy を持つサービス操作が、WS-Security で保護されます。WS-Policiy は、WS-PolicyAttachment というメカニズムによって、サービスに割り当てられます。「Web サービス ポリシーの添付」を参照してください。操作に要求ポリシーと応答ポリシーの両方を含めることもできます。
操作に要求 WS-Policy または応答 WS-Policy がある場合、テスト コンソールとサービスの間のメッセージ交換は、WS-Security のメカニズムで保護されます。テスト サービスは、操作のポリシーに従ってメッセージ (正確にはメッセージの一部) をデジタル署名または暗号化し、適用されるすべてのセキュリティ トークンを含めます。デジタル署名と暗号化操作の入力は、ユーザが指定するクリアテキストの SOAP エンベロープです。詳細については、BEA AquaLogic Service Bus の『ユーザーズ ガイド』の「テスト コンソール」で「プロキシ サービスのテスト データのコンフィグレーション」および「ビジネス サービスのテスト データのコンフィグレーション」を参照してください。
同様に、サービスは、操作の応答ポリシーに従って応答を処理します。応答は、暗号化またはデジタル署名される場合があります。この場合テスト サービスは、この応答を処理し、メッセージを復号化したりデジタル署名を検証したりします。
テスト コンソール ([セキュリティ] パネル) には、WS-Security を含むサービスをテストする場合に使用する [サービス プロバイダ]、[ユーザ名]、および [パスワード] フィールドが表示されます。
テスト コンソールでプロキシ サービス プロバイダを指定すると、WS-Security で要求されるすべてのクライアントサイド PKI キーペア資格が、プロキシ サービス プロバイダから取得されます。詳細については、「プロキシ サービス プロバイダ」を参照してください。操作の要求ポリシーで ID アサーションが指定されており、サポートされるトークン タイプの 1 つがユーザ名トークンである場合は、[ユーザ名] と [パスワード] フィールドを使用します。詳細については、「Web サービス ポリシー」を参照してください。
[サービス プロバイダ]、[ユーザ名]、および [パスワード] フィールドは、操作に要求または応答ポリシーがある場合は必ず表示されます。値が必須かどうかは、実際の要求および応答ポリシーによって決まります。
|
|
|
|
|
|
|
|
|
|
|
表 4-2 ID ポリシーのシナリオ (ポリシーに ID アサーションがあるという前提)
|
| ||
|---|---|---|
|
|
||
|
|
||
|
|
||
|
|
||
SAML ポリシーを持つプロキシ サービスと SAML holder-of-key ポリシーを持つビジネス サービスのテストには、以下の制限があります。
注意 : テスト コンソールでテストを実行した後、WSS で生成されたエンベロープが必ずしも有効なエンベロープというわけではありません。テスト コンソールの結果ページには、読みやすくするためにホワイト スペースが挿入されています。つまり、保護された SOAP メッセージは、出力時にホワイト スペースが追加されて表示されます。ホワイト スペースはドキュメントのセマンティクスに影響する可能性があるため、このような SOAP メッセージはリテラル データとして使用できない場合もあります。たとえば、デジタル署名はホワイト スペースの影響を受け、無効になることがあります。
テスト コンソールの [転送] パネルには、テスト システムのメッセージのメタデータと転送ヘッダを指定することができます。次の図は、テスト コンソールの [転送] パネルの例を示します。
この図は、あるサービス (この場合は WSDL ベースのプロキシ サービス) の転送パネルの例を示しています。
プロキシ サービスのメッセージ フローのメタデータと転送ヘッダを設定できます。この設定によって、発信転送のアクションを調整します。メタデータ、メッセージ、およびヘッダをテストして、パイプラインで取得される出力を確認できます。プロキシ サービスのテスト時に [転送] パネルに表示されるフィールドは、パイプラインで使用できるヘッダとメタデータを表します。テスト コンソールに表示されるフィールドは、プロキシ サービスに応じてフィルタされません。HTTP ベースのすべての要求のページに、同じ転送パラメータのセットが表示されます。
[ユーザ名] と [パスワード] フィールドは、プロキシ サービスを実行しているユーザの基本認証を実装するために使用されます。[ユーザ名] と [パスワード] フィールドは、特に転送との関連はありません。
メタデータ フィールドは、[転送] パネルで、[ユーザ名] および [パスワード] フィールドと転送ヘッダ フィールド群の間にまとめられています。表示されるフィールドは、サービスの転送タイプに基づいています。サービスを定義するときに選択した操作選択アルゴリズムによっては、テスト コンソールであらかじめ入力されているフィールドもあります。
たとえば、図 4-9 の転送パネルの場合、[SOAPAction] ヘッダ フィールドには "http://example.orgprocessLoanApp" と入力されています。この値は、サービス定義から取得されました (このプロキシ サービスに指定した選択アルゴリズムは [SOAPAction ヘッダ] です)。選択アルゴリズムの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」で「プロキシ サービスの追加」を参照してください。
転送パネルのフィールドに値を指定する場合、サービスのテストに直接呼び出しと間接呼び出しのどちらを使用するように選択したかに留意して (「直接呼び出し」および「間接呼び出し」を参照)、メッセージが転送レイヤを経由して処理されるかどうかに基づいて値を指定します。
プロキシ サービスを直接呼び出しでテストする場合、テスト データは、転送レイヤを経由してメッセージが処理された場合のメッセージを表す必要があります。つまり、テスト データは、メッセージが転送レイヤを放れてサービスに到達した時点で想定される状態のメッセージを表す必要があります。プロキシ サービスまたはビジネス サービスを間接呼び出しでテストする場合、テスト データは、ルート ノードまたはサービス コールアウトから送信されるデータを表します。テスト メッセージは、転送レイヤを経由して処理されます。
特定のヘッダおよびメタデータの詳細と、それらがテスト フレームワークで処理される仕組みについては、「テスト コンソールでのランタイムによる転送設定の使用方法」を参照してください。
テスト コンソールで、ヘッダの値とメタデータを指定できます。ただし、メッセージが送信されると、一部のヘッダとメタデータが修正または削除される場合があります。また、テスト実行時に、使用される転送によって一部のヘッダが無視され、その転送固有の値が使用される場合があります。
次の表で、テスト コンソールで使用するときに制限されるヘッダとメタデータについて説明します。
表 4-3 サービスをテストするときにテスト コンソールで指定する転送ヘッダとメタデータの値の制限
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|
![テスト コンソールの [セキュリティ] パネル](wwimages/test_svc_provider.gif "テスト コンソールの [セキュリティ] パネル")
![テスト コンソールの [転送] パネル](wwimages/test_transport.gif "テスト コンソールの [転送] パネル")