40 テスト・コンソールの使用

Oracle Service Busテスト・コンソールは、システムの設計の検証およびテストに使用するブラウザ・ベースのテスト環境です。これは、Oracle Service Bus管理コンソールの拡張機能です。(テスト・コンソールはEclipseでも使用できます。)テスト・コンソールで、テストするオブジェクト(プロキシ・サービス、ビジネス・サービス、XQuery、XSLT、またはMFLリソース)の構成、テストの実行、および結果の表示を行うことができます。場合によっては、コードをトレースし、特定のトレース・ポイントのメッセージの状態を調べることができます。設計時テストを行うことで、構成を本番環境にデプロイする前に設計上の問題を割り出すことができます。

テスト・コンソールでは、システムの特定部分を切り分けてテストしたり、システムを1つの単位としてテストしたりできます。クラスタ環境でテストすることもできます。ただし、クラスタ・ドメインでは、構成されたビジネス・サービス、またはビジネス・サービスにルーティングされるプロキシ・サービスのテストにはテスト・コンソールを使用することはできません。

テスト・コンソールには、次の場所からアクセスできます。

• プロジェクト・エクスプローラ

• リソース・ブラウザ

• XQueryエディタ

• Eclipse(実行およびデバッグオプションを使用)

手順の詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』の第33章「テスト・コンソール」およびOracle Service Busデバッガの使用に関する項を参照してください。

この章の内容は次のとおりです。

• 40.1項「前提条件」

• 40.2項「プロキシ・サービスのテスト」

• 40.3項「ビジネス・サービスのテスト」

• 40.4項「プロキシ・サービスとビジネス・サービスの推奨テスト・アプローチ」

• 40.5項「テスト・コンソールを使用したプロキシ・サービスのトレース」

• 40.6項「リソースのテスト」

• 40.7項「XQueryテストの実行」

• 40.8項「Webサービス・セキュリティを含むサービスのテスト」

• 40.9項「テスト・コンソールの転送設定」

• 40.10項「セキュリティと転送について」

40.1 前提条件

テスト・コンソールを使用するには、次のようにします。

• Oracle Service Busが実行中であり、テストするリソースを含むセッションがアクティブ化されています。

• XQueryテストが機能するように、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。XQueryテストは、設計時環境(アクティブ・セッション)でのみ実行されます。

• テスト・コンソール・サービスが実行されていないことを示すエラーを受信した場合は、管理サーバーがlocalhostなどの特定の有効なアドレスをリスニングするように設定してみます。Oracle WebLogic Server Consoleで、「環境」>「サーバー」>「admin_server_name」>「構成」>「一般」を選択して、「Listen address」を設定します。

• テスト・コンソールを使用してSAMLトークンを生成し、プロキシ・サービスに送信する場合は、SAMLトークンを要求し、リライイング・パーティにするように、プロキシ・サービスを構成する必要があります。SAMLリライイング・パーティの作成の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSAML 1.1リライイング・パーティの作成に関する説明を参照してください。

  
  

  注意: SAMLリライイング・パーティ作成時には、以下に留意してください。 プロキシ・サービスではWSS/Sender-VouchesプロファイルおよびWSS/Holder-of-Key SAMLプロファイルのみ使用できます。 リライイング・パーティを構成する場合、対象URLの値としてプロキシ・サービスのURIを指定します。Oracle Service Bus管理コンソールのプロジェクト・エクスプローラ・モジュールでプロキシ・サービス名をクリックすると、プロキシ・サービスのURIを表示できます。URIは、「トランスポート構成」表のエンドポイントURI行に表示されます。

  
  

40.2 プロキシ・サービスのテスト

以下のタイプのプロキシ・サービスをテストできます。

• WSDL Webサービス

• メッセージング・サービス

• 任意のSOAPサービス

• 任意のXMLサービス

40.2.1 直接呼出し

注意: 直接呼出しオプションを有効にしてプロキシ・サービスのテストを行うと、アクセス制御を含むいくつかの重要なセキュリティ手順が回避されます。Oracleは、プロダクション・システムでテスト・サービスを使用しないことをお薦めします。

