Cisco ACE XML Gateway ユーザ ガイド
仮想サービスに関する作業
仮想サービスに関する作業
発行日;2012/02/01 | 英語版ドキュメント(2009/11/20 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 8MB) | フィードバック

目次

仮想サービスに関する作業

仮想サービスについて

WSDL インポートによるサービスの仮想化

WSDL インポートのトラブルシューティング

SOAPAction と SOAP メソッド名について

BPEL WSDL ファイルのインポート

テスト メッセージの送信

基本仮想サービスの手動作成

マルチ オペレーション仮想サービスに関する作業

マルチ オペレーション仮想サービスの作成

サービス オペレーションの上書き

上書きしたオペレーションの復元

マルチ オペレーション仮想サービスに関するその他の作業

次の手順

仮想サービスに関する作業

この章では、ACE XML Gateway のポリシー内で外部サービスのトラフィック処理を設定する方法を説明します。内容は次のとおりです。

「仮想サービスについて」

「WSDL インポートによるサービスの仮想化」

「テスト メッセージの送信」

「基本仮想サービスの手動作成」

「マルチ オペレーション仮想サービスに関する作業」

「次の手順」

仮想サービスについて

特定のバックエンド サービスの設定は、 仮想サービス によってポリシー内にカプセル化されます。仮想サービス ポリシー オブジェクトには、特定のサービスのトラフィックに適用される検証と処理の指示が入っています。ACE XML Gateway が特定のバックエンド サービスのトラフィックを処理できるようにするには、そのバックエンド サービスの接続設定を持つ仮想サービスを作成します。

図 4-1 に、ACE XML Manager ポリシー内にある retrieveQuote submitOrder 、および submitPayment という名前の 3 つの仮想サービスを示します。

図 4-1 仮想サービス オブジェクト

 

図 4-1 内の各仮想サービス オブジェクトは、ソース Web Services Description Language(WSDL)内のオペレーションに対応します。各オペレーションの設定は、個別に設定されます。複数のオペレーションを 1 つのユニットとして管理したい場合は、マルチ オペレーション仮想サービスを使用することもできます。この場合、WSDL 内のサービス要素からのすべてのオペレーションがその仮想サービスに含まれます。

図 4-2 マルチ オペレーション仮想サービス

 

仮想サービスの名前をクリックすると、サービス設定ページが表示されます(図 4-3 を参照してください)。

図 4-3 仮想サービスの設定

 

設定には、ユーザ インターフェイスとバックエンド インターフェイスが含まれていることに注目してください。デフォルトでは、1 つの仮想サービスに、ユーザ インターフェイスとバックエンド インターフェイスの両方が含まれます。このタイプの仮想サービスは、基本仮想サービスと呼ばれ、ACE XML Gateway を通るシンプルで分岐のないメッセージ ルートを含みます。

分岐ルーティングやプロトコル メディエーションなどの拡張機能には、追加のポリシー オブジェクトを持つ仮想サービスを表す必要があります。 拡張仮想サービス は、1 つまたは複数のハンドラ、サービス記述子、およびルートから成ります。


) 詳細については、「仮想サービスについて」および第 5 章「ハンドラ、ルート、およびサービス記述子の使用方法」を参照してください。


仮想サービスの設定は、次のように分類できます。

一般設定では、仮想サービスの名前とロギング プロパティ、およびサービスによって表されるプロトコル(HTTP POST、SOAP Document など)を指定します。

ユーザ インターフェイスの設定では、サービスが ACE XML Gateway でどのようにアクセスされるかを定義します。

バックエンド サービスの設定では、サービス ホストへの接続情報を指定します。

メッセージ仕様の設定には、要求および応答トラフィックの仕様が含まれます。

コンテンツ スクリーニング ルールでは、メッセージ コンテンツに基づいてメッセージをブロックしたり修正したりできます。

アクセス コントロールの設定は、サービスにアクセスするためのユーザの権限付与条件を決定します。

以降では、これらの設定について詳しく説明します。

WSDL インポートによるサービスの仮想化

ACE XML Gateway のためのポリシー作成を最も簡単に開始する方法は、Web サービス コンフィギュレーション ウィザードを使用することです。このウィザードは、ACE XML Gateway で仮想化するバックエンド サービスを表す WSDL に基づいてポリシー オブジェクトを生成します。また、このウィザードは、UDDI レジストリにクエリーを実行することによりサービスを発見することもできます。


) RPC スタイルまたは Document スタイルの WSDL をマネージャにインポートできます。WSDL は、リテラル スタイルまたはエンコードされたスタイルでの使用状況を示すことができます。ただし、マネージャが ACE XML Gateway で仮想化されるサービスを表す WSDL を生成する場合は、RPC/リテラルだけ、または Document/リテラル WSDL だけを生成し、エンコードされたスタイルの WSDL(WS-I 準拠ではない)は生成しません。WSDL の生成の詳細については、「ACE XML Gateway でのサービスに対する WSDL の生成」を参照してください。


サービス発見後は、サービスをポリシーにインポートするオプションが得られます。インポートを行うと、ACE XML Gateway でサービスを効果的に仮想化するポリシー オブジェクトが生成され、そのサービスのトラフィックが ACE XML Gateway を通ってルーティングされることが可能になります。これらのオブジェクトには、仮想サービス(つまりハンドラとサービス記述子)、サーバ オブジェクト、およびポートが含まれます。

WSDL インポートとサービス発見に関して注意すべき点を次に示します。

UDDI レジストリでサービスを発見するには、そのレジストリの問い合せ URL を知っている必要があります。

WSDL ファイルは、ファイル システムまたはネットワーク上の場所(URL による)から直接インポートできます。ただし、WSDL に URL 参照が含まれており、ファイル システムの場所からの WSDL のインポートを試みる場合は、正常にインポートするには URL 参照が完全修飾 URL(相対 URL ではなく)でなければなりません。

WSDL のインポートによってポリシー設定を生成する手順は次のとおりです。


ステップ 1 ACE XML Manager の Web コンソールに Administrator ユーザまたは Routing ロールを持つ Privileged ユーザとしてログインした状態で、操作メニューの [Virtual Services] リンクをクリックして、[Virtual Services] ページを開きます。

ステップ 2 [Virtual Services] メニューから [Start Virtual Web Service Wizard] を選択し、[Go] をクリックします。

仮想サービス ブラウザのページの上端にメニューが表示されます。

ステップ 3 [Locate Service] メニューで、インポートする WSDL のソースを次のオプションから選択します。

[Import WSDL File from URL or Disk]

[Discover on UDDI Registry]

