このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索の URL を出力します。
このスクリプトでは、e-docs マニュアルに必要なバナーを出力します。
このスクリプトでは、e-docs マニュアルの検索に必要な Google 検索のパラメータを出力します。
AquaLogic Service Bus Console の使い方
プロキシ サービス
この節の内容は以下のとおりです。
プロキシ サービスの概要
この節の内容は以下のとおりです。
プロキシ サービスとは、WebLogic Server 上にローカルに実装されるサービスの AquaLogic Service Bus 定義です。プロキシ サービスは、WSDL、パイプライン、ポリシーの観点で定義できます。プロキシ サービスでセキュリティ証明書が必要な場合は、そのセキュリティ証明書とキーストア エントリとのマッピングを管理するプロキシ サービス プロバイダを AquaLogic Service Bus Console で作成できます。プロキシ サービス プロバイダのコンフィグレーション方法については、「プロキシ サービス プロバイダの追加 」を参照してください。プロキシ サービスのアクセス制御ポリシーをコンフィグレーションすることができます。詳細については、「アクセス制御ポリシーの表示と検索 」、「転送レベルのアクセス ポリシーの編集 」、「メッセージレベルのアクセス ポリシーの編集 」を参照してください。
プロキシ サービスは、メッセージ フローをコンフィグレーションすることで実装します。メッセージ フローには、開始ノード、パイプライン ペア ノード、ブランチ ノード、およびルート ノードを入れることができます。詳細については、「プロキシ サービスの概要 」および「メッセージ フローの表示と変更 」を参照してください。
以下の表は [プロジェクト エクスプローラ ] モジュールと [リソース ブラウザ ] モジュールでアクセスできるページをまとめたものです。各ページに関連するタスクとヘルプ トピックを確認できます。
表 16-1 [プロジェクト エクスプローラ] モジュールおよび [リソース ブラウザ] モジュールからアクセスするページ
プロキシ サービスのリストの表示。サービス名とアラートが表示される。
サービス タイプ
サービス タイプはそれぞれ同じパターンに従って作成されます。サービス タイプのコンフィグレーションは、共通の部分とサービス タイプ固有の部分で構成されます。
共通のコンフィグレーションは、以下のプロパティで構成されます。
表 16-2 サービス タイプのコンフィグレーション
サービス名 (プロジェクト名、パス名、およびローカル名)
サービスの説明 (省略可能)
サービス タイプ (読み込み専用)
このコンフィグレーションは、以下のもので構成される。
注意 :
サービス プロバイダが必要になるのは、クライアント証明書認証を必要とする HTTPS サービスに対してプロキシ サービスからメッセージをルーティングする場合、または一部のメッセージレベルのセキュリティ シナリオに限られる。
各プロキシ サービスに以下のパラメータをコンフィグレーションできる。
エンドポイント URI - 文字列。/proxy1
または jms://localhost:7001/QueueConnectionFactory/DestName
など (必須)。 JMS 送り先を複数のサーバにするには、次の URI 形式を使用する。jms://host1:port,host2:port/QueueConnectionFactory/DestName
要求から HTTP Authorization ヘッダ以外のすべてのヘッダを取得 。ブール型の値で、デフォルト値は [はい]。
ユーザ指定のヘッダ - ヘッダ名の文字列のリスト。[すべてのヘッダを取得] オプションで [いいえ] を選択した場合にのみ適用可能。HTTP Authorization ヘッダは、指定した場合でも取得されない。
選択する転送方式は、バインディング定義により必要とされる転送モード (要求/応答、一方向、または両方) をサポートする必要があり、それに従ってコンフィグレーションする。
両方のモードでメッセージを交換するサービスでは、バインディング レイヤをコンフィグレーションし、場合に応じて転送モードを選択できるようにする必要がある (要求/応答を 2 つの非同期呼び出しとして実装する、JMS などのすべての転送用)。サービスが具象型である場合、この選択は、バインディング定義の記述に従って自動的に行われる。サービスが具象型でない場合、バインディング レイヤをコンフィグレーションするには、
$outbound
変数でモードを設定する必要がある。
転送方式と WSDL、またはインタフェースに基づいて、転送モードが自動的に選択されるが、
$inbound
や
$outbound
で上書きできる。
各サービス タイプでは、以下のコンフィグレーションを定義する必要があります。
バインディング定義
実行時コンフィグレーション
実行時変数 ($operation
、$body
、$header
、$attachments
)
表 16-3 サービス タイプのコンフィグレーション
既存の WSDL リソースを基にして SOAP および XML サービスを構築できる。WSDL リソースは、HTTP 転送、HTTPS 転送、および JMS 転送を使用するプロキシ サービスに使用できる。この WSDL は、サービスの最終的な WSDL ドキュメントのベースとして使用される。
WSDL では、ポートが定義可能な場合と可能でない場合があるため、WSDL を基にしてプロキシ サービスを作成するときには、WSDL ポートまたは WSDL バインディングのいずれかのみを選択できる。WSDL ポートは、実際の転送アドレスを表す。ただし、実際の転送アドレスがプロキシ サービスに使用されるわけではない。URL は、サービスの転送コンフィグレーションで指定する。
AquaLogic Service Bus では、WSDL バインディングに基づいてプロキシ サービスを作成すると、そのプロキシ サービス用に生成された WSDL に新しいサービスとポートの定義が設定される。WSDL ポートと WSDL バインディングのどちらに基づいてプロキシ サービスを定義するかに関わらず、そのプロキシ サービス用として生成された WSDL で定義されるポートは 1 つだけである。テンプレート WSDL でポート X からサービスが生成される場合、生成される WSDL でもポート X が定義される。
ただし、HTTP(S) サービスに使用される URL は、サービスの転送コンフィグレーションで定義された URL であり、WSDL で定義された URL ではない。他の転送 (JMS のみ適用) については、生成される WSDL にサービスとポートは定義されない。
さらに、WSDL ポートに基づいてプロキシ サービスを作成する場合、生成される WSDL ではそのポート名が使用され、そのポートに関連付けられたすべての WS-Policy が保持される。バインディングはポートから決定され、ポート タイプはバインディングから決定される。
サービスがテンプレート WSDL のバインディング Y から生成される場合、生成される WSDL によって新しいサービスとポートが定義される (<service-name>QSService および <port-name>QSPort)。テンプレート WSDL で定義されたどのポートも、生成される WSDL には含まれない。
WSDL バインディング テンプレートに基づいてサービスを作成する場合は、その WSDL に該当のバインディングに関連付けられた複数のポートが存在する場合がある。各ポートは異なる URL を使用でき、異なる WS-Policy が付加されている。したがって、生成される WSDL は、そのバインディングを使用するが、そのバインディング用に WS-Policy のない人為的なポートを生成する。すべての WSDL ベース サービスでは、サービス定義の転送セクションで転送タイプと転送 URL を指定する。
注意 :
サービスの URL に ?WSDL を追加したものをブラウザのアドレス フィールドに入力することで、HTTP(S) ベースのプロキシ サービスの WSDL を取得できる。
既存の WSDL リソースを基にして SOAP および XML サービスを構築できる。WSDL リソースは、HTTP 転送、HTTPS 転送、および JMS 転送を使用するプロキシ サービスに使用できる。この WSDL は、最終的な WSDL ドキュメントのベースとして使用される。
WSDL では、ポートが定義可能な場合と可能でない場合があるため、WSDL を基にしてプロキシ サービスを作成するときには、WSDL ポートまたは WSDL バインディングのいずれかのみを選択できる。WSDL ポートは、実際の転送アドレスを表す。ただし、実際の転送アドレスがプロキシ サービスに使用されるわけではない。URL は、サービスの転送コンフィグレーションで指定する。
サービスの転送コンフィグレーションで、サービスの転送プロトコルを互換性のある別のプロトコルに変更できる。
サービスとポートは、HTTP と HTTPS のために生成された WSDL にのみ存在する (JMS には存在しない。他の転送はサポートされない)。SOAP サービスの場合は、既存の
<wsdl:service>
定義があればそれが削除され、単一の
<wsdl:port>
を持つ新しい定義が作成される。
XML サービスの場合、使用可能な標準の WSDL バインディング定義は、HTTP 用に定義されたものだけである。これは、JMS のために生成された WSDL でも使用される。
WSDL が SOAP ベースの場合、変数は AnySOAP に似ているが、
$operation
が操作選択アルゴリズム (「
プロキシ サービスを追加するには - 操作選択コンフィグレーション 」を参照) に基づいて初期化される点が異なる。同様に、WSDL が XML ベースの場合、変数は AnyXML に似ているが、
$operation
が操作選択アルゴリズムに基づいて初期化される点が異なる。
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義とは無関係に、サービスで SOAP メッセージを受信するか送信するかのみである。したがって、このタイプのバインディング コンフィグレーションは空になる。
また、バインディング コンフィグレーションが存在しないため、このタイプではメッセージのコンテンツ タイプとの組み合わせで、メッセージに添付ファイルがあるかどうかを十分判別できる。
定義上、どのサービス (SOAP または XML) も WSDL 定義を持たない。これらのサービスの WSDL ドキュメントを要求することはできない。
$body
変数および
$header
変数に、受信 SOAP メッセージの
<soap:Body>
および
<soap:Header>
がそれぞれ格納される。
SOAP メッセージに添付ファイルがあれば、
$attachments
変数に格納される。
ポート タイプを定義しないため、
$operation
変数はこのサービス タイプには使用されない。
メッセージ コンテキスト変数の詳細については、「
メッセージ関連の変数 」および「
送信するメッセージの作成 」を参照。
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義とは無関係に、サービスで XML メッセージを受信するか送信するかのみである。したがって、このタイプのバインディング コンフィグレーションは空になる。
また、バインディング コンフィグレーションが存在しないため、このタイプではメッセージのコンテンツ タイプとの組み合わせで、メッセージに添付ファイルがあるかどうかを十分判別できる。
定義上、どのサービス (SOAP または XML) も WSDL 定義を持たない。これらのサービスの WSDL ドキュメントを要求することはできない。
$body
変数内の
<soap:Body>
要素内に受信 XML メッセージがラップされて格納される。
メッセージに添付ファイルがあれば、
$attachments
変数に格納される。
$header
変数はこのサービス タイプには使用されず、デフォルト値に設定される。
ポート タイプを定義しないため、
$operation
変数はこのサービス タイプには使用されない。
メッセージ コンテキスト変数の詳細については、「
メッセージ関連の変数 」および「
送信するメッセージの作成 」を参照。
バインディング定義 : メッセージング サービス用のバインディング定義は、交換されるメッセージのコンテンツ タイプのコンフィグレーションで構成される。応答のコンテンツ タイプは、要求のコンテンツ タイプと同じである必要はない。そのため、応答は個別にコンフィグレーションされ (たとえば、サービスで MFL メッセージを受信し、XML の受信確認を返すことも可能)、[なし] に設定することも可能。
定義上、メッセージベースのサービスには WSDL 定義は存在しない。これらのサービスの WSDL ドキュメントを要求することはできない。
要求 (および応答) のコンテンツ タイプは、以下の 4 つから選択できる。
このサービス タイプはメッセージ ベースである。Web サービスには複数の「操作」という概念はない。したがって、
$operation
変数は空のままになる。
$body
変数内の
<soap:Body>
要素内に受信メッセージがラップされて格納される。
$header
変数はこのサービス タイプでは使用されず、デフォルト値に設定される。
メッセージに添付ファイルがあれば、
$attachments
変数に格納される。
メッセージ コンテキスト変数の詳細については、「
メッセージ関連の変数 」および「
送信するメッセージの作成 」を参照。
プロキシ サービスのタイプと転送方式
AquaLogic Service Bus では、以下のプロキシ サービスのタイプと転送方式をサポートしています。
表 16-4 AquaLogic Service Bus でサポートされるプロキシ サービスのタイプと転送方式
メッセージ タイプ (バイナリ、テキスト、MFL、XML)
セキュリティ関連の検証
アクティブな媒介であるプロキシ サービスへの変更が含まれるセッションをアクティブ化する場合、AquaLogic Service Bus では、その変更が検証され、プロキシ サービスの静的なエンドポイントに必要なすべての資格が作成されているかが確認されます。たとえば、Web サービスを使用するプロキシ サービスを静的なエンドポイントとしてコンフィグレーションしており、その Web サービスにデジタル署名が必要な場合、AquaLogic Service Bus では、対象のプロキシ サービスにプロキシ サービス プロバイダを関連付けているか、およびプロキシ サービス プロバイダにデジタル署名で使用できるキーペア バインディングが含まれているかを検証します。
プロキシ サービス プロバイダに対する変更がセッションに含まれる場合は、そのプロキシ サービス プロバイダを使用するすべてのプロキシ サービスに対する変更が検証されます。たとえば、暗号化用のキーペア バインディングをプロキシ サービス プロバイダから削除して、暗号化が必要なエンドポイントを含むプロキシ サービスが、変更されたプロキシ サービス プロバイダを使用している場合は、そのプロキシ サービスが変更されていなくても、プロキシ サービスに対する検証エラーが報告されます。
以下の条件により、セキュリティ関連の検証が実行されるタイミングと、検証中に行われるアクションが決定されます。
プロキシ サービスが静的なルートと処理を指定する場合は、静的なルートおよび処理に必要な資格が決定される。必要な資格がプロキシ サービスに含まれていない場合は、その資格が追加されるまで、対象のセッションはコミットされません。
プロキシ サービスが静的なルートを指定しており、処理が着信要求からパススルーされる場合は、静的なルートおよび各ルートの処理に必要な資格が決定される。必要な資格がプロキシ サービスに含まれていない場合は、検証の警告が表示されますが、セッションをコミットすることはできます。
プロキシ サービスが動的なルートと処理を指定する場合は、セキュリティ要件を検証できないため、実行時エラーが発生するおそれがある。動的ルーティングの詳細については、AquaLogic Service Bus のユーザーズ ガイドの「AquaLogic Service Bus でのメッセージ フローの作成 」にある「動的ルーティング」を参照してください。
関連トピック
ビジネス サービスの概要
プロキシ サービスの追加
[プロキシ サービスの編集 - 全般的なコンフィグレーション ] ページでは、プロキシ サービスを追加できます。
プロキシ サービスとは、WebLogic Server 上にローカルに実装されるサービスの AquaLogic Service Bus 定義です。プロキシ サービスは、WSDL、パイプライン、ポリシーの観点で定義します。詳細については、「プロキシ サービスの概要 」を参照してください。
プロキシ サービスを追加するには、まずサービスの全般的な情報をコンフィグレーションしたうえで、そのサービスについて、全般的な転送情報とプロトコルに依存する転送情報をコンフィグレーションし、さらに、サービスに操作が含まれる場合は、サービスの操作選択アルゴリズムをコンフィグレーションする必要があります。これがメッセージング サービスである場合は、メッセージ タイプもコンフィグレーションする必要があります。コンフィグレーションはプロキシ サービスを作成する前に確認できます。
この手順には以下のタスクが含まれます。
プロキシ サービスを追加するには - 全般的なコンフィグレーション
まだセッションを作成していない場合は、左側のナビゲーション ペインで、[Change Center ] の下にある [作成 ] をクリックして、現在のコンフィグレーションに変更を加えるための新しいセッションを作成します。詳細については、「Change Center の使用 」を参照してください。
左側のナビゲーション ペインで、[プロジェクト エクスプローラ ] を選択します。[プロジェクト ビュー ] ページが表示されます。
プロキシ サービスの追加先となるプロジェクトを選択します。プロキシ サービスは直接プロジェクトに追加することも、選択したフォルダに対して追加することもできます。
注意 :
フォルダを選択するには、フォルダ名をクリックします。[フォルダ ビュー ] ページが表示されます。
[プロジェクト ビュー ] ページまたは [フォルダ ビュー ] ページの [リソースの作成 ] フィールドで、[サービス ] の下にある [プロキシ サービス ] を選択します。[プロキシ サービスの作成 - 全般的なコンフィグレーション ] ページが表示されます。
[サービス名 ] フィールドにユニークなプロキシ サービス名を入力します。
[説明 ] フィールドに、プロキシ サービスの説明を入力します。
[サービスの種類 ] フィールドで、以下のいずれか 1 つを実行します。
注意 :
サービス タイプでは、そのサービスで交換されるメッセージのタイプとパッケージ化が決定されます。このフィールドは必須です。
表 16-5 [サービスの種類] フィールド
[WSDL ポート ] を選択し、[参照 ] をクリックする。[WSDL の選択 ] ページが表示される。
リストで WSDL リソースをクリックして選択すると、[WSDL 定義の選択 ] ページが開き、WSDL のポートとバインディング情報が表示される。
[WSDL 定義の選択 ] で、ポートまたはバインディング定義を選択する。
注意 : ポート オプションとバインディング オプションは互いに排他的な関係である。いずれか一方しか選択できない。
[送信 ] をクリックしてダイアログ ボックスを閉じ、[全般的なコンフィグレーション ] ページに戻る。
注意 :
操作に [SOAP 本体の種類] を使用する場合は、WSDL に同じ入力メッセージで 2 つの操作がないことを確認する。[SOAP 本体の種類] 操作は、入力メッセージを調べてユニークに識別することはできない。
[
メッセージング サービス ] を選択して、あるデータ タイプのメッセージを受信し、別のデータ タイプのメッセージで応答できるサービスを作成する。このようなメッセージ交換は、要求/応答または一方向にすることができる。Web サービスとは異なり、要求と応答のコンテンツ タイプは同じでなくてもかまわない。
注意 :
HTTP GET に対応しているサービス タイプは、任意の XML サービスとメッセージング サービスのみ。
明示的に定義された具象インタフェースを持たない SOAP サービスの作成
明示的に定義された具象インタフェースを持たない SOAP サービスを作成するには、[
任意の SOAP サービス ] を選択する。
明示的に定義された具象インタフェースを持たない XML サービスの作成
明示的に定義された具象インタフェースを持たない XML サービスを作成するには、[
任意の XML サービス ] を選択する。
注意 :
HTTP GET に対応しているサービス タイプは、任意の XML サービスとメッセージング サービスのみ。
既存のビジネス サービスからのプロキシ サービスの作成
[既存のサービスから作成 ] の下にある [ビジネス サービス ] を選択する。
[参照 ] をクリックする。[サービス ブラウザ ] が表示される。
[サービス ブラウザ ] で、ビジネス サービスを選択する。
[送信 ] をクリックしてダイアログ ボックスを閉じ、[全般的なコンフィグレーション ] ページに戻る。
これにより、選択したビジネス サービスにルーティングするルート ノードを備えたプロキシ サービスを作成できる。ビジネス サービスの詳細については、「
ビジネス サービスの概要 」を参照。
注意 :
転送タイプのビジネス サービスからプロキシ サービスを作成することはできない。
既存のプロキシ サービスからのプロキシ サービスの作成
[既存のサービスから作成 ] の下にある [プロキシ サービス ] を選択する。
[参照 ] をクリックする。[サービス ブラウザ ] が表示される。
[サービス ブラウザ ] でプロキシ サービスを選択する。
[送信 ] をクリックしてダイアログ ボックスを閉じ、[全般的なコンフィグレーション ] ページに戻る。
これにより、選択したプロキシ サービスのクローンを新しいプロキシ サービスとして作成できる。
AquaLogic Service Bus では複数のサービスに同じ URI を設定できないため、クローン サービスの URI を変更する必要がある。
[プロキシ サービス プロバイダ ] フィールドで、プロキシ サービス プロバイダの名前を選択します。
[参照 ] をクリックします。プロキシ サービス プロバイダ ブラウザ が表示されます。
プロキシ サービス プロバイダ ブラウザ で、プロキシ サービス プロバイダを選択します。
[送信 ] をクリックしてダイアログ ボックスを閉じ、[全般的なコンフィグレーション ] ページに戻ります。
プロキシ サービス プロバイダは特定の場合だけに必要とされます。たとえば、双方向発信 TLS/SSL でクライアント証明書認証を必要とする HTTPS サービスに対してプロキシ サービスからメッセージをルーティングする場合や、一部の Web サービス セキュリティのシナリオ (プロキシ サービスでメッセージの暗号化を必要とする場合など) に限定されます。プロキシ サービス プロバイダの詳細については、「プロキシ サービス プロバイダの概要 」を参照してください。プロキシ サービス プロバイダの作成方法については、「プロキシ サービス プロバイダの追加 」を参照してください。
注意 :
Web サービス セキュリティ対応のプロキシ サービスを追加するには、WS-Policy が付加された WSDL (ポートまたはバインディング) からプロキシ サービスを作成する必要があります。
[次へ ] をクリックします。
[サービスの種類 ] フィールドで [メッセージング サービス ] を選択した場合は、[プロキシ サービスの編集 - メッセージの種類のコンフィグレーション ] ページが表示されます。「プロキシ サービスを追加するには - メッセージ タイプのコンフィグレーション 」に進みます。
その他のサービス タイプを選択した場合は、[プロキシ サービスの編集 - 転送コンフィグレーション ] ページが表示されます。「プロキシ サービスを追加するには - 転送コンフィグレーション 」に進みます。
プロキシ サービスを追加するには - メッセージ タイプのコンフィグレーション
[サービスの種類 ] フィールドで [メッセージング サービス ] を選択した場合は、[プロキシ サービスの編集 - 全般的なコンフィグレーション ] ページで [次へ ] をクリックすると、[プロキシ サービスの編集 - メッセージの種類のコンフィグレーション ] ページが表示されます。
メッセージング サービス用のバインディング定義は、交換されるメッセージのコンテンツ タイプのコンフィグレーションで構成されています。応答のコンテンツ タイプは、要求のコンテンツ タイプと同じである必要はありません。そのため、応答は個別にコンフィグレーションされます (たとえば、サービスで MFL メッセージを受信し、XML の受信確認を返すことも可能です)。
要求メッセージと応答メッセージのメッセージ タイプを選択します。
[要求メッセージの種類 ] フィールドで、要求メッセージのメッセージ タイプを選択します。
表 16-6 [要求メッセージの種類] フィールド
メッセージのコンテンツ タイプが不明か、重要でない場合は、[
バイナリ ] を選択する。
メッセージをテキストに限定できる場合は、[
テキスト ] を選択する。
メッセージが MFL 定義に準拠したバイナリ ドキュメントの場合は、[
MFL ] を選択する。MFL ファイルは、1 つのみコンフィグレーションできる。
注意 :
MFL の場合は、[参照 ] をクリックし、MFL ファイル ブラウザ で MFL を選択してから、[送信 ] をクリックできる。
注意 :
複数の MFL ファイルをサポートするには、コンテンツをバイナリまたはテキストとして定義し、メッセージ フローの MFL アクションを使用して XML に変換する。
メッセージが XML ドキュメントの場合は、[
XML ] を選択する。一部の型情報を指定するために、交換される XML ドキュメントの XML スキーマ型を宣言できる。
[応答メッセージの種類 ] フィールドで、応答メッセージのメッセージ タイプを選択します。
表 16-7 [応答メッセージの種類] フィールド
メッセージのコンテンツ タイプが不明か、重要でない場合は、[
バイナリ ] を選択する。
メッセージをテキストに限定できる場合は、[
テキスト ] を選択する。
メッセージが MFL 定義に準拠したバイナリ ドキュメントの場合は、[
MFL ] を選択する。MFL ファイルは、1 つのみコンフィグレーションできる。
注意 :
MFL の場合は、[参照 ] をクリックし、MFL ファイル ブラウザ で MFL を選択してから、[送信 ] をクリックできる。
メッセージが XML ドキュメントの場合は、[
XML ] を選択する。一部の型情報を指定するために、交換される XML ドキュメントの XML スキーマ型を宣言できる。
[次へ ] をクリックします。
[転送コンフィグレーション ] ページが表示されます。「プロキシ サービスを追加するには - 転送コンフィグレーション 」に進みます。
プロキシ サービスを追加するには - 転送コンフィグレーション
[プロキシ サービスの編集 - 全般的なコンフィグレーション ] ページで [次へ ] をクリックすると、[転送コンフィグレーション ] ページが表示されます。[プロキシ サービスの編集 - メッセージの種類のコンフィグレーション ] ページで [次へ ] をクリックすると、メッセージング サービスに関する内容が表示されます。
このページでは、プロキシ サービスの転送情報をコンフィグレーションできます。AquaLogic Service Bus でサポートしているサービス タイプと転送方式については、「プロキシ サービスのタイプと転送方式 」を参照してください。
注意 :
着信転送レベルのセキュリティは、クライアント アプリケーションと AquaLogic Service Bus プロキシ サービスに適用されます。発信転送レベルのセキュリティは、AquaLogic Service Bus のプロキシ サービスとビジネス サービスの間の接続に適用されます。転送レベルのセキュリティの詳細については、AquaLogic Service Bus のセキュリティ ガイドの「転送レベルのセキュリティのコンフィグレーション 」を参照してください。
[プロトコル ] フィールドで、以下の転送プロトコルを 1 つ選択します。
電子メール
ファイル
FTP
HTTP
HTTPS
JMS
Tuxedo
ローカル
[エンドポイント URI ] フィールドに、[プロトコル ] フィールドで選択した転送プロトコルに基づく形式のエンドポイント URI を入力してから、[追加 ] をクリックします。
表 16-8 [エンドポイント URI ] フィールド
mailfrom:mail-server-hostname:mail-server-port
file:///drivename:/somename
ftp://hostname:port/directory
jms://host:port/factoryJndiName/destJndiName
JMS 送り先として複数のサーバを指定するには、次の URI 形式を使用する。
jms://host1:port,host2:port/QueueConnectionFactory/DestName
プロキシ サービスを作成するとき、エンドポイントのサーバが使用可能でない場合でも、JMS エンドポイントの URI をコンフィグレーションできる。ただし、JMS の場合は、セッションをアクティブ化する時点でエンドポイントが使用可能でなければならない。詳細については、「
セッションのアクティブ化には JMS エンドポイントの URI が使用可能であることが必要 」を参照。
URI
exportname
はリモート Tuxedo ドメインが Tuxedo サービスとして識別する WTC Export に一致する。
複数の URI が指定されている場合、エンドポイントにはユニークなリソース名を付ける必要がある。リモート名が指定されていない場合は、その値がリソース名の値になる。リモート名が入力されていない、またはリモート名およびリソース名が同じである場合は、1 つの URI のみを使用できる。この場合、リソース名とリモート名は同じ値。これにより、既に定義された WTC インポートを使用しているユーザは、WTC ロードバランシングおよびフェイルオーバを使用できるようになる。
注意 :
同一の URI を 2 つコンフィグレーションすると、そのサービス名がすでに存在していることを通知するエラーが表示される。
[すべてのヘッダを取得 ] フィールドで、Transport からのすべてのヘッダを取り出す場合は [はい ] を、定義に該当するヘッダを取り出す場合は [いいえ ] を選択します。[いいえ ] を選択した場合は、[ヘッダ ] フィールドに一連のヘッダを入力してから、[追加 ] をクリックします。この手順は、ローカル転送には該当しません。
注意 :
AquaLogic Service Bus は、要求からパイプラインに HTTP Authorization ヘッダを渡しません。要求からパイプラインに HTTP Authorization ヘッダを渡すと、セキュリティの脆弱性が生じ、ユーザ名と暗号化されていないパスワードをログ ファイルに書き込むログ アクションを誤って作成するおそれがあります。パイプラインに HTTP Authorization ヘッダが必要なデザイン パターンの場合、以下の操作を行います。
注意 :
a. AquaLogic Service Bus の起動コマンドで、システム プロパティ com.bea.wli.sb.transports.http.GetHttpAuthorizationHeaderAllowed
を true に設定します。
注意 :
b. AquaLogic Service Bus Console の [転送コンフィグレーション] ページで、[すべてのヘッダを取得 ] または [ユーザ指定のヘッダ ] を選択し、認可を指定します。
注意 :
c. AquaLogic Service Bus を再起動します。
注意 :
AquaLogic Service Bus が Authorization ヘッダをパイプラインに渡します。
[次へ ] をクリックします。
新しい [転送コンフィグレーション ] ページが表示されます。このページでは、プロキシ サービスのプロトコルに依存する転送情報をコンフィグレーションできます。「プロキシ サービスを追加するには - プロトコル依存の転送コンフィグレーション 」に進みます。
プロキシ サービスを追加するには - プロトコル依存の転送コンフィグレーション
[プロキシ サービスの編集 - 転送コンフィグレーション ] ページで [次へ ] をクリックすると、[[プロトコル] 転送コンフィグレーション ] ページが表示されます。このページでは、プロキシ サービスについて、[プロトコル ] フィールドで選択した転送プロトコルに基づき追加的な転送情報をコンフィグレーションできます。この手順は、ローカル転送には不要です。
[プロトコル ] フィールドで設定した転送プロトコルに基づき、以下のいずれか 1 つを実行します。
表 16-9 [プロトコル] フィールド
[基本認証が必要 ] チェックボックスを選択して、このサービスにアクセスするために基本認証を必須とするか、このフィールドを空白のままにして基本認証を不要とする。基本認証では、WebLogic Server でユーザ名とパスワードを使用し、セキュリティ レルム (Lightweight Directory Access Protocol (LDAP) ディレクトリ サービスや Windows Active Directory など) でコンフィグレーションされた認証プロバイダに対してクライアントの認証が行われる。クライアントは、HTTP 要求ヘッダでユーザ名とパスワードを送信する必要がある。
注意 : HTTP での基本認証は、パスワードがクリア テキストで送信されるため推奨されない。HTTPS では暗号化されたチャネルが提供されるため、パスワードは HTTPS で送信するのが安全。
警告 : デフォルトでは、すべてのユーザ (認可ユーザおよび匿名ユーザ) がプロキシ サービスにアクセス可能である。プロキシ サービスにアクセスできるユーザを制限するには、転送レベルの認可ポリシーを作成する必要がある。「転送レベルのアクセス ポリシーの編集 」を参照。
[ディスパッチ ポリシー ] フィールドで、このエンドポイントのディスパッチ ポリシーを選択する。デフォルトのディスパッチ ポリシーを使用するには、空白にする。
ディスパッチ ポリシーは、サービスのエンドポイントに使用する WLS 9.0 ワーク マネージャのインスタンスを参照する。たとえば、プロキシ サービスが JMS 転送プロトコルに対応している場合、サービスのエンドポイントは、そのディスパッチ ポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。
[要求エンコーディング ] フィールドで、以下を実行する。
HTTP 着信転送の場合、クライアント要求で Content-Type ヘッダの文字セット エンコーディング パラメータが指定されていないときは、このフィールドに文字セット エンコーディング パラメータを入力する。値を入力しない場合は、このフィールドにデフォルトの [iso-8859-1
] が設定される。
HTTP 発信転送の場合、要求エンコーディングをコンフィグレーションしていないときは、AquaLogic Service Bus ランタイムがビジネス サービスに要求を行う際に最適なエンコーディングが決定される。パススルー以外のシナリオでは、実行時のデフォルトの文字エンコーディングは utf-8
となる。ただし、パススルーのシナリオでは、ランタイムは発信応答で受信したエンコーディングのパススルーを行う。
[応答エンコーディング ] フィールドで、以下を実行する。
HTTP 着信転送の場合は、応答エンコーディングを入力する必要はない。バインディング レイヤがクライアントに応答を送り返すときに、最適なエンコーディングが決定される。パススルー以外のシナリオでは、実行時のデフォルトの文字セット エンコーディングは utf-8
となる。ただし、パススルーのシナリオの場合、ランタイムは発信応答で受信したエンコーディングのパススルーを行う。
HTTP 発信転送の場合、バック エンド サービス応答に Content-Type ヘッダの文字セット エンコーディング パラメータが指定されていないときは、このフィールドに文字セット エンコーディング パラメータを入力する。値を入力しない場合は、このフィールドにデフォルトの [iso-8859-1
] が設定される。
[クライアント認証 ] フィールドで、クライアント認証方式として [なし ]、[基本 ]、または [クライアント証明書 ] を選択する。
警告 : デフォルトでは、すべてのユーザ (認可ユーザおよび匿名ユーザ) がプロキシ サービスにアクセス可能である。プロキシ サービスにアクセスできるユーザを制限するには、転送レベルの認可ポリシーを作成する必要がある。「転送レベルのアクセス ポリシーの編集 」を参照。
[ディスパッチ ポリシー ] フィールドで、このエンドポイントのディスパッチ ポリシーを選択する。デフォルトのディスパッチ ポリシーを使用するには、空白にする。
ディスパッチ ポリシーは、サービスのエンドポイントに使用する WLS 9.0 ワーク マネージャのインスタンスを参照する。たとえば、プロキシ サービスが JMS 転送プロトコルに対応している場合、サービスのエンドポイントは、そのディスパッチ ポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。
[要求エンコーディング ] フィールドで、HTTPS 転送における要求の文字セット エンコーディングとして、デフォルトの iso-8859-1
を受け入れるか、別の文字セット エンコーディングを入力する。
[応答エンコーディング ] フィールドで、HTTPS 転送における応答の文字セット エンコーディングとして、デフォルトの iso-8859-1
を受け入れるか、別の文字セット エンコーディングを入力する。
[送り先の種類 ] フィールドで [キュー ] または [トピック ] を選択する。
[送り先の種類 ] フィールドで [キュー ] を選択した場合は、必要に応じて [応答が必要 ] を選択する。このオプションにより、メッセージの送信後に応答を受け取るか受け取らないかが決まる。このチェックボックスを選択しない場合は、手順 6 に進む。 チェックボックスを選択する場合は、次の手順 3 に進む。
メッセージ送信後に応答を受け取る場合、[応答相関パターン ] を選択する必要がある。WebLogic Server 9.2 で JAX-RPC サービスを実行している場合、JMSMessageID を選択する。その他のサービスを実行している場合は、JMSCorrelationID を選択する。
手順 3 で JMSCorrelationID を選択した場合、[応答 URI ] フィールドに、jms://host:port/factoryJndiName/destJndiName
という形式で応答 URI を入力する。[応答が必要 ] を選択した場合は、このフィールドは必須。 複数のサーバを送り先にするには、次の URI 形式を使用する。jms://host1:port,host2:port/QueueConnectionFactory/DestName
手順 3 で JMSMessageID を選択した場合、[応答接続ファクトリ ] フィールドに応答接続ファクトリの URI を入力する。接続ファクトリを指定しない場合、要求の接続ファクトリが応答で使用される。
[応答メッセージの種類 ] フィールドで、[バイト ] または [テキスト ] を選択する ([応答が必要 ] フィールドを選択した場合)。
[要求エンコーディング ] フィールドで、JMS 転送における要求の文字セット エンコーディングとして、デフォルトの utf-8
を受け入れるか、別の文字セット エンコーディングを入力する。
[応答エンコーディング ] フィールドで、JMS 転送における応答の文字セット エンコーディングとして、デフォルトの utf-8
を受け入れるか、別の文字セット エンコーディングを入力する。
[クライアント応答のタイムアウト ] フィールドに、接続を切断するまでの応答の待ち時間を秒単位で入力する。このフィールドの値は、クライアントが同一ドメインの別のプロキシ サービスである場合にのみ適用される。
[ディスパッチ ポリシー ] フィールドで、このエンドポイントのディスパッチ ポリシーを選択する。[default] は、デフォルトのディスパッチ ポリシーを示す。
ディスパッチ ポリシーは、要求を処理するためにサービスのエンドポイントに使用する WLS 9.0 ワーク マネージャのインスタンスを参照する。たとえば、プロキシ サービスが JMS 転送プロトコルに対応している場合、プロキシ サービスのエンドポイントは、そのディスパッチ ポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。
[詳細設定 ] をクリックして追加のフィールドを表示する。
要求を TSL/SSL 接続で行う場合は、[SSL を使用 ] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。TLS/SSL (セキュア ソケット レイヤ) では、ネットワークで接続される 2 つのアプリケーションが互いの ID を認証し、アプリケーション間で交換されるデータを暗号化できるようにすることによって、安全な接続が可能になる。認証を使用すると、サーバ (および必要に応じてクライアント) はネットワーク接続の相手側アプリケーションの ID を検証できる。また、送り先の JNDI エントリに対してアクセス制御が設定されていることにより、管理者から個々の JMS 送り先 (キューまたはトピック) へのアクセスが制限されている場合、JNDI ツリー内でのルックアップ時に、ビジネス サービスでユーザ名とパスワードを使用して認証を行う必要がある。
[メッセージ セレクタ ] フィールドにメッセージ セレクタ式を入力する。式に一致するプロパティを持つメッセージのみが処理される。
サブスクリプションが恒久である場合は [恒久サブスクリプション ] チェックボックスを選択する。サブスクリプションが恒久でない場合は、このチェックボックスにチェックを入れない。
[再試行回数 ] フィールドに、メッセージがエラー送り先に移されるまでに許可される配信の再試行回数を入力する。このフィールドは、WebLogic Server JMS 送り先にのみ適用される。
[再試行間隔 ] フィールドに、ロールバックまたは復元されたメッセージが再配信されるまでの時間をミリ秒単位で入力する。このフィールドは、WebLogic Server JMS 送り先にのみ適用される。
[エラー送り先 ] フィールドに、再配信制限に達したメッセージの送り先の名前を入力する。このフィールドは、WebLogic Server JMS 送り先にのみ適用される。
[有効期限ポリシー ] フィールドで、有効期限の経過したメッセージが送り先で検出されたときに使用する有効期限ポリシーを選択する。
注意 : このフィールドは、WLS JMS 送り先にのみ適用される。
[JMS サービス アカウント ] フィールドで、JMS サーバによる JMS リソース管理に使用するサービス アカウントを選択する。サービス アカウントは、ユーザ ID とそれに関連付けられたパスワードのエリアス リソースである。サービス アカウントの詳細については、「サービス アカウントの概要 」を参照。
[サービス アカウント ] フィールドにサービス アカウントを入力する。[参照 ] をクリックし、サービス アカウントを参照して選択できる。このフィールドは必須。
[ポーリング間隔 ] フィールドにポーリング間隔を秒数で入力する。このフィールドは必須。
[電子メール プロトコル ] フィールドで、電子メール アカウントのサーバ タイプとして [pop3 ] または [imap ] を選択する。このフィールドは必須。
[読み込み制限 ] フィールドに、ポーリング スイープあたりの読み込みメッセージ最大数を指定する。無制限にするには「0
」と入力する。このフィールドは必須。
アーカイブ ディレクトリにファイルをステージングして、それをヘッダに参照として渡す場合は、[参照として渡す ] フィールドを選択する。それ以外の場合は、このフィールドを空白のままにする。
[読み込み後のアクション ] フィールドで、メッセージ読み込み後の動作を選択する。このフィールドは必須。
[アーカイブ ] - メッセージがアーカイブ化される。
[削除 ] - メッセージが削除される。
[移動 ] - メッセージが移動される。[移動] は、IMAP プロトコルでのみ使用可能。
[添付ファイル ] フィールドで添付ファイルの処理方法を選択する。
[アーカイブ ] - 添付ファイルがアーカイブ ディレクトリに保存される。
[無視 ] - 添付ファイルが無視される。
このフィールドは必須。
[読み込み後のアクション ] フィールドで [移動 ] を選択した場合は、[IMAP 移動先フォルダ ] フィールドにメッセージの移動先フォルダを入力する。
[ダウンロード ディレクトリ ] フィールドに、電子メールのダウンロード先となる一時保存先を入力する。このフィールドは必須。
[読み込み後のアクション ] フィールドで [アーカイブ ] を選択した場合は、[アーカイブ ディレクトリ ] フィールドにアーカイブ保存先のパスを入力する。[アーカイブ ディレクトリ ] フィールドは、[参照として渡す ] フィールドを選択した場合も必須。
[エラー ディレクトリ ] フィールドに、問題が生じたときにメッセージと添付ファイルを書き込むファイル システム ディレクトリへのパスを入力する。このフィールドは必須。
[要求エンコーディング ] フィールドで、電子メール転送における要求の文字セット エンコーディングとして、デフォルトの iso-8859-1
を受け入れるか、別の文字セット エンコーディングを入力する。
[ファイル マスク ] フィールドに、選択されるファイルの正規表現を入力する。デフォルト値は *.* 。このフィールドは必須。
[ポーリング間隔 ] フィールドにポーリング間隔を秒数で入力する。デフォルト値は 60 。このフィールドは必須。
[読み込み制限 ] フィールドに、ポーリング スイープあたりの読み込みメッセージ最大数を指定する。無制限にするには「0
」と入力する。デフォルト値は 10 。このフィールドは必須。
イベントが受信順に配信されるように指定する場合は、[到着順にソート ] チェックボックスを選択し、それ以外の場合は空白のままにする。
クラスタ環境で実行されるプロキシ サービスに対して [到着順にソート ] オプションを選択すると、メッセージは常に同じサーバに送信される。つまり、このオプションを選択した場合、サーバ全体のロード バランシングは無視される。
すべてのディレクトリを再帰的にスキャンする場合は、[サブディレクトリのスキャン ] チェックボックスを選択し、それ以外の場合はこのフィールドを空白のままにする。
アーカイブ ディレクトリにファイルをステージングして、それをヘッダに参照として渡す場合は、[参照として渡す ] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。
[読み込み後のアクション ] フィールドで、メッセージ読み込み後の動作を選択する。このフィールドは必須。
[アーカイブ ] - メッセージがアーカイブ化される。
[削除 ] - メッセージが削除される。
[ステージ ディレクトリ ] フィールドに、ファイルの処理中に一時的にファイルをステージングする中間ディレクトリを入力する。このフィールドは必須。
[読み込み後のアクション ] フィールドで [アーカイブ ] を選択した場合は、[アーカイブ ディレクトリ ] フィールドにアーカイブ保存先のパスを入力する。[アーカイブ ディレクトリ ] フィールドは、[参照として渡す ] フィールドを選択した場合も必須。
[エラー ディレクトリ ] フィールドに、問題が生じたときにメッセージと添付ファイルを書き込む場所を入力する。このフィールドは必須。
[要求エンコーディング ] フィールドで、ファイル転送における要求の文字セット エンコーディングとして、デフォルトの utf-8
を受け入れるか、別の文字セット エンコーディングを入力する。
FTP サーバのユーザが匿名の場合は、[ユーザ認証 ] フィールドで [匿名 ] を選択し、FTP サーバが外部的にコンフィグレーションされたアカウントの場合は [外部ユーザ ] を選択する。
[ID (電子メール ID) ] フィールドまたは [サービス アカウント ] フィールドに、匿名ユーザのメール ID を入力するか ([ユーザ認証 ] フィールドで [匿名 ] を選択した場合)、またはサービス アカウントを入力する ([ユーザ認証 ] フィールドで [外部ユーザ ] を選択した場合)。[外部ユーザ ] を選択した場合、このフィールドへの入力は必須。
アーカイブ ディレクトリにファイルをステージングして、それをヘッダに参照として渡す場合は、[参照として渡す ] チェックボックスを選択する。
処理時にリモート サーバから FTP ファイルを直接ストリーミングする場合は、[リモート ストリーミング ] チェックボックスを選択する。それ以外の場合は、このフィールドを空白のままにする。[リモート ストリーミング] を選択した場合、アーカイブ ディレクトリはリモートの FTP サーバ マシン上のリモート ディレクトリになる。そのため、FTP ユーザ ディレクトリを基準にした相対パスでアーカイブ ディレクトリを指定する必要がある。
[ファイル マスク ] フィールドに、選択されるファイルの正規表現を入力する。デフォルト値は *.* 。このフィールドは必須。
[ポーリング間隔 ] フィールドにポーリング間隔を秒数で入力する。デフォルト値は 60 。このフィールドは必須。
[読み込み制限 ] フィールドに、ポーリング スイープあたりの読み込みメッセージ最大数を指定する。無制限にするには「0
」と入力する。デフォルト値は 10 。このフィールドは必須。
[読み込み後のアクション ] フィールドで、メッセージ読み込み後の動作を選択する。このフィールドは必須。
[アーカイブ ] - メッセージがアーカイブ化される。
[削除 ] - メッセージが削除される。
[転送モード ] フィールドで転送モードとして [ascii ] または [binary ] を選択する。
[ダウンロード ディレクトリ ] フィールドに、ファイル転送中にファイルをダウンロードするローカルのディレクトリを入力する。このフィールドは必須。
[読み込み後のアクション ] フィールドで [アーカイブ ] を選択した場合は、[アーカイブ ディレクトリ ] フィールドにアーカイブ保存先のパスを入力する。[アーカイブ ディレクトリ ] フィールドは、[参照として渡す ] フィールドを選択した場合も必須。
[エラー ディレクトリ ] フィールドに、問題が生じたときにメッセージを書き込む場所を入力する。このフィールドは必須。
注意 : アーカイブ ディレクトリ、ダウンロード ディレクトリ、およびエラー ディレクトリは絶対パスであり、自動的に作成される。相対パスを指定すると、ファイルは WebLogic Server を起動した Java プロセスを基準にした相対的な位置に作成される。
[要求エンコーディング ] フィールドで、FTP 転送における要求の文字セット エンコーディングとして、デフォルトの utf-8
を受け入れるか、別の文字セット エンコーディングを入力する。
[詳細設定 ] をクリックして追加のフィールドを表示する。
すべてのディレクトリを再帰的にスキャンする場合は、[サブディレクトリのスキャン ] チェックボックスを選択し、それ以外の場合はこのフィールドを空白のままにする。
イベントの配信を受信順にする場合は、[到着順にソート ] チェックボックスを選択する。
[タイムアウト ] フィールドに、接続が切断されるまでのソケット タイムアウト間隔を秒数で入力する。「0」と入力した場合、タイムアウトは発生しない。
[再試行回数 ] フィールドに FTP 接続失敗時の再試行回数を指定する。
オプションの [フィールド テーブル クラス ] フィールドに、受信される FML または FML32 バッファを表すクラス名を入力する。これらは、フィールド名を要素名にマップするために、FML または FML32 から XML への変換ルーチンで使用される。完全修飾クラス名をスペースで区切ってリストする。
オプションの [View クラス ] フィールドに、受信される VIEW または VIEW32 バッファを表すクラス名を入力する。これらは、フィールド名を要素名にマップするために、VIEW から XML または VIEW32 から XML への変換ルーチンで使用される。完全修飾クラス名をスペースで区切ってリストする。
注意 : Tuxedo のバッファ タイプ X_C_TYPE
と X_COMMON
は、VIEW/VIEW32 バッファと同様に処理される。
受信要求に VIEW が含まれる場合、該当する VIEW クラスを AquaLogic Service Bus の CLASSPATH
に指定する必要がある。
[クラス Jar ] フィールドで、このエンドポイント オペレーションに必要な FML/FML32 または VIEW/VIEW32 クラスを持つ JAR ファイルを含んだ JAR リソースを選択する。
エクスポートに関連付けられたドロップダウン リストから、[ローカル アクセス ポイント ] を選択する。このドロップダウン リストには、WTC でコンフィグレーションされたローカル アクセス ポイントが含まれる。関連するローカル アクセス ポイントがない場合、プロキシ サービスは作成できない。
[応答バッファ タイプ ] ドロップダウン リストから、リモート Tuxedo サービスが受信するバッファ タイプを選択する。このフィールドは、[応答が必要 ] フィールドが選択されている場合に有効。
以前の [応答バッファ タイプ] の値が VIEW または VIEW32 である場合、[応答バッファ サブタイプ ] が有効になる。応答バッファに関連付けるバッファのサブタイプを入力する。このフィールドは、[応答が必要 ] フィールドが選択されている場合に有効。
このサービスに応答の送信が想定されている場合は、[応答が必要? ] チェックボックスを選択する。デフォルトは選択された状態、ただしサービスのタイプが [メッセージング サービス ] で、応答メッセージのタイプが [なし ] の場合は選択が解除される。この場合、フィールドは無効。
[応答バッファ タイプ ] の値が MBSTRING である場合、[要求エンコーディング ] フィールドが有効になる。[要求エンコーディング ] のチェックボックスを選択し、Tuxedo クライアントへの送信時の MBSTRING バッファのエンコーディングをオーバーライドする。
[次へ ] をクリックします。
このサービスに処理がある場合 (つまり、このサービスが WSDL に基づく場合) は、[プロキシ サービスの編集 - 操作選択コンフィグレーション ] ページが表示されます。「プロキシ サービスを追加するには - 操作選択コンフィグレーション 」に進みます。
このサービスに処理がない場合は、[全般的なコンフィグレーションの確認 ] ページが表示されます。「プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認 」に進みます。
プロキシ サービスを追加するには - 操作選択コンフィグレーション
このサービスに処理がある場合は、[プロトコル転送コンフィグレーション ] ページで [次へ ] をクリックすると、[操作選択コンフィグレーション ] ページが表示されます。このページでは、WS-I を適用し、このプロキシ サービスによって呼び出される操作の決定に使用される選択アルゴリズムを選択できます。このオプションは、WSDL に基づいて定義された SOAP サービスまたは XML サービスでのみ使用できます。
WSDL 仕様では、受信する SOAP メッセージのタイプに基づいて呼び出す操作を計算するデフォルトのアルゴリズムが定義されています。ただし、その他の手段に基づいて操作を選択しなければならない場合もあります (パフォーマンスや、署名および暗号化に問題があったり、デフォルトのアルゴリズムが使用できない場合など)。
AquaLogic Service Bus には、アルゴリズムが追加で用意されています。これらはそれぞれ同じパターンに従っており、式の評価に基づいて値を取得し、その値を使用して静的なテーブルから対応する操作をルックアップします。
Web Services Interoperability Organization で定義された Basic Profile にサービスを準拠させるかどうかを指定する場合は、[WS-I 準拠の適用 ] チェックボックスを選択します。
サービスを WS-I 準拠として指定すると、サービス間で送受信されるメッセージの確認が行われます。プロキシの場合、プロキシが受信した要求メッセージの確認が行われます。呼び出されるサービス (つまり、プロキシがサービス コールアウト アクションまたはルート ノード経由で呼び出すサービス) の場合、それらのサービスから受信した応答メッセージの確認が行われます。呼び出されるサービスから受信したメッセージを確認するかどうかを決定するのは、呼び出されるサービス側の WS-I 準拠プロパティであり、プロキシ側ではありません。呼び出されるサービスで WS-I 準拠のテストを指定すると、メッセージ フローによって応答エラーの fault が生成されます。
[選択アルゴリズム ] フィールドで、以下のいずれか 1 つを選択します。
表 16-10 [選択アルゴリズム] フィールド
この選択アルゴリズムを選択すると、ルックアップ値を含む転送ヘッダを定義できる。
この選択アルゴリズムを選択すると、このプロキシ サービスに関連付けられた WSDL から自動的に操作のマッピングが行われる。
この選択アルゴリズムを選択すると、ルックアップ値は SOAP メッセージの SOAP ヘッダ内の WS-Addressing Action タグに入る。
この選択アルゴリズムを選択すると、SOAP ヘッダに対して評価される XPath 式を定義して、ルックアップ値を取得できる。
WSDL 仕様で定義されたデフォルトのアルゴリズム。受信する SOAP メッセージのタイプに基づいて呼び出す操作が計算される。
注意 :
プロキシ サービスをコンフィグレーションする Web サービス セキュリティのパススルー シナリオで本体が暗号化されている場合は、選択アルゴリズムとして [SOAP 本体の種類] を選択することはできない。パススルーの暗号化された SOAP ヘッダについても同様。 同じ入力メッセージで 2 つの操作のある WSDL の場合、入力メッセージを調べて操作をユニークに識別できないため、[SOAP 本体の種類] アルゴリズムを操作に選択しないこと。
注意 :
WSDL ポートや WSDL バインディングに基づく XML サービスを作成しようとする場合は、[転送ヘッダ ] と [ペイロードの種類 ] という選択アルゴリズムがこのページに表示されます。 表示されるフィールドの数は選択した選択アルゴリズムによって異なります。
[選択アルゴリズム ] フィールドで選択した選択アルゴリズムに基づき、以下のいずれか 1 つを実行します。
表 16-11 [選択アルゴリズム] フィールド
[ヘッダ名 ] フィールドに、呼び出される動作を選択するときにキーとして使用される値を抽出する転送ヘッダを入力する。
[操作のマッピング ] フィールドの下にある [値 ] フィールドに、各動作の値を指定する。この値が動作のキーとして使用される。このフィールドは必須。
この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
[
操作のマッピング ] フィールドの下にある [
値 ] フィールドに、各動作の値を指定する。この値が動作のキーとして使用される。このフィールドは必須。
[XPath 式 ] フィールドに、呼び出される動作を選択するときにキーとして使用される値を抽出する XPath 式を指定する。
[操作のマッピング ] フィールドの下にある [値 ] フィールドに、各動作の値を指定する。この値が動作のキーとして使用される。このフィールドは必須。
この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
[次へ ] をクリックします。
[全般的なコンフィグレーションの確認 ] ページが表示されます。「プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認 」に進みます。
注意 :
WS-Policy が付加された WSDL (ポートまたはバインディング) からプロキシ サービスを作成する場合は、[次へ ] をクリックすると、[Web サービス セキュリティ コンフィグレーション ] ページが表示されます。このページには、すべての操作について効果的な要求/応答の WS-Policy の読み込み専用ビューが表示されます。
プロキシ サービスをアクティブな媒介として使用し、復号化や署名の検証などの操作を実行する場合は、[WS-Security ヘッダの処理 ] を選択する。
プロキシ サービスをパススルーとして使用し、メッセージの復号化やデジタル署名の検証を行わない場合は、[WS-Security ヘッダの処理 ] を空白にする。
プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認
[操作選択コンフィグレーション ] ページで [次へ ] をクリックすると、[全般的なコンフィグレーションの確認 ] ページが表示されます。このページでは、このプロキシ サービスについてこれまでに入力したコンフィグレーション データを確認できます。必要であれば、[編集 ] をクリックすると、コンフィグレーションを変更してからプロキシ サービスを保存できます。
注意 :
プロキシ サービス作成後の次の手順では、メッセージ フローをコンフィグレーションします。メッセージ フローは、プロキシ サービスの実装を定義します。メッセージ フローには、パイプライン ペア、および、開始ノード、ルート ノード、ブランチ ノードを入れることができます。詳細については、「メッセージ フローの概要 」および「メッセージ フローの表示と変更 」を参照してください。
注意 :
新しいプロキシ サービスは現在のセッションで保存されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーション ペインで、[Change Center ] の下にある [アクティブ化 ] をクリックします。セッションが終了し、コア コンフィグレーションが更新されます。また、セッション中はいつでも [破棄 ] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。
プロキシ サービスからの WSDL の生成
AquaLogic Service Bus では、WSDL バインディングに基づいてプロキシ サービスを作成すると、そのプロキシ サービス用に生成された WSDL に新しいサービスとポートの定義が設定されます。WSDL ポートと WSDL バインディングのどちらに基づいてプロキシ サービスを定義するかに関わらず、そのプロキシ サービス用として生成された WSDL で定義されるポートは 1 つだけです。テンプレート WSDL でポート X からサービスが生成される場合、生成される WSDL でもポート X が定義されます。テンプレート WSDL で定義された他のすべてのポートは、生成される WSDL には含まれません。さらに、WSDL ポートに基づいてプロキシ サービスを作成する場合、生成される WSDL ではそのポート名が使用され、そのポートに関連付けられたすべての WS-Policy が保持されます。バインディングはポートから決定され、ポート タイプはバインディングから決定されます。
サービスがテンプレート WSDL のバインディング Y から生成される場合、生成される WSDL によって新しいサービスとポートが定義されます (<service-name>QSService および <port-name>QSPort)。テンプレート WSDL で定義されたどのポートも、生成される WSDL には含まれません。
WSDL バインディング テンプレートに基づいてサービスを作成する場合は、その WSDL に該当のバインディングに関連付けられた複数のポートが存在する場合があります。各ポートは異なる URL を使用でき、異なる WS-Policy が付加されています。したがって、生成される WSDL は、そのバインディングを使用しますが、そのバインディング用に WS-Policy のない人為的なポートを生成します。すべての WSDL ベース サービスでは、サービス定義の転送セクションで転送タイプと転送 URL を上書きできます。
サービスの URL に ?WSDL を追加したものをブラウザのアドレス フィールドに入力することで、HTTP(S) ベースのプロキシ サービスの WSDL を取得できます。
関連トピック
プロキシ サービスの表示と検索
プロキシ サービスの表示と変更
プロキシ サービスの削除
メッセージ フローの表示と変更
プロキシ サービスの表示と検索
[プロキシ サービスの概要 ] ページでは、プロキシ サービスのリストを表示できます。プロキシ サービスとは、WebLogic Server 上にローカルに実装されるサービスの AquaLogic Service Bus 定義です。詳細については、「プロキシ サービスの概要 」を参照してください。
プロキシ サービスを表示および検索するには
左側のナビゲーション ペインで、[リソース ブラウザ ] の下にある [プロキシ サービス ] を選択します。[プロキシ サービスの概要 ] ページが表示されます。プロキシ サービスごとに、以下の情報が表示されます。各プロパティの詳細については、「プロキシ サービスの表示と変更 」を参照してください。
表 16-12 [プロキシ サービスの概要] ページ
ユニークなプロキシ サービス名。この名前は [
詳細の表示 ] ページにリンクされている。詳細については、「
プロキシ サービスの表示と変更 」を参照。
このパスは、プロジェクト名、およびプロキシ サービスが格納されるフォルダの名前。このリソースが格納されているプロジェクトまたはフォルダにリンクされている。詳細については、「
プロジェクトの詳細の表示 」または「
フォルダの詳細の表示 」を参照。
プロキシ サービスの場合、[アクション] カラムには最大 4 つのアイコンが表示される。
[モニタの管理 ] アイコン。このアイコンは、[モニタ コンフィグレーション - [サービス名] ] ページにリンクされている。アイコンをクリックすると、特定のサービスに対するモニタまたはサービス自体を有効または無効にできる。また、特定のサービスに関するアラート ルールを表示したりコンフィグレーションしたりできる。詳細については、「アラート ルールの表示と検索 」を参照。
[テスト コンソールの起動 ] アイコン。クリックすると、テスト コンソールを起動できる。テスト コンソールは、サービスおよびトランスフォーメーションの設計の検証とテストに使用する。ビジネス サービスの場合、テスト コンソールは実行時 (つまり、セッションをアクティブ化したとき) にのみ使用できる。詳細については、「サービスのテスト 」を参照。
[メッセージ フローの編集 ] アイコン。このアイコンは特定のサービスに関するパイプラインの編集用画面にリンクされている。詳細については、「メッセージ フローの表示と変更 」を参照。
[WSDL のエクスポート ] アイコン。WSDL ベースのすべてのプロキシ サービスに対して表示される。WSDL のエクスポート機能は、WSDL をすばやく IDE などの外部ツールでの消費に使用できるようにする場合に使用する。これは、システムの管理モジュールにあるリソースのエクスポート機能とは異なる。リソースのエクスポート機能は、2 つのドメイン間でリソースを移動およびステージングする場合に使用する。[WSDL のエクスポート ] アイコンをクリックすると、WSDL がエクスポートされる。詳細については、「WSDL のエクスポート 」を参照。
[
オプション ] カラムに以下のアイコンが表示される。
指定したサービスを削除できる [削除 ] アイコン。詳細については、「プロキシ サービスの削除 」を参照。
AquaLogic Service Bus の他のリソースによって参照されているリソースは削除できない。このようなリソースの場合は、[削除] アイコンではなく、赤い X 印の付いた [削除] アイコンが表示される。
特定のプロキシ サービスを検索するには、以下のいずれか 1 つを実行します。
プロキシ サービス名でフィルタする。[名前 ] フィールドと [パス ] フィールドに、検索対象の名前とパスを入力してから、[検索 ] をクリックします。このパスは、プロジェクト名、およびプロキシ サービスが格納されるフォルダの名前であり、検索条件と一致するサービスが表示されます。
リストを再ソートする。ソート可能なカラムには昇順と降順のボタンが表示されます (この場合は [名前 ] カラムと [パス ] カラム)。このボタンをクリックしてソート順を変更します。
ページをスクロールする。右下隅のコントロールを使用します。ページを移動するには、ページ番号を選択するか、次のページ、前のページ、最初のページ、または最後のページに移動する矢印ボタンを使用します。
注意 :
[すべて表示 ] をクリックして、すべてのプロキシ サービスを表示します。
関連トピック
プロキシ サービスの追加
メッセージ フローの表示と変更
プロキシ サービスの表示と変更
[詳細の表示 ] ページでは、個々のプロキシ サービスの詳細を表示および編集できます。詳細については、「プロキシ サービスの概要 」を参照してください。
プロキシ サービスの詳細を表示および編集するには
対象のプロキシ サービスを検索します。詳細については、「プロキシ サービスの表示と検索 」を参照してください。
プロキシ サービス名をクリックします。
[詳細の表示 ] ページに以下の情報が表示されます。
表 16-13 [詳細の表示] ページ
このプロキシ サービスを作成したか、コンフィグレーションにインポートしたユーザ。
ユーザがこのプロキシ サービスを作成したか、コンフィグレーションにインポートした日時。
このプロキシ サービスが参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「
参照の表示 」を参照。
このプロキシ サービスを参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「
参照の表示 」を参照。
このプロキシ サービスの説明 (説明が存在する場合)。
[詳細の表示 ] ページに以下の全般的なコンフィグレーション 情報が表示されます。
このプロキシ サービスのサービス タイプがメッセージング サービスの場合は、以下のメッセージ タイプのコンフィグレーション 情報が表示されます。
表 16-15 メッセージ タイプのコンフィグレーション情報
[
なし ]、[
バイナリ ]、[
テキスト ]、[
MFL ]、または [
XML ] で示される要求メッセージのメッセージ タイプ。
[
なし ]、[
バイナリ ]、[
テキスト ]、[
MFL ]、または [
XML ] で示される応答メッセージのメッセージ タイプ。
このページには以下の転送コンフィグレーション 情報が表示されます。
表 16-16 転送コンフィグレーション情報
転送からすべてのヘッダ、定義に該当するヘッダのどちらを取り出すか。
転送プロトコルが [電子メール] の場合は、以下の 電子メール転送コンフィグレーション 情報が表示されます。
表 16-17 電子メール転送コンフィグレーション情報
ポーリング スイープあたりの読み込みメッセージ最大数。無制限の場合は「
0
」を指定する。
ファイルをアーカイブ ディレクトリにステージングして、ヘッダに参照として渡すかどうか。
メッセージの読み込み後に、アーカイブ化、削除、移動のどの動作を実行するか。
[アーカイブ] - メッセージがアーカイブ化される。
[削除] - メッセージが削除される。
[移動] - メッセージが移動される。
注意 :
[移動] は、IMAP プロトコルでのみ使用可能。
[アーカイブ] - 添付ファイルがアーカイブ ディレクトリに保存される。
[無視] - 添付ファイルが無視される。
[
読み込み後のアクション ] フィールドで [
移動 ] を選択した場合に使用されるメッセージの移動先フォルダ。
電子メールのダウンロードに使用される一時的な保存先。
[
読み込み後のアクション ] フィールドで [
アーカイブ ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[
アーカイブ ディレクトリ ] フィールドは、[
参照として渡す ] フィールドを選択した場合も必須。
問題が生じた場合にメッセージと添付ファイルが書き込まれるファイル システム ディレクトリへのパス。
電子メール転送の要求用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1
。
転送プロトコルがファイルの場合は、以下のファイル転送コンフィグレーション 情報が表示されます。
表 16-18 ファイル転送コンフィグレーション情報
ポーリング スイープあたりの読み込みメッセージの最大数。無制限の場合は「
0
」を指定する
。
すべてのディレクトリを再帰的にスキャンするかどうか。
ファイルをアーカイブ ディレクトリにステージングして、ヘッダに参照として渡すかどうか。
処理時にリモート サーバから ftp ファイルを直接ストリーミングするかどうか。
メッセージの読み込み後に、アーカイブ化または削除するかどうか。
[アーカイブ] - メッセージがアーカイブ化される。
[削除] - メッセージが削除される。
ファイルの処理中に一時的にファイルをステージングする中間ディレクトリ。
問題が生じた場合にメッセージと添付ファイルが書き込まれるファイル システム ディレクトリへのパス。
[
読み込み後のアクション ] フィールドで [
アーカイブ ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[
アーカイブ ディレクトリ ] フィールドは、[
参照として渡す ] フィールドを選択した場合も必須。
ファイル転送の要求用文字セット エンコーディングが表示される。デフォルト値は
utf-8
。
転送プロトコルが [FTP] の場合は、以下の FTP 転送コンフィグレーション 情報が表示されます。
表 16-19 FTP 転送コンフィグレーション情報
匿名ユーザのメール ID または外部的にコンフィグレーションされたユーザのサービス アカウント。
すべてのディレクトリを再帰的にスキャンするかどうか。
ファイルをアーカイブ ディレクトリにステージングして、ヘッダに参照として渡すかどうか。
メッセージの読み込み後に、アーカイブ化または削除するかどうか。
[アーカイブ] - メッセージがアーカイブ化される。
[削除] - メッセージが削除される。
[
読み込み後のアクション ] フィールドで [
アーカイブ ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[
アーカイブ ディレクトリ ] フィールドは、[
参照として渡す ] フィールドを選択した場合も必須。
FTP ファイルのダウンロードに使用される一時的な保存場所。
問題が生じた場合にメッセージと添付ファイルが書き込まれるファイル システム ディレクトリへのパス。
ポーリング スイープあたりの読み込みメッセージの最大数。無制限の場合は「
0
」を指定する
。
転送モード : [Binary] または [ASCII]。
FTP 転送の要求用文字セット エンコーディングが表示される。デフォルト値は
utf-8
。
転送プロトコルが HTTP の場合は、以下の HTTP 転送コンフィグレーション 情報が表示されます。
表 16-20 HTTP 転送コンフィグレーション情報
基本認証が必要かどうか (必要な場合は [有効] が表示される)。
HTTP 転送の要求用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1
。
HTTP 転送の応答用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1
。
転送プロトコルが HTTPS の場合は、以下の HTTPS 転送コンフィグレーション 情報が表示されます。
表 16-21 HTTPS 転送コンフィグレーション情報
クライアント認証方式 : [なし]、[基本]、または [クライアント証明書]。
HTTPS 転送の要求用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1
。
HTTPS 転送の応答用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1
。
転送プロトコルが JMS の場合は、以下の JMS 転送コンフィグレーション 情報が表示されます。
表 16-22 JMS 転送コンフィグレーション情報
送り先のタイプ : [キュー] または [トピック]。
JMSCorrelationID
JMSMessageID
JMSCorrelationID の応答 URI。
MessageID の応答接続ファクトリ URI。
JMS 転送の要求用文字セット エンコーディング。デフォルト値は
utf-8
。
JMS 転送の応答用文字セット エンコーディング。デフォルト値は
utf-8
。
タイムアウトまでクライアント応答を待つ時間 (秒)。
メッセージがエラー送り先に送信されるまでの再試行回数としてコンフィグレーションされた数。
有効期限の経過したメッセージが送り先で検出されたときに使用する有効期限ポリシー。
JMS サーバによって管理される JMS リソースに使用するサービス アカウント。
転送プロトコルが Tuxedo の場合は、以下の Tuxedo 転送コンフィグレーション 情報が表示されます。
表 16-23 Tuxedo 転送コンフィグレーション情報
バッファのマップに用いる FML ファイルの完全修飾クラス名をスペースで区切ったリスト。
バッファのマップに用いる View クラスの完全修飾名をスペースで区切ったリスト。
エンドポイント オペレーションに必要な FML/FML32 または VIEW/VIEW32 クラスを持つ JAR ファイルを含む JAR リソース。
WTC エクスポート サービスに関連付けられた URI エンドポイント用のローカル アクセス ポイント。
リモート Tuxedo クライアントが受信するバッファ タイプ。このフィールドは、[
応答が必要 ] フィールドが選択されている場合に有効。
CARRAY、FML、FML32、MBSTRING、STRING、VIEW、VIEW32、X_COMMON、X_C_TYPE、XML、X_OCTET で示される有効なバッファ タイプ。
バッファ タイプが VIEW または VIEW32 の場合に、応答バッファに関連付けるバッファのサブタイプ。
チェックボックスが選択されている場合に有効。応答を必須にする。選択していない場合は、応答は不要。
デフォルトは選択された状態、ただしサービスのタイプが [
メッセージング サービス ] で、応答メッセージのタイプが [
なし ] の場合は選択が解除される。この場合、フィールドは無効。
チェックボックスを選択し、Tuxedo クライアントに送信する際の MBSTRING バッファのエンコーディングをオーバーライドする。このフィールドは、[
応答バッファ タイプ ] フィールドの値が MBSTRING である場合に有効。
このページには以下の操作選択コンフィグレーション 情報が表示されます。
表 16-24 操作選択コンフィグレーション情報
このオプションを選択してサービスが WS-I 準拠であるかどうかを指定した場合は、[
はい ] が表示され、これを指定しなかった場合は、[
いいえ ] が表示される。
このプロキシ サービスに呼び出される操作を決定する選択アルゴリズム。
このプロキシ サービスについて [
選択アルゴリズム ] フィールドで [
転送ヘッダ ] を選択している場合、このフィールドには、呼び出される処理を選択するキーとして使用される値を抽出する転送ヘッダが表示される。
このプロキシ サービスについて [
選択アルゴリズム ] フィールドで [
SOAP ヘッダ ] を選択している場合、呼び出される操作を選択するキーとして使用される値を抽出する XPath 式がこのフィールドに表示される。
このプロキシ サービスについて [
選択アルゴリズム ] フィールドで [
転送ヘッダ ]、[
WS-Addressing ]、または [
SOAP ヘッダ ] を選択している場合、各処理の値がこのフィールドに表示される。この値が動作のキーとして使用される。
セッションの作成または編集をまだ行っていない場合は、左側のナビゲーション ペインで、[Change Center ] の下にある [作成 ] をクリックして新しいセッションを作成するか、[編集 ] をクリックして既存のセッションに入り、現在のコンフィグレーションを変更します。詳細については、「Change Center の使用 」を参照してください。
対象のページについて [編集 ] をクリックして、各コンフィグレーション ページのフィールドに変更を加えます。各ページとフィールドの詳細については、「プロキシ サービスの追加 」を参照してください。
注意 :
[サービス名 ] および [サービスの種類 ] フィールドは変更できません。
以下のいずれか 1 つを実行します。
[完了 ] をクリックして、プロキシ サービスを更新する。[プロキシ サービスの編集 - 概要 ] ページが表示されます。[保存 ] をクリックして更新内容をコミットします。
[<<前へ ] をクリックして、前のページに戻る。
[取り消し ] をクリックして、変更を取り消し、[プロキシ サービスの概要 ] ページに戻る。
注意 :
プロキシ サービスは現在のセッションで更新されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーション ペインで、[Change Center ] の下にある [アクティブ化 ] をクリックします。セッションが終了し、コア コンフィグレーションが更新されます。また、セッション中はいつでも [破棄 ] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。
関連トピック
プロキシ サービスの追加
プロキシ サービスの表示と変更
プロキシ サービスの削除
プロキシ サービスの削除
[プロキシ サービスの概要 ] ページでは、プロキシ サービスを削除できます。詳細については、「プロキシ サービスの概要 」を参照してください。
注意 :
AquaLogic Service Bus の他のリソースによって参照されているリソースは削除できません。このようなリソースの場合は、[削除] アイコンではなく、赤い X 印の付いた [削除] アイコンが表示されます。
注意 :
AquaLogic Service Bus からプロキシ サービスを削除する前に、そのプロキシ サービスに関連付けられたすべてのサービス レベルのアクセス制御ポリシーと転送レベルのアクセス制御ポリシーを削除する必要があります。
プロキシ サービスを削除するには
まだセッションを作成していない場合は、左側のナビゲーション ペインで、[Change Center ] の下にある [作成 ] をクリックして、現在のコンフィグレーションに変更を加えるための新しいセッションを作成します。詳細については、「Change Center の使用 」を参照してください。
左側のナビゲーション ペインで、[リソース ブラウザ ] の下にある [プロキシ サービス ] を選択します。[プロキシ サービスの概要 ] ページが表示されます。
削除するプロキシ サービスの [オプション ] フィールドにある [削除 ] アイコンをクリックします。
そのプロキシ サービスがリストから削除されます。
注意 :
必要に応じて、このリソースの削除を取り消すことができます。詳細については、「タスクの取り消し 」を参照してください。
プロキシ サービスは現在のセッション内で削除されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーション ペインで、[Change Center ] の下にある [アクティブ化 ] をクリックします。セッションが終了し、コア コンフィグレーションが更新されます。また、セッション中はいつでも [破棄 ] をクリックすることができ、現在のセッションでこれまでに加えた変更を取り消すことができます。
関連トピック
プロキシ サービスの追加
プロキシ サービスの表示と変更
メッセージ フローの表示と変更