直接呼出しは、同じOracle Service Busドメイン内にあるプロキシ・サービスをテストするときに使用します。直接呼出しオプションを使用すると、メッセージはトランスポート・レイヤーを経由せずにプロキシ・サービスに直接送信されます。直接呼出しオプションを使用した場合、デフォルトでトレースが有効になり、テスト・コンソールでメッセージ・フローの診断とトラブルシューティングが可能になります。デフォルトでは、プロキシ・サービスのテストは直接呼出しオプションを使用して実行されます。

直接呼出しオプションを使用してプロキシ・サービスをテストする場合、テスト・コンソールに入力する構成データは、プロキシ・サービスを呼び出すクライアントから渡されるものとしてプロキシ・サービスで想定されているデータである必要があります。つまり、テスト・コンソールは、プロキシ・サービスを呼び出すクライアントの役割を果たします。また、直接呼出しによるテストを実行するときには、メッセージのモニター・フレームワークは経由しません。

図40-1は、直接呼出しを示しています。メッセージはトランスポート・レイヤーを経由せず、プロキシ・サービス(P1)に直接配信されます。

図40-1 直接呼出しによるプロキシ・サービスのテスト

「図40-1 直接呼出しによるプロキシ・サービスのテスト」の説明

直接呼出しの方法は、プロキシ・サービスの内部メッセージ・フロー・ロジックをテストする場合に最も適しています。テスト・データでは、ディスパッチされた時点でのメッセージの予想される状態をシミュレートする必要があります。このテスト・アプローチと、テスト・コンソールの「トランスポート」パネルにあるカスタム(インバウンド)トランスポート・ヘッダーの設定を使用して、サービス呼出しを正確にシミュレートします。

40.2.2 間接呼出し

間接呼出しを使用してプロキシ・サービスをテストする場合(つまり、「直接呼出し」オプションを選択していない場合)、メッセージはトランスポート・レイヤー経由でプロキシ・サービスに送信されます。トランスポート・レイヤーでは、テストの一環としてメッセージ・ヘッダーまたはメタデータの操作を実行します。これにより、プロキシ・サービス間の実行時パスが呼び出されます。

図40-2は、間接呼出しを示しています。メッセージはまずトランスポート・レイヤーによって処理され、その後でプロキシ・サービス(P1)に配信されます。

図40-2 間接呼出しによるプロキシ・サービスのテスト

「図40-2 間接呼出しによるプロキシ・サービスのテスト」の説明

このテスト方法は、2つのプロキシ・サービスが同じJVMで実行されているときに、プロキシ・サービス間のインタフェースをテストする場合に使用することをお薦めします。このテスト・アプローチと、テスト・コンソールの「トランスポート」パネルにあるカスタム(アウトバウンド)トランスポート・ヘッダーの設定を使用して、サービス呼出しを正確にシミュレートします。トランスポート設定の詳細は、40.9項「テスト・コンソールのトランスポート設定」を参照してください。

間接呼出しを使用する場合、テストに入力する構成データは、プロキシ・サービス(たとえば、別のプロキシ・サービスのルート・ノードやサービス・コールアウト・アクション)から送信されるデータです。間接呼出しのシナリオでは、テスト・コンソールは、別のサービスへのルーティングまたはコールアウトを行うプロキシ・サービスの役割を果たします。

注意: リクエスト/レスポンスMQプロキシ・サービスに対して間接呼出しを使用しても機能しません。 また、messageIDに基づく相関を使用したMQまたはJMSリクエスト/レスポンス・プロキシ・サービスの間接呼出しからのレスポンスは、テスト・コンソールには表示されません。間接呼出しを使用してMQまたはJMSリクエスト/レスポンス・プロキシ・サービスをテストした場合、レスポンスはレスポンス・キューに保持されますが、テスト・コンソールには表示されません。 詳細は、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のMQトランスポートに関する項を参照してください。

40.2.3 HTTPリクエスト

プロキシ・サービスをテストするときに、テスト・コンソールではネットワーク経由でHTTPリクエストを送信しないため、トランスポートレベルのアクセス制御は適用されません。トランスポートレベルのアクセス制御は、Webアプリケーション・レイヤーで行われるため、Oracle Service Bus管理コンソールのトランスポート・レイヤー経由で間接呼出しが行われても、HTTPリクエストはネットワーク経由で送信されず、トランスポートレベルのアクセス制御は適用されません。トランスポート・レイヤーでのメッセージ処理については、『Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ』のアーキテクチャの概要に関する項を参照してください。