図 4-4 [Locate Service] のオプション

 

ステップ 4 [Import WSDL File from URL or Disk] オプションを選択した場合は、次の手順で、ディスク ファイル システムの場所から WSDL ファイルにアクセスします。

a. [Browse] ボタンをクリックします。

b. [File Upload] ダイアログボックスのコントロールを使用して、WSDL ファイルを指定します。選択した WSDL ファイルのパスが [Import a New WSDL File] ページの [File] フィールドに表示されます。

セキュリティ上の理由から、マネージャは、ディスク上の場所からインポートされた、相対 URI で識別されるリソース(スキーマ ファイルなど)の import 文を持つ WSDL ファイルは受け付けません。ACE XML Manager は、 import 文に完全修飾リソース識別子が入っていることを要求します。

次の手順で、URL によってネットワーク上の場所から WSDL ファイルを取得することもできます。

a. WSDL ファイルの場所を示す URL を指定します。

b. WSDL へのアクセスに認証が必要な場合は、[Click here to enter a username and password for WSDLs protected by HTTP Basic Auth] というラベルの付いたエキスパンダ コントロールをクリックして、ユーザ名とパスワードを入力します。

ステップ 5 [Discover on UDDI Registry] インポート オプションを選択した場合は、次の手順を実行します。

a. [UDDI Inquiry URL] フィールドに、次のようなサービス問い合せのために UDDI が示す完全 URL を入力します。

http://uddihost.example.com:8090/uddi/inquiry

b. 必要であれば、UDDI サーバの公開 URL を [UDDI Publish URL] フィールドに入力し、UDDI サーバへの公開アクセス権限を持つユーザ アカウントのユーザ名とパスワードを入力します。

ほとんどの場合、問い合せ API 値はサービス発見に十分です。ただし、公開される情報のパスワード保護を達成するために、多くの場合、レジストリは公開 API メカニズムを使用します。レジストリがこれを行うために、公開 URL を [UDDI Publish URL] フィールドに入力し、ユーザ名とパスワードを入力します。

c. ソース UDDI レジストリがバージョン 3 の場合は、レジストリのセキュリティ URL をユーザ名およびパスワードと一緒に指定する必要があります。使用する値がわからない場合は、UDDI レジストリの管理者に問い合せてください。

d. [Continue] をクリックします。

しばらくすると、ACE XML Manager に、その UDDI レジストリで見つかったサービスが表示されます。[WSDL details] を展開すれば、WSDL に関するより詳細な情報が表示されます。

サービス発見で UDDI ソースに対するサービスが見つからなかった場合は、次のページにその事実が示されます。

ACE XML Manager は、UDDI レジストリで参照されているすべてのリンクの解決を試みますが、必ずしもそのすべてが WSDL を参照しているというわけではありません。この場合、次のようなメッセージが表示されます。

The following URLs were found, but did not refer to readable WSDLs

WSDL の読み取り試行は、次のような場合にも失敗します。

WSDL が無効である。

リンクが HTTP 404 応答(ファイルが見つからない)になるか、ネットワークまたはセキュリティ上のその他の問題が解決できない。

リンクへのアクセスに認証が必要である。

WSDL がその他のファイル(通常は XML スキーマまたはその他の WSDL)をインポートしており、それが何らかの理由で取得できない。

e. サービス発見が成功した場合は、[Choose WSDL] ページで、インポートするサービスのラジオ ボタンをクリックし、[Continue] をクリックします。

ステップ 6 [Consumer Interface] ページで、ACE XML Gateway でサービスを公開するのに使用するポートを [HTTP Port] メニューから選択します。ほとんどの場合、デフォルト値で受け付けられます。

ステップ 7 [Exposed Path] で、必要に応じて、ACE XML Gateway でのサービスの公開に使用するデフォルト URL を変更します。このパスは、クライアントが Gateway でのサービスへのアクセスに使用する完全 URL を形成するために、ACE XML Gateway のホスト名に追加されます。

ステップ 8 デフォルトでは、ウィザードは、WSDL 内の接続情報に基づいて、ポリシー内にサーバ オブジェクトを作成します。WSDL 内で示されているサーバではなく、メニューから選択したサーバを使用するには、[Override host '<host>' in WSDL with] というラベルの付いたチェックボックスを選択します。メニューから選択したサーバは、WSDL のインポートで得られた仮想サービスのためのバックエンド サービスになるように設定されます。

このオプションを選択した場合、WSDL 内のホスト用のサーバ オブジェクトは作成されません。このオプションは、WSDL 内で示される(ラベルでも示されている)サービスのホストが、Gateway が発信要求の中で実際に指定する必要のあるバックエンド ホストではない場合に便利です。メニューに、ポリシー内で定義されているサーバがリストされます。詳細については、 第 14 章「宛先サーバ設定の指定」、 を参照してください。

ステップ 9 サービスのアクセス コントロール設定を選択します。アクセスなし、公開アクセス、コントロールされたアクセスのいずれかを選択できます。コントロールされたアクセスでは、ユーザが、選択された権限付与グループで指定される要件を満たしていなければなりません。

公開アクセスを使用すれば、アクセス ポリシーを作成するよりも前にサービス設定をテストできます。ただし、ほとんどの場合、サービスへのアクセスは最終的には何らかの形でコントロールする必要があるでしょう。詳細については、 第 6 章「サービスへのアクセス コントロール」 を参照してください。

ステップ 10 [Default Message Logging] オプションには、サービスのログレベルを選択します。初期の作成とテストでは、ログ メッセージの本文もあった方が便利でしょう。一方、トラフィックの生成やパフォーマンスのテストには、統計情報だけをロギングしてください。


) ログレベルは、後から [Handler Group] 設定ページでまとめてすべての操作に対してリセットすることができます。


ステップ 11 必要に応じて、[Advanced Options] という見出しの横のエキスパンダ コントロールをクリックして、次の設定値を設定します。

[Import Bindings] WSDL で、それが記述するオペレーションに複数のプロトコル バインディングを指定できます。インポートするプロトコルを SOAP、HTTP GET、HTTP POST の中から 1 つまたは複数選択できます。この選択は、インポートの結果としてポリシー内で作成される仮想サービスのプロトコル タイプを決定します。通常は、複数のバインディング(WSDL がそれらを持つ場合)が同じ一連のサービスを記述するため、バンディングはデフォルト オプションの SOAP のままにしておいてかまいません。

[Validate the WSDL file before importing] このオプションで、ACE XML Manager が WSDL をインポートする前にそれが有効かどうかをチェックするようにできます。WSDL は、WSDL 仕様のスキーマに対してチェックされます。WSDL が無効だった場合は、ACE XML Manager の結果ページに 1 行ごとのエラーが表示されます。