トランスポート設定の詳細は、33.4項「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。

40.3 ビジネス・サービスのテスト

以下のタイプのビジネス・サービスをテストできます。

• WSDL Webサービス

• トランスポート型付きのサービス

• メッセージング・サービス

• 任意のSOAPサービス

• 任意のXMLサービス

ビジネス・サービスをテストする場合、メッセージは必ずトランスポート・レイヤーを経由してルーティングされます。直接呼出しオプションは使用できません。サービスをテストする際にテスト・コンソールに指定する構成データは、プロキシ・サービスのルート・ノードやサービス・コールアウト・アクションなどから、そのビジネス・サービスに送信されることが予想されるメッセージの状態を表すデータです。テスト・コンソールを使用してビジネス・サービスをテストする場合、テスト・コンソールは呼出し側のプロキシ・サービスの役割を果たします。

ヒント: テスト中のビジネス・サービスがリモート・ドメインにある場合でも、テスト・コンソールで指定されたユーザー名およびパスワードが、ローカルOracle Service Busドメインに存在することを確認します。テスト・サービスは、プロキシ・サービスまたはビジネス・サービスを呼び出す前に、ローカル認証を実行します。

40.4 プロキシ・サービスとビジネス・サービスの推奨テスト・アプローチ

図40-3に示すシナリオでは、クライアントがプロキシ・サービス(P1)を呼び出します。メッセージ・フローは、ビジネス・サービスB1、プロキシ・サービスP2、プロキシ・サービスP3の順に呼び出してから、メッセージをクライアントに返します。インタフェースを番号で示しています。

図 40-3テスト・シナリオの例

「図40-3 テスト・シナリオの例」の説明

このシナリオには、有効なテスト方法がいくつもあります。以下のテスト方法をお薦めします。

• クライアント呼出しをテストする前に、特定のプロキシ・サービスへのクライアント・インタフェース以外のインタフェースのテストを完了します。つまり、図40-3に示すサンプル・シナリオでは、まずインタフェース1から4のテストを完了してから、インタフェース5をテストします。このようにして、プロキシ・サービス(P1)のメッセージ・フロー・ロジックを繰返し変更し、プロキシ・サービスへの他のインタフェースが正しく機能することを確認した上で(インタフェース5を介して)テストできます。

• システム・テストの前に、メッセージ・フローですべてのXQuery式を検証し、テストします。図40-3では、インタフェース1がXQuery式のテストを示しています。

• 間接呼出しを使用して、プロキシ・サービスからビジネス・サービスへのインタフェース(図40-3のインタフェース2)をテストします。つまり、トランスポート・レイヤー経由でメッセージをルーティングします。

• 間接呼出しを使用して、プロキシ・サービスからプロキシ・サービスへのインタフェース(図40-3のインタフェース3と4)をテストします。つまり、直接呼出しオプションを無効にします。これにより、テスト時にメッセージはトランスポート・レイヤー経由でルーティングされます。

• 最後のシステム・テストで、プロキシ・サービスP1を呼び出すクライアントをシミュレートします。図40-3では、このテストはインタフェース5によって表されています。直接呼出しを使用してインタフェース5をテストします。この方法では、テスト時にメッセージはトランスポート・レイヤーを経由しません。デフォルトでは、直接呼出しを使用するとトレースが有効になります。

• システムの今後のトラブルシューティングを容易にするために、インタフェースのテストが成功した後のメッセージの状態を保存します。インタフェース5のテストは、実際にはシステム全体のテストです。システムの他のすべてのインタフェースが正しく機能していることを確認することで、システム・エラー発生時のトラブルシューティングの範囲を絞り込むことができます。

40.5 テスト・コンソールを使用したプロキシ・サービスのトレース

プロキシ・サービスのメッセージのトレースでは、メッセージ・フローの複数のポイントでメッセージ・コンテキストとアウトバウンド通信が検証されます。メッセージを検査するポイントはOracle Service Busであらかじめ定義されています。Oracle Service Busでは、ステージ、エラー・ハンドラ、およびルート・ノードのトレースが定義されています。

トレースのステージごとに、メッセージ・コンテキストに発生した変更と、そのステージの実行中に呼び出されたすべてのサービスが含まれます。トレースには以下の情報が含まれます。

• (新しい変数) - すべての新しい変数の名前と値。+記号をクリックすると、値が表示されます。

• (削除された変数) - 削除されたすべての変数の名前。

• (変更された変数) - 値が変更されたすべての変数の名前。+記号をクリックすると、新しい値が表示されます。

• パブリッシュ - すべてのパブリッシュ呼出しが表示されます。トレースには、パブリッシュ呼出しごとに、呼び出されたサービスの名前と、outbound、header、bodyおよびattachmentの各変数の値が含まれます。

• サービス・コールアウト - すべてのサービス・コールアウトが表示されます。トレースには、サービス・コールアウトごとに、呼び出されたサービスの名前、outbound変数の値、リクエスト・メッセージとレスポンス・メッセージのheader、bodyおよびattachmentの各変数の値が含まれます。

ルート・ノードについても、ステージと同様の情報が含まれます。ルート・ノードの場合、トレースには以下のカテゴリの情報が含まれます。

• リクエスト・パスでのサービス呼出しのトレース

• ルーティングされたサービスのトレース

• レスポンス・パスでのサービス呼出しのトレース

• (リクエスト・パスの)ルート・ノードの開始ポイントと(レスポンス・パスの)終了ポイントの間でメッセージ・コンテキストに加えられた変更

40.5.1 例: プロキシ・サービスのテストとトレース

次のサンプル・シナリオでは、手順のベースとしてOracle Service Busサンプル・ドメインのプロキシ・サービスの1つ(「融資申込みの検証」例に対応しているloanGateway3プロキシ・サービス)を使用します。

テスト・コンソールを使用して、このOracle Service Busサンプル・ドメインのプロキシ・サービスをテストするには:

1. Oracle Service Busサンプル・ドメインを起動し、サンプル・データをロードします。

2. Oracle Service Bus管理コンソールにログインし、「リソース・ブラウザ」を選択してLoanGateway3プロキシ・サービスを検索します。

3. LoanGateway3プロキシ・サービスの「テスト・コンソールの起動」アイコンをクリックします。「プロキシ・サービス・テスト - LoanGateway3」ページが表示されます。「直接呼出し」と「トレースを含む」オプションが選択されていることを確認します。

4. 表示されたテスト用XMLを編集して、例40-1に示すテスト・メッセージを送信します。

   例40-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>
   

5. 「実行」をクリックします。

   結果ページの下部までスクロールして、図40-4に示す「呼出しのトレース」パネルのトレース結果を表示します。

図 40-4 loanGateway3プロキシ・サービスの呼出しのトレース

「図40-4 LoanGateway3プロキシ・サービスの呼出しのトレース」の説明

トレースでは以下が示されます。

• 初期メッセージ・コンテキスト - プロキシ・サービスが呼び出されたときに、プロキシ・サービスが初期化した変数を表示します。変数の値を確認するには、変数名に対応する+記号をクリックします。

• 変更された変数 - validate loan applicationステージでメッセージが処理された結果、$header、$bodyと$inboundが変更されました。これらの変更は、メッセージ・フローの最後に表示されます。

• ステージ・エラー・ハンドラが検証エラーを処理した結果として、faultコンテキスト変数($fault)のコンテンツが表示されます。この場合、例40-1の<java:NumOfYear>要素に整数以外の値(20.5)を入力したことが原因で検証エラーが発生しました。

別の入力パラメータを使用するか、Oracle Service Bus管理コンソールでメッセージ・フローを変更することで、プロキシ・サービスをテストできます。次に、再度テストを実行し、結果を表示します。

40.6 リソースのテスト

テストできるリソースは次のとおりです。

• 40.6.1項「MFL」

• 40.6.2項「XSLT」

• 40.6.3項「XQuery」

40.6.1 MFL

MFL (メッセージ・フォーマット言語)ドキュメントは、バイナリ・データのレイアウトの記述に使用する特殊なXMLドキュメントです。MFLリソースは、以下のトランスフォーメーションをサポートしています。

• XMLからバイナリ - 必須入力(XML)が1つと出力(バイナリ)が1つあります。

• バイナリからXML - 必須入力(バイナリ)が1つと出力(XML)が1つあります。

各トランスフォーメーションでは、入力を1つだけ受け入れ、出力を1つ返します。

40.6.1.1 例