[Strip elementFormDefault attributes from XML schemas imported from WSDL files] このオプションは、このアトリビュートを不正確に実装したフレームワークによって生成された WSDL を使用する RPC スタイルのサービスをインポートしようとした場合に発生する問題を回避できます。

このオプションを選択すると、WSDL のインポート時に SOAP RPC 仮想サービスに対してこの要素が削除されます(SOAP Document スタイル仮想サービスには影響はありません)。何らかのフレームワークによって elementFormDefault に誤って qualified の値が与えられると、ACE XML Manager が WSDL を正常にインポートできなくなります。

[Configure SOAP Document virtual services to match requests based on SOAP method in addition to SOAPAction] Document スタイルの SOAP サービスが、メッセージによって指定されたオペレーションを見分けるために SOAP メソッド値を使用する場合、このオプションを選択して、ACE XML Gateway に、SOAP メソッドと SOAPAction の両方の値に基づいて、トラフィックと生成された仮想サービスを比較させてください。

一部の仮想サービスでは、サービスの起動を明確にするためにこれが必要です。SOAP メソッドは、SOAP メッセージの SOAP 本文の最初の子ノードです。

このオプションは、ACE XML Manager が SOAPAction だけでは WSDL 内のオペレーションを明確にできないことを検出した場合に、自動的にイネーブルになります。

詳細については、「SOAPAction と SOAP メソッド名について」を参照してください。

[Condense SOAP Document operations into one virtual service per WSDL "Service" element, if possible] SOAP Document を定義する WSDL をインポートする場合は、WSDL 内の各オペレーションに対して仮想サービスを作成することもできれば、WSDL の各サービス要素からのオペレーションを組み合わせて 1 つの仮想サービスにすることもできます。

凝縮された仮想サービスを使用すると、関連する複数のオペレーションのための設定値を設定する単一のポイントが得られるので、このオプションはイネーブルのままにしておくことを推奨します。特定の設定が必要なオペレーションがある場合は、共通仮想サービス内で後からそのオペレーションの定義を上書きできます。


) WSDL のインポートによって生成されたマルチ オペレーション仮想サービスを拡張仮想サービスに直接変換することはできません。詳細については、「マルチ オペレーション仮想サービスに関するその他の作業」を参照してください。


詳細については、「マルチ オペレーション仮想サービスに関する作業」を参照してください。

[Create a separate handler and service descriptor for each operation] これを選択すると、ACE XML Manager は、サービス オペレーションのための基本仮想サービスではなく、独立したハンドラとサービス記述子を作成します。分岐ルーティングを使用したい場合(つまり、メッセージが単一のユーザ インターフェイスと複数のバックエンド サービスの間で、あるいはその逆でルーティングされるようにする場合)、または応答キャッシング、引数マッピングなどの基本仮想サービスでは使用できないその他の機能を使用したい場合に、このオプションを選択します。

ほとんどの場合、このオプションはオフのままにしておくことができ、必要であれば、仮想サービスを後から拡張モードに切り替えることができます。

詳細については、 第 5 章「ハンドラ、ルート、およびサービス記述子の使用方法」 を参照してください。

[Create a direct-mapping route between each handler and service instead of a pass-through route] 次のモードに従って、ACE XML Gateway がどのようにメッセージを処理するかを制御します。

直接マッピングでは、受信メッセージが ACE XML Gateway で分解され、ポリシー設定および Gateway の通常の正規化の方法に従って再生成されます。メッセージ プロトコルにとって標準ではないヘッダー要素やその他のメッセージ要素、およびそのポリシー設定内で特別に提供されたヘッダー要素やその他のメッセージ要素は、削除されます。このオプションでは、最も強化されたセキュリティを使用でき、メッセージの正規化という利点がありますが、予期しない統合問題が発生する可能性があります。

パススルー ルートでは、自由度が上がります。メッセージを完全に分解して再生成するのではなく、ACE XML Gateway は、予想しなかったヘッダーおよびその他のメッセージアトリビュートも送信インターフェイスに反映されます。

直接マッピング モードでは予期しない変更がメッセージに加えられる可能性があるため、自分の事例にこのモードが適しているとはっきり確信がある場合以外は選択しないでください。

[Subscribe to updates of this WSDL from UDDI] UDDI 発見を使用して仮想サービスを生成する場合で、その UDDI レジストリが UDDI バージョン 3 をサポートしている場合は、WSDL への変更をサブスクライブできます。この機能がイネーブルになっている場合、Manager は、[Imported WSDL Files] ページへのアクセスがあるたびに UDDI レジストリをポーリングします。ソース WSDL が変更されていた場合は、ポリシーが最新ではなくなっていることを知らせるメッセージがページ上に表示されます。この場合、[Imported WSDL Files] ページから WSDL を更新できます。これにより、その変更内容がソースから作業ポリシーに反映されます。

WSDL アップデートをサブスクライブするには、チェックボックスをイネーブルにし、オプションの下にある URL フィールドを設定します(ほとんどのフィールドには、WSDL 発見ページで入力した値が最初から入っています)。実際に使用する値については、Universal Description, Discovery and Integration(UDDI)レジストリの管理者に問い合せてください。

ステップ 12 完了したら、[Continue] をクリックします。

ステップ 13 一連のページの最後のページでは、変更内容を ACE XML Gateway に導入する(ACE XML Gateway を通じてサービスを利用できるようにする)か、承認を要求するか、またはコンソールの他のページに移動して作業を続けます。承認ベースの導入がイネーブルになっていて、使用中のアカウントにポリシーを導入するための特権が与えられていない場合は、最後のページに [Request Approval] ボタンが表示されます。これを使用して、承認要求プロセスを開始します(詳細については、 第 29 章「ポリシーの導入」 を参照してください)。


 

作成されたポリシー オブジェクトには、サービス設定のための最小限の設定値が含まれています。ほとんどの場合、アクセス要件、暗号化の動作、メッセージ検証要件、およびその他の設定とサービスに関連付けられている動作を追加することになります。

WSDL インポートのトラブルシューティング

WSDL インポート プロセスは、常に正常に完了するとは限らず、さまざまな問題がその原因として考えられます。WSDL ファイルを Web サービス記述言語を定義する XML スキーマに対して検証すると、一部の問題を回避する助けとなる場合があります。このオプションの動作がイネーブルになっていると、ACE XML Manager は、WSDL ファイルをインポートする前にそのファイルを検証しようとします。検証に失敗したり、WSDL ファイルが構文上正しくない XML だったりすると、ACE XML Manager はその WSDL ファイルをインポートしません。

インポート エラーを生成する状況の例を次に示します。

WSDL ファイルが、有効なターゲット名前空間を定義していない埋め込み XML スキーマを使用している。 WSDL ファイルを、有効なターゲット名前空間を提供する修正したバージョンに置き換える必要があります。

WSDL ファイルに重複したオペレーション名が含まれている。 このエラーは、WSDL ファイルを手作業で編集して重複したオペレーションを削除することにより修正できる可能性があります。

WSDL ファイルが定義されていない複合タイプを参照している。 WSDL ファイル内のエラーを修正する必要があります。

WSDL ファイルが他の WSDL ファイルをインポートしており、そのファイルが利用可能でない。 WSDL ファイルを編集してその依存関係をなくすか、またはインポートされる WSDL ファイルを利用可能にする必要があります。

WSDL ファイルに対する、後から利用可能にする予定の URL を指定することでは、この問題は解決されません。セキュリティ上の理由から、ACE XML Gateway は、ポリシーの実施中に WSDL やその他のリソースをダウンロードすることは一切しません。これらのリソースは、ポリシーの導入準備の段階でダウンロードします。このため、導入前に、すべての WSDL およびその他のリソース ファイルがポリシーから利用できるようにしておく必要があります。

WSDL ファイルが、利用できない XML スキーマをインポートしている。 WSDL ファイルを編集して依存関係をなくすか、インポートされる XML スキーマを利用可能にする必要があります。

All external files the WSDL ファイルがインポートする外部ファイルは、XML スキーマ ファイルも含めてすべてが、導入よりも前にポリシーから利用できるようになっている必要があります。

WSDL ファイルが利用できない他の WSDL ファイルまたは XML スキーマをインポートしていることが原因でインポートに失敗した場合、問題を修正するには 2 通りの方法があります。1 つ目は、必要なその他の WSDL ファイルまたは XML スキーマ ファイルを手作業でインポートすることです。これが実際的な解決方法でない場合は、WSDL ファイルを編集して、利用できないファイルへの参照を削除します。ただし、多くの場合、手作業で WSDL ファイルを編集してうまくインポートできるファイルにすることは、たとえ可能であったとしても簡単なことではありません。

SOAPAction と SOAP メソッド名について

SOAPAction は、オペレーション間の区別を支援する HTTP ヘッダーとして SOAP 1.1 仕様で定義されています。これは、SOAP 1.1 の必須ヘッダーです。HTTP 要求は、少なくとも 1 つの空の SOAPAction ヘッダーがなければ、SOAP 1.1 要求として認識されません。SOAP 1.2 では、これは省略可能です。特に、SOAP 1.2 では、これは HTTP Content-type ヘッダーへのオプションの改正として定義されています。

SOAP メソッド名は、SOAP RPC スタイルのメッセージだけに適用される概念です。RPC スタイルの SOAP では、メソッド名は、SOAP Body 要素の最初の子の完全修飾名です。SOAPAction は Document スタイルの SOAP サービスを識別するため、SOAP Body のコンテンツを検査するのに受信ノードは必要ありません。SOAP メソッド名は、一般に、SOAPAction に空の値または汎用的な値が格納された RPC スタイルの SOAP サービスの識別に使用されます。

一部の SOAP フレームワークは、この変換を厳密に検査せず(たとえば、WebLogic 8)、その代わりに同じ SOAP アクションを持つオペレーションで WSDL ファイルを発行します。こういった場合のために、ACE XML Gateway には、ハンドラに割り当てられていた場合には受信メッセージの Body 要素の名前と名前空間を考慮しなければならないことを示す、SOAP Document スタイルのハンドラ用のオプションのフラグが用意されています。このフラグは、WSDL のインポート時にセットするか(ACE XML Manager は、通常、このオプションが必要かどうかを判断でき、必要であれば WSDL インポート時にイネーブルにできます)または SOAP ドキュメント ユーザ インターフェイスの設定からセットできます。

ACE XML Gateway は、受信 SOAP メッセージが期待される SOAPAction 値を持っているかどうかを常にチェックします。RPC スタイルの SOAP サービスには、常に完全修飾 SOAP メソッド名(名前と名前空間を持つ)がチェックされます。Document スタイルのサービスには、フラグがセットされている場合にだけ、Body Entry 要素の要素名と名前空間がチェックされます。

BPEL WSDL ファイルのインポート

Business Process Execution Language(BPEL; ビジネス プロセス実行言語)は、複数のトランザクション、参加者、およびサービスを含んでいて複雑になる可能性があり、長期にわたって実行されるプロセスをモデリングするための言語です。BPEL は、プロセス参加者間の相互作用のための Web サービスの使用を規定します。このため、BPEL 情報が WSDL に含まれる場合があります(WSDL 拡張の形で)。

BPEL 定義を含む WSDL を ACE XML Manager にインポートすると、Manager は BPEL 情報を認識して保持し、それを WSDL インポートの結果として生成されたポリシー オブジェクトに関連付けます。この情報は、ACE XML Gateway によるサービスのメッセージの処理には影響せず、サービス エンドポイントによってしばしば必要とされます。このため、これらのサービスのための Gateway ポリシーから WSDL を生成すると、ACE XML Manager は生成された WSDL に BPEL 情報を反映します。

ACE XML Manager と Gateway での BPEL のサポートについては、次の点に注意してください。

BPEL 1.1 がサポートされています(BPEL 2.0 はサポートされていません)。

インポート時に、Manager が WSDL を検証できます。ただし、ACE XML Manager は、BPEL で定義されたスキーマに照らし合わせて WSDL をチェックすることはしません。WSDL スキーマに対するチェックを行うだけです。

BPEL 情報のインポートは、WSDL の内容に基づいて、WSDL インポート時に自動的に行われます。この機能のために設定しなければならないインポート オプションはありません。インポート時に、BPEL 拡張が WSDL 内に見つかったのでインポートされるということを知らせるメッセージが、Manager の Web コンソールに表示されます。

テスト メッセージの送信

ACE XML Manager には、サービス設定をテストするために使用できる組み込みの HTTP クライアント テスト ツールが含まれています。テスト メッセージは、次のいずれかに対して発行できます。

サービス インターフェイス。バックエンド サービスに直接要求を送信するインターフェイスです。これは、主にバックエンド サービスへの接続をテストするためのもので、ACE XML Gateway によるメッセージの処理と検証をバイパスします。サービス インターフェイスをテストするための仮想サービス定義を作成した後は、ポリシーを導入する必要はありません。これは、エコー サービスには使用できません。