次の例は、MFLトランスフォーメーションのテストを示しています。テスト・コンソールにより、MFLファイルからXMLドキュメントのサンプルが生成されます。XML入力を使用してテストを実行します。テストが成功すると、入力XMLドキュメントのメッセージ・コンテンツがバイナリ形式に変換されます。

例40-2に、MFLファイルの例を示します。

例40-2 MFLファイルの内容

<?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>

例40-2のMFLファイルをテストするためにテスト・コンソールで生成されるXMLドキュメントを例40-3に示します。

例40-3 テスト・コンソールでのXML入力

<StockPrices>
    <PriceQuote>
        <StockSymbol>StockSymbol_31</StockSymbol>
        <StockPrice>StockPrice_17</StockPrice>
    </PriceQuote>
</StockPrices>

テスト・コンソールで、「実行」をクリックしてテストを実行します。例40-4は、生成されたテスト・データを示しています。この結果では、銘柄記号と株価がバイナリ形式で示されています。

例40-4 MFLのテスト・コンソールでの結果

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 .. .. .. StockPrice_17|...

40.6.2 XSLT

Oracle Service Busでは、Extensible Stylesheet Language Transformation (XSLT)を使用してXML間のマッピングを記述します。XSLトランスフォーメーションは、プロキシ・サービスのメッセージ・フローでXQuery式を編集するときに使用できます。

XSLTリソースをテストするには、入力XMLドキュメントを指定する必要があります。テスト・コンソールは、出力XMLドキュメントを返します。ドキュメントに、トランスフォーメーションで使用するパラメータを作成できます。XSLTパラメータは、値としてプリミティブ型またはXMLドキュメントをとります。XSLトランスフォーメーションからパラメータの型を識別することはできません。テスト・コンソールの「XSLTリソース・テスト」ページの「入力およびパラメータ」パネルで、ドキュメントに定義されたXSLTパラメータにバインドする値を指定する必要があります。

詳細は、33.2.2項「XSLTトランスフォーメーションのテスト」を参照してください。

40.6.3 XQuery

XQueryは、データがXMLに物理的に格納されるか、XMLとして表示されるかに関係なく、XMLの構造を使用して、様々な種類のデータに対する問合せを表現します。

XQueryトランスフォーメーションは複数の入力をとる場合があります。返される出力は1つです。XQueryトランスフォーメーションに想定される入力は、定義済みの各XQuery外部変数にバインドする変数値です。XQuery入力変数の値には、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスを指定できます。出力値は、プリミティブ型の値(string型、integer型、date型)、XMLドキュメント、またはこれらの型のシーケンスになります。

XQueryは型付きの言語で、外部変数ごとに型が決まっています。型は以下のグループに分類できます。

• 単純型/プリミティブ型 - string、int、floatなど

• XMLノード

• 型なし

想定される型が単純型である場合は、テスト・コンソールに1行の編集ボックスが表示されます。想定されるデータがXMLである場合は、複数行の編集ボックスが表示されます。変数に型がない場合は、両方の組合せの入力が使用されます。テスト・コンソールに[] as XMLというフィールドが表示され、ここで変数の型を宣言できます。テスト・コンソールの入力は、入力する必要のあるデータの型がわかりやすいように、型に基づいて表示されます。

図40-5は、int、XML、および未定義の型の3つの変数を含むXQueryを示しています。

図40-5 XQueryテストへの入力

「図40-5 XQueryテストへの入力」の説明

テスト・コンソールでは、3つの変数がすべて「変数」パネルに表示されます。型なし変数には、デフォルトでXMLが選択されます。これが最も一般的なケースであるためです。「変数」パネルでこれらの変数を構成する必要があります。33.2.3項「XQueryトランスフォーメーションのテスト」を参照してください。

XQueryエディタからXQuery式をテストすることもできます。

40.7 XQueryテストの実行

XQueryテストが機能するように、ブラウザのポップアップ・ブロッカを無効にする必要があります。Internet Explorerブラウザでツールバーを使用している場合、「インターネット オプション」メニューでポップアップ・ブロッカを無効にするだけでなく、ポップアップをブロックするように構成されているすべてのツール・バーについてもこの機能を無効にする必要があります。

テスト・コンソールでXQueryテストを実行する場合、新しいテストを実行するには「戻る」ボタンを使用します。ただし、XQueryを変更した後に新しいテストを実行する場合、変更を有効にするには、テスト・コンソールを閉じて再度開く必要があります。詳細については、33.2.3項「XQueryトランスフォーメーションのテスト」を参照してください。