ユーザ インターフェイス。Gateway で公開されているサービスの URL に要求を送信するインターフェイスです。ACE XML Gateway が、メッセージに対して十分な検証と処理を実行します。このオプションは生のトラフィックを Gateway に送信するため、最後に導入されたポリシーがメッセージに適用されます。

仮想サービスをテストする手順は次のとおりです。


ステップ 1 サービス設定ページの下端にあるテスト メニューで、[Test Consumer Interface] または [Test Service Interface] を選択します。

ステップ 2 [Test] ボタンをクリックします。

テスト ブラウザが表示されます。可能な場合には、ACE XML Manager が、サービスに適した要求テンプレートを生成します。テンプレートは、ハンドラの現在動作しているバージョンではなく、導入されているバージョンに対して生成されます。

ステップ 3 仮想サービスに複数のオペレーションが含まれている場合は、[Test Operation] メニューからオペレーションを選択します。

ステップ 4 必要に応じて、[Basic Auth] 設定などのその他の設定も変更し、[Send Test Message] をクリックします。

メッセージが、選択したインターフェイスに送信されます。完了したら、応答ページが表示されます。このページには、応答メッセージの本文、および成功の応答だったかエラー応答だったかが表示されます。


 

応答ページからは、次の操作が行えます。

[Back to Request Page] をクリックして、要求ページに戻ります。

[Message Body] を展開して、元の要求を表示します。

生の応答を展開して、応答を元の形式で表示します。[Response] エリアに表示される応答は、読みやすく表示を整えるために、Manager によって改行やスペースが加えられている場合があります。

基本仮想サービスの手動作成

保護したいサービスの WSDL が入手できない場合は、ここで説明する手順に従って、仮想サービスを手動で作成できます。


ステップ 1 Administrator ユーザまたは Routing ロールを持つ Privileged ユーザとして Web コンソールにログオンした状態で、アクティブ サブポリシーを作成したポリシー オブジェクトを入れるポリシーに設定します。

ステップ 2 操作メニューの [Policy] エリアで、[Virtual Services] リンクをクリックします。

ステップ 3 ページの右上にある [Virtual Services] ページ メニューから [Create a Basic Virtual Service] を選択し、[Go] ボタンをクリックします。

ステップ 4 この定義の適用対象とするサービスのプロトコルを [Select the protocol that this service uses] メニューから選択します。SOAP RPC スタイルまたは Document スタイルのプロトコル、またはいずれかの HTTP オプションを選択します。

HTTP プロトコル オプションは、HTTP 仕様で定義されている標準機能です。一方、HTTP POST には、次の 2 つのオプションがあります。

[HTTP(S) POST Body]:これは、基本 HTTP POST サービスです。このサービスでは、受信要求に XML または生データのいずれかの形で本文コンテンツが含まれているものと想定されます。

[HTTP(S) POST Arguments]:この場合、[HTTP(S) POST Body] と同様に、本文に XML または生データが含まれていてかまいませんが、要求に(HTTP GET サービスと同様)URL 引数も含まれていてもかまいません。Gateway に要求内の本文と URL 引数の両方を処理させる場合には、このプロトコルを使用します。


) メッセージング プロトコルなどのその他のプロトコルを使用するサービスについては、基本仮想サービス オブジェクトではなく、拡張仮想サービス(ハンドラとサービス記述子で構成される)を使用しなければなりません。


ステップ 5 [Continue] をクリックします。

ステップ 6 [General Information] ページで、[Name] フィールドに仮想サービス オブジェクトの名前を入力します。この名前は、基本仮想サービスに対して一意でなければなりません。

最終的には、このポリシーに多数の仮想サービスが含まれる可能性があるので、仮想サービス間の区別がつきやすい意味のある名前を選択しておくことを推奨します。

ステップ 7 サービスをホストするバックエンド サーバを [Server] メニューから選択します。

サーバがメニューに表示されない場合は、そのサーバの設定をポリシーに追加する必要があります。サーバをポリシーに追加するには、[Add a New Server] をクリックします。詳細については、 第 14 章「宛先サーバ設定の指定」 を参照してください。

ステップ 8 [Continue] ボタンをクリックします。

[Service Interface] ページが表示されます。このページに表示される設定は、HTTP、SOAP などのプロトコルごとに異なります。次の一覧では、プロトコル固有の設定は、その旨をカッコに入れて示してあります。

[Service Interface] ページに表示されるコントロールは、次のとおりです。

[Path On Server]:このサービスにアクセスするための URL パス。この値は、サービスの公開されたローカル パス(つまり、Gateway がこのサービスを公開する URL パス)と、バックエンド サービス パス(このサービスを起動するバックエンド サーバのパス)の両方に使用されます。この 2 つに異なる値を与える必要がある場合は、仮想サービスの初期設定を完了した後に、[Consumer Interface] と [Backend Service] の設定から値を変更できます。

[Replace back references using regular expression matches from the handler path]:デフォルトでは、[Path on Server] フィールドのリテラル値が、バックエンド サーバ上のリソースを要求するために使用されます。このオプションをイネーブルにすると、Gateway は、[Path On Server] フィールド内のプレースホルダを要求されたサービス パスの正規表現によって一致した値で置き換えます。[Path on Server] フィールド内のプレースホルダは、バックスラッシュと数字で示されます(\1、\2 など)。

このオプションをチェックすると、逆参照代入が可能になります。この機能の詳細については、 第 9 章「パスでの変数の使用」 を参照してください。

[Timeout] :仮想サービスがバックエンド サーバからの応答を待って待機する秒数。この秒数が経過すると、仮想サービスはトランザクションを破棄します。デフォルト値は 90.0 秒です。この値を変更するには、[Timeout] フィールドに正の数値を入力します。トランザクションが破棄されると、ACE XML Gateway は、要求元に 500 タイムアウト エラーを返します。

[SOAP Version](SOAP Document、SOAP RPC):このサービスでトランザクションに使用する SOAP プロトコルのバージョン。デフォルト値は、SOAP 1.1 です。公開したいサービスが SOAP 1.2 の場合は、メニューからそれを選択します。

[SOAPAction](SOAP Document、SOAP RPC):サービスの SOAPAction。ここに値を指定した場合、ユーザの要求に SOAPAction が含まれていなければならなくなります。同様に、SOAPAction は、バックエンド サービスに送信される要求の中でも使用されます。