40.8 Webサービス・セキュリティを含むサービスのテスト

テスト・コンソールは、Webサービス・セキュリティ(WSS)で保護されたプロキシ・サービスとビジネス・サービスのテストをサポートします。WS-Securityアサーションを含むWS-Policyが割り当てられたSOAPサービスは、WSSで保護されます。具体的には、サービス操作の有効なリクエストWS-PolicyまたはレスポンスWS-PolicyにWS-Securityアサーションが含まれている場合、そのサービス操作はWS-Securityで保護されます。WS-Policyは、WS-PolicyAttachmentによってサービスに割り当てられます。詳細については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のWSDLドキュメントへのWS-Policy文の付加に関する項を参照してください。操作にリクエスト・ポリシーとレスポンス・ポリシーの両方を含めることができることに注意してください。

操作にリクエストWS-PolicyまたはレスポンスWS-Policyが含まれる場合、テスト・コンソールとサービスとの間のメッセージのやり取りはWS-Securityのメカニズムによって保護されます。テスト・サービスは、操作のポリシーに従って、デジタル署名を施すか、メッセージ(正確にはメッセージの一部)を暗号化し、該当するセキュリティ・トークンを含めます。デジタル署名操作および暗号化操作に対する入力がクリアテキストSOAPエンベロープであることを指定します。33.1.2項「プロキシ・サービスのテスト・データの構成」および33.1.6項「ビジネス・サービスのテスト・データの構成」を参照してください。

同様に、サービスは、操作のレスポンス・ポリシーに従ってレスポンスを処理します。レスポンスは、暗号化またはデジタル署名される場合があります。この場合、テスト・サービスはこのレスポンスを処理し、メッセージの復号化またはデジタル署名の検証を行います。

テスト・コンソール(「セキュリティ」パネル)には、WS-Securityを含むサービスのテストに使用するサービス・プロバイダ、「ユーザー名」および「パスワード」の各フィールドが表示されます。

テスト・コンソールでサービス・キー・プロバイダを指定すると、WS-Securityで要求されるクライアント側のすべてのPKIキー・ペア資格証明がサービス・キー・プロバイダから取得されます。操作のリクエスト・ポリシーでIDアサーションが指定されており、サポートされるトークン・タイプの1つがユーザー名トークンである場合は、「ユーザー名」フィールドと「パスワード」フィールドを使用します。

サービス・プロバイダ、「ユーザー名」および「パスワード」の各フィールドは、操作にリクエスト・ポリシーまたはレスポンス・ポリシーが含まれている場合に必ず表示されます。値が必須かどうかは、実際のリクエスト・ポリシーとレスポンス・ポリシーによって決まります。

表40-1と表40-2にセキュリティ・シナリオを示します。

表40-1 デジタル署名と暗号化のシナリオ

シナリオ	サービス・キー・プロバイダの必要性
リクエスト・ポリシーにConfidentialityアサーションがあります。	いいえ。テスト・サービスは、サービスの公開鍵でリクエストを暗号化します。プロキシ・サービスをテストする場合、テスト・サービスは、プロキシ・サービスのサービス・キー・プロバイダに割り当てられた暗号化証明書から公開鍵を自動的に取得します。 ビジネス・サービスをテストする場合、暗号化証明書はビジネス・サービスのWSDLに埋め込まれます。テスト・サービスは、WSDLリポジトリからこのWSDLを自動的に取得し、WSDLから暗号化証明書を取り出します。
レスポンス・ポリシーにConfidentialityアサーションがあります。	はい。このシナリオでは、操作ポリシーは、クライアントが証明書をサービスへ送信することを要求します。サービスは、この証明書の公開鍵を使用し、クライアントへのレスポンスを暗号化します。サービス・キー・プロバイダを指定する必要があり、このサービス・キー・プロバイダには、暗号化資格証明が関連付けられている必要があります。 リクエストとレスポンスの両方の暗号化がサポートされている場合、異なる資格証明を使用する必要があります。
リクエスト・ポリシーにIntegrityアサーションがあります。	はい。クライアントはリクエストに署名する必要があります。サービス・キー・プロバイダを指定する必要があり、このサービス・キー・プロバイダには、デジタル署名資格証明が関連付けられている必要があります。 さらに、このIntegrityアサーションがSAML holder-of-keyの場合は、サービス・キー・プロバイダに加え、ユーザー名とパスワードも必要です。
レスポンス・ポリシーにIntegrityアサーションがあります。	いいえ。この場合、ポリシーは、サービスがレスポンスに署名する必要があることを指定します。サービスは、秘密鍵でレスポンスに署名します。テスト・コンソールはこの署名を確認するのみです。 プロキシ・サービスをテストする場合、プロキシ・サービスのサービス・キー・プロバイダのデジタル署名資格証明に関連付けられた秘密鍵が使用されます。 ビジネス・サービスをテストする場合、サービスは、サービスをホストするシステムに製品固有の方法で構成されたキー・ペアを使用して署名します。 現在のセキュリティ・レルムが証明書検索および検証を実行するように構成されている場合、サービス・キー・プロバイダに割り当てられる証明書は、証明書検索および検証フレームワークに登録され、有効である必要があります。 証明書検索と検証の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の資格検索および検証フレームワークの構成に関する項を参照してください。