SOAPAction は、要求の応答側を、通常はサービス パスの形で指定します。SOAPAction の定められた用途は、要求と応答側を複数の候補の中から 1 つに指定することです。これにより、サービス アドレスの指定に新たな次元が加えられます。これは、たとえば受信者サービスが複数のプロトコルでのトラフィックをサポートしている場合などに必要とされる可能性があります。実際には、多くの場合は区別の必要はなく、メッセージ内の SOAPAction フィールドは空です。

サービス記述子がこの値を自動的に二重引用符で囲むため、このフィールドに引用符を入力する必要はありません。このフィールドに何も入力しないと、サービスから SOAPAction ""(空の文字列)を要求することになります。

[SOAP Method](SOAP RPC):SOAP RPC サービスの場合は、これはターゲットとなるオペレーションを識別する必須値です。

[SOAP Method Namespace](SOAP RPC):SOAP RPC では、RPC 要求のターゲットとなるメソッドは、Body 要素に続く要素の名前により識別されます。このフィールドには、ターゲット応答側を識別するメソッドの名前空間を入力します。

[Service Time Threshold]:タイムアウトと似ていますが、要求を破棄するのではなく、Gateway がイベントをログに記録し、応答を待っての待機を続行します。

ステップ 9 [Continue] をクリックします。

ステップ 10 [Step 4 of 5: Request Message Specification] ページで、受信要求メッセージの要件を指定します。ACE XML Gateway は、要求を受信したら、メッセージを検証して、期待される形式になっているメッセージだけがバックエンド サービス プロバイダーに到達することを保証します。

要求メッセージ使用を設定する方法は、プロトコルごとに次のように異なります。

SOAP RPC の場合:

a. 次の SOAP メッセージ検証オプションから選択します。

[Well-formed: require that the SOAP message is well-formed XML; reject malformed messages]:適格性のチェックにより、バックエンド サービスに到達するメッセージが有効な XML であることを保証します。これにより、アプリケーションは、無効な要求に対処する必要がなくなります。また、これは、コンテンツ ベースの攻撃を防ぐ助けともなります。

[Content: require SOAP message validation with the specified XML schemas; reject invalid messages]:メッセージが指定したスキーマに準拠していなかった場合、そのメッセージはブロックされます。

[Content (passive): validate the SOAP message with the specified XML schemas; allow invalid messages but log an event]:メッセージが指定したスキーマに準拠していなかった場合、イベントがログに記録されますが、メッセージはバックエンド サーバに渡されます。

b. [Add a New Row] をクリックし、引数指定フォームで次のフィールドに入力することにより、検証する引数を指定します。

[Name]:要求に現れる引数の名前。たとえば、次のような引数を受け取る SOAP RPC オペレーションがあったとします。

<temp xsi:type="xs:float">58</temp>

この場合、図 4-5 に示すように、引数名は temp 、タイプは Float に設定します。

[Req]:引数が必須かどうか。このオプションをイネーブルにすると、要求内に引数がなかった場合、メッセージはブロックされます。

このオプションを選択しなかったけれども、引数の検証は指定した場合、ACE XML Gateway は、引数のないメッセージを許可しますが、引数が存在するかどうかはチェックします。

[Type]:引数のタイプ。integer、float、XML などを指定します。

選択したタイプによっては、その他の検証オプションも表示される場合もあります。たとえば、XML 引数には XML スキーマを指定できます。コンテンツだけでなくタイプも検証するように選択することにより、引数を特定の値に制限できます。たとえば、integer の場合は、引数が 1000 より小さくなければならないなどと指定できます。

図 4-5 引数の検証

 

SOAP Document の場合:

a. 次の SOAP メッセージ検証オプションから選択します。

[Well-formed: require that the SOAP message is well-formed XML; reject malformed messages]:適格性のチェックにより、バックエンド サービスに到達するメッセージが有効であることを保証します。これは、特定のコンテンツ インジェクション攻撃を防ぐ助けにもなります。

[Content: require SOAP message validation with the specified XML schemas; reject invalid messages]:メッセージがスキーマに準拠していなかった場合、そのメッセージはブロックされ、イベント ログが記録されます。選択されているデフォルト スキーマ、Web Services Security (WSS) 1.0 および Web Services Utility (WSU) 1.0 と一緒にメッセージの検証に使用されるスキーマは、[Import additional XML schemas] テキスト フィールドに指定します。[Upload] をクリックし、ファイル システムまたはネットワーク上の場所からスキーマを選択することにより、XML スキーマを追加できます。

このオプションを選択すると、さらにスキーマで定義されていない SOAP ヘッダーを渡すかどうかを指定することができます。

SOAP ヘッダーがスキーマに準拠していない場合、そのヘッダーはバックエンド サーバに送信される要求から削除されます。

[Content (passive): validate the SOAP message with the specified XML schemas; allow invalid messages but log an event]:メッセージが(前のオプションで説明したとおりに指定した)スキーマに準拠していなかった場合、イベントはログに記録されますが、メッセージはバックエンド サーバに渡されます。

b. 本文のコンテンツについては、ACE XML Gateway に、指定したスキーマと照らし合わせて本文を検証させることができます。使用したいスキーマが [XML Schema] メニューに表示されない場合は、[Upload] をクリックし、ファイル システムまたはネットワーク上の場所から XSD をアップロードすることにより、スキーマを ACE XML Manager のリソースとして追加します。

c. スキーマを選択すると、そのスキーマで定義されている名前空間が [Namespace] メニューに表示されます。有効なメッセージの構造を定義するスキーマ内の要素の名前空間をリストから選択します。

スキーマが名前空間を使用していない場合は、リストに [<no namespace>] が表示されます。

d. [Element] メニューから要素を選択することにより、選択した名前空間内の 1 つまたは任意の要素にまで、さらに検証を絞り込むことができます。

HTTP(S) Get Arguments および HTTP(S) DELETE の場合:

a. [Add a New Row] をクリックし、引数仕様フォームで次の設定値を設定することにより、要求メッセージに対する引数要件を追加します。

[Name]:要求に現れる引数の名前。

[Req]:引数が必須かどうか。このオプションをイネーブルにすると、要求内に引数がなかった場合、メッセージはブロックされます。このオプションを選択しなかったけれども、引数の検証は指定した場合、ACE XML Gateway は、引数のないメッセージを許可しますが、引数が存在するかどうかはチェックします。

[Type]:引数のタイプ。integer、float、XML などを指定します。選択できるオプションはメニューに表示されます。

選択したタイプによっては、その他の検証オプションも表示される場合もあります。たとえば、XML 引数には XML スキーマを指定できます。コンテンツだけでなくタイプも検証するように選択することにより、引数を特定の値に制限できます。たとえば、integer の場合は、引数が 1000 より小さくなければならないなどと指定できます。