表40-2 IDポリシーのシナリオ(ポリシーにIDアサーションが含まれている場合)

サポートされるトークン・タイプ脚注 1	説明	コメント
UNT	サービスがWSSユーザー名トークンのみを使用	「セキュリティ」パネルでユーザー名とパスワードを指定する必要があります。
X.509	サービスがWSS X.509トークンのみを使用	「セキュリティ」パネルでサービス・キー・プロバイダを指定する必要があります。このサービス・キー・プロバイダには、WSS X.509資格証明が関連付けられている必要があります。
SAML	サービスがWSS SAMLトークンのみを使用	「セキュリティ」パネルまたは「トランスポート」パネルで、ユーザー名とパスワードを指定する必要があります。両方のパネルで指定した場合は、「セキュリティ」パネルのユーザー名とパスワードがSAMLトークンのIDとして使用されます。
UNT、X.509	サービスがUNTまたはX.509トークンを使用	「セキュリティ」パネルで、ユーザー名とパスワードを指定します。または、WSS X.509資格証明が関連付けられているサービス・キー・プロバイダを「セキュリティ」パネルで指定する必要があります。両方指定した場合は、UNTトークンのみが生成されます。
UNT、SAML	サービスがUNTまたはSAMLトークンを使用	「セキュリティ」パネルまたは「トランスポート」パネルで、ユーザー名とパスワードを指定する必要があります。両方指定した場合は、UNTトークンのみが送信されます。
X.509、SAML	サービスがX.509またはSAMLトークンを使用	次のいずれかを指定する必要があります。 「セキュリティ」パネルでユーザー名とパスワード 「トランスポート」パネルでユーザー名とパスワード WSS X.509資格証明が関連付けられているサービス・キー・プロバイダ
UNT、X.509、SAML	サービスがUNT、X.509、またはSAMLトークンを使用	次のいずれかを指定する必要があります。 「セキュリティ」パネルでユーザー名とパスワード 「トランスポート」パネルでユーザー名とパスワード WSS X.509資格証明が関連付けられているサービス・キー・プロバイダ

^脚注 1 リクエスト・ポリシー内のIDアサーションから

40.8.1 サービスとポリシーの制限

SAMLポリシーを持つプロキシ・サービスとSAML holder-of-keyポリシーを持つビジネス・サービスのテストには、以下の制限があります。

• インバウンドSAMLポリシーを持つプロキシ・サービスのテストはサポートされていません。

• SAML holder-of-keyポリシーを持つビジネス・サービスのテストは特殊なケースです。SAML holder-of-keyのシナリオは、次の2とおりの方法で構成できます。

  • 整合性ポリシーとして(推奨アプローチ)

  • IDポリシーとして

  どちらの場合も、ユーザー名とパスワードを指定する必要があります。SAMLアサーションはこのユーザーの代理として機能します。SAML holder-of-keyが整合性ポリシーとして構成されている場合は、サービス・キー・プロバイダも指定する必要があります。このサービス・キー・プロバイダには、デジタル署名資格証明が割り当てられている必要があります。これは、IDポリシーがない場合でもユーザー名とパスワードを指定する必要がある唯一のケースであり、特殊なケースです。

  
  

  注意: テスト・コンソールでテストを実行した後、WSSで生成されたエンベロープが必ずしも有効なエンベロープというわけではありません。テスト・コンソールの結果ページには、読みやすくするためにホワイト・スペースが挿入されています。つまり、保護されたSOAPメッセージは、ホワイト・スペースが追加された状態で表示されます。ホワイト・スペースはドキュメントのセマンティクスに影響する可能性があるため、このようなSOAPメッセージはリテラル・データとして必ずしも使用できるわけではありません。たとえば、デジタル署名はホワイト・スペースの影響を受け、無効になることがあります。

  
  