HTTP(S) POST arguments の場合:

a. [Add a New Row] をクリックし、引数仕様フォームで次の設定値を設定することにより、要求メッセージに対する引数要件を追加します。

[Name]:要求に現れる引数の名前。

[Req]:引数が必須かどうか。このオプションをイネーブルにすると、要求内に引数がなかった場合、メッセージはブロックされます。このオプションを選択しなかったけれども、引数の検証は指定した場合、ACE XML Gateway は、引数のないメッセージを許可しますが、引数が存在するかどうかはチェックします。

[Type]:引数のタイプ。integer、float、XML などを指定します。選択したタイプによっては、その他の検証オプションも表示される場合もあります。たとえば、XML 引数には XML スキーマを指定できます。コンテンツだけでなくタイプも検証するように選択することにより、引数を特定の値に制限できます。たとえば、integer の場合は、引数が 1000 より小さくなければならないなどと指定できます。

HTTP(S) POST body および HTTP(S) PUT の場合:

a. 次の要求メッセージ検証オプションから選択します。

[Treat the body content as raw bytes (opaque data) with no validation]:ペイロードに検証する必要のない生バイトが含まれている場合に、このオプションを選択します。

[Treat the body content as XML with no validation]:メッセージ コンテンツを XML として指定しますが、コンテンツ検証はスキップします。このオプションを選択すると、コンソールで、変換などのサービス用のその他の XML オプションが指定可能になります。

[Validate that the body is well-formed XML only, with no content validation]:ACE XML Gateway は本文が適正な形式の XML になっていることは保証しますが、XML スキーマに対する本文の検証は行いません。

[Validate the body as XML according to]:ACE XML Gateway がメッセージ本文の検証に使用する XML スキーマを指定します。XML スキーマを選択し、そのスキーマ内から、メッセージが準拠していなければならない特定の名前空間と要素を選択できます。

b. バックエンド サーバに送信される要求内に現れてほしい content-type ヘッダーを指定します。ユーザ要求からの値をそのまま渡すこともできれば、その他のコンテンツ タイプ値を text/xml text/html 、カスタム コンテンツ タイプのいずれかから選択することもできます。カスタム コンテンツ タイプは、[custom] オプションを選択すると表示されるフィールドで指定できます。

ステップ 11 [Continue] をクリックします。

[Step 5 of 5: Response Message Specification] ページが表示されます。このページでは、要求メッセージの要件を指定できます。

基本的に、応答を設定する設定値は、要求の設定値とよく似ています。ただし、若干の違いが存在します。次に、プロトコル タイプごとに応答メッセージと要求メッセージの間の相違点を挙げていきます。

SOAP RPC および SOAP Document

[SOAP Message Validation] メニューに追加のオプション [Must be empty: require that the message body is empty] があります。

このオプションは、バックエンド サーバからユーザにメッセージ本文コンテンツは一切送信されないようにします。使用するアプリケーションで応答にメッセージ本文を含める理由がない場合は、このオプションを選択すれば、メッセージ本文が含まれる可能性が確実になくなります。

HTTP GET Arguments HTTP POST Arguments 、および HTTP DELETE :

HTTP 要求は、ヘッダーで構成されるシンプルなメッセージですが、一方の応答は、複雑な本文コンテンツを含む場合もあり、XML ドキュメントやバイナリ データで構成される可能性もあります。このため、HTTP GET、HTTP POST、HTTP PUT、および HTTP DELETE の応答メッセージ仕様のページには、次の [Body Content Specification] オプションが用意されています。

[Treat the body content as raw bytes (opaque data) with no validation]:ACE XML Gateway でのメッセージ コンテンツの検証を抑止するには、このオプションを選択します。

[Treat the body content as XML with no validation]:本文コンテンツを XML で書式化されているように指定しますが、コンテンツの検証はスキップします。このオプションを選択すると、Web コンソールで、XSLT アプリケーションなどのサービス用のその他の XML オプションが指定可能になります。

[Validate that the body is well-formed XML only, with no content validation]:ACE XML Gateway は本文が適正な形式の XML になっていることは保証しますが、XML スキーマに対する本文の検証は行いません。

[Validate the body as XML according to]:メッセージ本文コンテンツの検証に使用する XML スキーマを指定するのに使用します。XML スキーマを選択し、そのスキーマ内から、メッセージが準拠していなければならない名前空間と要素を選択できます。

HTTP POST Body および HTTP PUT

応答仕様ページは、HTTP Content-Type ヘッダーの設定オプションが追加され、パススルーがデフォルトになっている点以外は、要求仕様ページと同じです。

ステップ 12 [Continue] をクリックします。

仮想サービスのプロパティ ページが表示されます。変更したい設定のタイプの見出しの横にある [Edit] ボタンをクリックすることにより、いつでも設定を変更できます。


 

デフォルトでは、仮想サービスはプロビジョニングされておらず、ユーザはまだ Gateway でサービスにアクセスすることができません。これをアクセス可能にするには、パブリック アクセスに設定することによりプロビジョニングするか、または権限付与グループに割り当てます。その後、ポリシーを導入すれば、サービスが ACE XML Gateway でアクセス可能になります。

マルチ オペレーション仮想サービスに関する作業

仮想サービスは、さまざまの異なる精度でバックエンド SOAP Document サービスを表すことができます。また、単一の SOAP サービス オペレーションにも複数のオペレーションにも対応できます。WSDL インポート時に、インポートされた WSDL の service 要素で定義されているすべてのオペレーションを含むマルチ オペレーション仮想サービスを生成できます(図 4-6 を参照してください)。

図 4-6 マルチ オペレーション仮想サービス

 

マルチ オペレーション サービスは、多数のオペレーションのための設定を行う単一ポイントを提供します(膨大になる場合もあるオペレーションのそれぞれに設定を実行しなくてもよくなります)。

マルチ オペレーション仮想サービスは、次のような条件下でサービスを表すのに使用できます。

基本仮想サービス ポリシー オブジェクト(独立したハンドラとサービス記述子ではなく)が、ポリシー内でのサービス定義に使用されます。

仮想サービスは、WSDL インポートにより作成されます。

プロトコルは SOAP Document です(SOAP RPC はサポートされていません)。

サポートされていれば、ACE XML Manager は、WSDL インポート時にデフォルトで、マルチ オペレーション仮想サービスを作成します。シングル オペレーション サービスが作成されるのは、そうするようにオプションを選択した場合だけです。

仮想サービスでの設定は、それに含まれるすべてのオペレーションに適用されます。最終的には、サービス内のオペレーションに対して特化した設定が必要な場合もあります。オペレーションを上書きすることによってその設定をカスタマイズできるように、仮想サービスからオペレーションを抽出できます。これにより、オペレーション固有の設定値の設定を行える独立した仮想サービスが作成されます。

図 4-7 上書きされたオペレーションを持つマルチ オペレーション仮想サービス

 

図 4-7 に、 order という名前のソース仮想サービスを示します。この WSDL には、3 つのオペレーションがあり、オペレーションの 2 つ submitPayment retrieveQuote が上書きされています。任意の時点で、この上書きを削除して、オペレーションをその元の仮想サービスに戻すことができます。


) マルチ オペレーション仮想サービスでインポートされた WSDL は、拡張仮想サービスに直接変換することはできません。


マルチ オペレーション仮想サービスの作成

マルチ オペレーション仮想サービスを作成するには、[Condense SOAP Document operations into one virtual service per WSDL "Service" element, if possible] というラベルの追加拡張オプションを WSDL インポート時にイネーブルにする必要があります。すでに説明したように、インポートしようとしている WSDL のサービス タイプ、SOAP Document によってサポートされている場合は、このオプションはデフォルトでイネーブルになっています。

このオプションをディセーブルにして、手動で、または WSDL インポートで作成された仮想サービスは、後から凝縮することはできません。既存の仮想サービスをマルチ オペレーション仮想サービスに変更する唯一の手段は、サービスの WSDL をもう一度インポートすることです。

仮想サービス ブラウザでは、マルチ オペレーション仮想サービスは、WSDL 内のサービス要素の名前でラベル付けされています。どの仮想サービスに対しても行えるように、サービスをクリックして、トラフィック処理やサービス オペレーションの検証を制御するための設定値を設定できます。

サービス オペレーションの上書き

マルチ オペレーション仮想サービスを作成した後、その仮想サービス内の 1 つのサービス オペレーションの設定を他のオペレーションからは切り離してカスタマイズする必要がある場合もあるでしょう。オペレーションの設定をカスタマイズするには、仮想サービス内でのその定義を上書きします。これにより、単一のオペレーションを持つ独立した仮想サービス オブジェクトが作成されます。

仮想サービスの上書きにより生成された仮想サービスには、作成された時点ではその親とまったく同じ設定が含まれています。その後、その設定は親の設定からは独立します。親仮想サービスで設定を変更しても、その変更は、生成された仮想サービスには影響しません。その逆も同じです。ただし、仮想サービスの系統は保持されるので、後からそのソース仮想サービス オブジェクトに復元することは可能です。

サービス オペレーションを上書きする手順は次のとおりです。


ステップ 1 仮想サービス ブラウザで、上書きするオペレーションが含まれているマルチ オペレーション仮想サービスの名前をクリックします。

ステップ 2 設定ページの [Operation] セクションで、[Manage] リンクをクリックします。

ステップ 3 独立した仮想サービスを作成する 1 つまたは複数のオペレーションの横のチェックボックスをチェックします。

ステップ 4 [Create Overrides] ボタンをクリックします。


 

1 つのオペレーションを選択していた場合は、新しい仮想サービスの設定ページに移動します。複数のオペレーションを選択していた場合は、[Manage Operations] ページの [Overridden Operations] テーブルにそれらのオペレーションがリストされます。上書きしたオペレーションの設定には、仮想サービス ブラウザからアクセスするか、または [Manage Operations] ページの [edit] リンクをクリックしてアクセスします。

上書きしたオペレーションの復元

上書きしたオペレーションは、いつでも元のマルチ オペレーション仮想サービスに戻すことができます。上書きしたサービス オペレーションを復元すると、そのオペレーション用にカスタマイズした設定はすべて失われます。

上書きしたサービス オペレーションを復元する手順は次のとおりです。


ステップ 1 仮想サービス ブラウザで、上書きしたオペレーションが元あったマルチ オペレーション仮想サービスの名前をクリックします。

ステップ 2 設定ページの [Operation] セクションで、[Manage] リンクをクリックします。

ステップ 3 復元するオペレーションの横にあるチェックボックスをチェックします。これは、上書きしたオペレーションのテーブル内にあります。

ステップ 4 [Restore Defaults] ボタンをクリックします。


 

これで、そのオペレーションが [Default Operations] テーブルに表示されます。これは、マルチ オペレーション仮想サービスの設定の対象が入ったテーブルです。

マルチ オペレーション仮想サービスに関するその他の作業

マルチ オペレーション仮想サービスに関して行えるその他の作業には、次のものがあります。

マルチ オペレーション仮想サービスの削除 :Web コンソールから仮想サービスを削除する方法は何通りかありますが、マルチ オペレーション仮想サービスについては、ほとんどの場合、その生成に使用した WSDL を [Imported WSDL] ページから削除するのが最もよい方法です。これにより、その WSDL から生成された仮想サービス、その仮想サービスを上書きすることにより作成された仮想サービス、およびその WSDL が削除されます。

オペレーションのイネーブル化/ディセーブル化 :マルチ オペレーション仮想サービスの [Manage Operations] ページで [Enable] ボタンまたは [Disable] ボタンを選択することにより、個々のオペレーションをディセーブル化したりイネーブル化したりできます。これは、単一オペレーション仮想サービスをイネーブル化したりディセーブル化したりするのと同じ効果を持ちます。ディセーブル化すると、そのオペレーションには Gateway を通じて到達できなくなります。

サービスのテスト :テスト ブラウザを使用すれば、仮想サービス内の個々のオペレーションをテストすることができますが、仮想サービス内の特定のオペレーションをテストするには、テスト ブラウザからオペレーションを選択する必要があります。

拡張への変換: マルチ オペレーション仮想サービスでインポートされた WSDL は、拡張仮想サービスに直接変換することはできません。

マルチ オペレーション仮想サービスを拡張に変換する手順は次のとおりです。


ステップ 1 オペレーションを上書きして、基本仮想サービスを作成します。

ステップ 2 基本仮想サービスを拡張に変換します。


 

次の手順

仮想サービス ウィザードを使用するか、または WSDL をインポートすることにより仮想サービスを作成すると、最低限の設定の施された仮想サービスが得られます。ほとんどの場合、これらの手順で作成された基本セットの設定パラメータに重ねて構築することになります。

サービスに追加することになると思われる設定のタイプには、次のものがあります。

カスタム ユーザ アクセス要件

バックエンド サービスへの認証

メッセージ コンテンツの XML 暗号化/複合または XML 署名検証/生成

これらの機能を設定する手順は、このマニュアルの以降の章で説明します。