40.9 テスト・コンソールのトランスポート設定

テスト・コンソールの「トランスポート」パネルでは、テスト・システムのメッセージのメタデータとトランスポート・ヘッダーを指定できます。

図40-6は、WSDLベースのプロキシ・サービスの「トランスポート」パネルを示しています。

図40-6 テスト・コンソールの「トランスポート」パネル

「図40-6 テスト・コンソールの「トランスポート」パネル」の説明

プロキシ・サービスのメッセージ・フローのメタデータとトランスポート・ヘッダーを設定すると、アウトバウンド・トランスポートのアクションに影響します。メタデータ、メッセージ、およびヘッダーをテストして、パイプライン出力を表示できます。プロキシ・サービスのテスト時に「トランスポート」パネルに表示されるフィールドは、パイプラインで使用できるヘッダーとメタデータを表します。プロキシ・サービスによっては、テスト・コンソールに表示されるフィールドをフィルタ処理できない場合もあります。HTTPベースのすべてのリクエストに対して、トランスポート・パラメータの同じセットが表示されます。

「ユーザー名」と「パスワード」フィールドは、プロキシ・サービスを実行しているユーザーの基本認証を実装するために使用されます。「ユーザー名」と「パスワード」フィールドは、特にトランスポートとの関連はありません。

メタデータ・フィールドは、「ユーザー名」フィールドおよび「パスワード」フィールドと、トランスポート・ヘッダー・フィールドの間に配置されています。表示されるフィールドは、サービスのトランスポート・タイプに基づいています。サービスを定義したときに選択した操作選択アルゴリズムに応じて、あらかじめ入力されているフィールドもあります。

たとえば、図40-6に示す「トランスポート」パネルでは、SOAPActionヘッダー・フィールドに「http://example.orgprocessLoanApp」が入力されます。これは、サービス定義から取得した値です(このプロキシ・サービスに指定されている選択アルゴリズムはSOAPAction Headerです)。選択アルゴリズムの詳細は、第37章「Oracle Service Busでのメッセージ・フローの作成」を参照してください。

トランスポート・レイヤー経由でメッセージを処理するかどうか(直接呼出しと間接呼出しのどちらを使用してサービスをテストするか)に基づいて、「トランスポート」パネルの各フィールドの値を指定します。

プロキシ・サービスを直接呼出しでテストする場合、テスト・データは、トランスポート・レイヤーを経由してメッセージが処理された場合のメッセージを表す必要があります。つまり、テスト・データは、メッセージがトランスポート・レイヤーを放れてサービスに到達した時点で想定される状態のメッセージを表す必要があります。間接呼出しを使用してプロキシ・サービスまたはビジネス・サービスをテストする場合、テスト・データは、ルート・ノードまたはサービス・コールアウトから送信されるデータを表します。テスト・メッセージは、トランスポート・レイヤー経由で処理されます。

特定のヘッダーおよびメタデータの詳細と、テスト・フレームワークでそれらが処理される仕組みについては33.4項「テスト・コンソールでのランタイムによるトランスポート設定の使用方法」を参照してください。

40.10 セキュリティとトランスポートについて

テスト・コンソールを使用してBASIC認証でHTTPビジネス・サービスをテストする場合、テスト・コンソールは、ビジネス・サービスのサービス・アカウントのユーザー名とパスワードを認証します。同様に、認証を必要とするJMS、電子メール、またはFTPビジネス・サービスをテストする場合、テスト・コンソールは、そのビジネス・サービスに関連付けられたサービス・アカウントを認証します。

テスト・コンソールでは、プロキシ・サービスをテストするときに、HTTPリクエストはネットワーク経由で送信されません。そのため、トランスポート・レベルのアクセス制御は適用されません。