このスクリプトでは、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 1.2 プロキシの場合、$body および $header は、SOAP 1.1 ネームスペース本体およびネームスペースではなく SOAP 1.2 ネームスペース本体およびネームスペースである。
SOAP メッセージに添付ファイルがあれば、
$attachments 変数に格納される。
ポート タイプを定義しないため、
$operation 変数はこのサービス タイプには使用されない。
メッセージ コンテキスト変数の詳細については、AquaLogic Service Bus ユーザーズ ガイドの「
メッセージ関連の変数 」および「
送信するメッセージの作成 」を参照。
バインディング定義 : このサービス タイプで定義する情報は、WSDL バインディング定義とは無関係に、サービスで XML メッセージを受信するか送信するかのみである。したがって、このタイプのバインディング コンフィグレーションは空になる。
また、バインディング コンフィグレーションが存在しないため、このタイプではメッセージのコンテンツ タイプとの組み合わせで、メッセージに添付ファイルがあるかどうかを十分判別できる。
定義上、どのサービス (SOAP または XML) も WSDL 定義を持たない。これらのサービスの WSDL ドキュメントを要求することはできない。
$body 変数内の
<soap:Body> 要素内に受信 XML メッセージがラップされて格納される。
注意 :
SOAP 1.2 プロキシの場合、$body および $header は、SOAP 1.1 ネームスペース本体およびネームスペースではなく SOAP 1.2 ネームスペース本体およびネームスペースである。
メッセージに添付ファイルがあれば、
$attachments 変数に格納される。
$header 変数はこのサービス タイプには使用されず、デフォルト値に設定される。
ポート タイプを定義しないため、
$operation 変数はこのサービス タイプには使用されない。
メッセージ コンテキスト変数の詳細については、AquaLogic Service Bus ユーザーズ ガイドの「
メッセージ関連の変数 」および「
送信するメッセージの作成 」を参照。
バインディング定義 : メッセージング サービス用のバインディング定義は、交換されるメッセージのコンテンツ タイプのコンフィグレーションで構成される。応答のコンテンツ タイプは、要求のコンテンツ タイプと同じである必要はない。そのため、応答は個別にコンフィグレーションされ (たとえば、サービスで MFL メッセージを受信し、XML の受信確認を返すことも可能)、[なし] に設定することも可能。
定義上、メッセージベースのサービスには WSDL 定義は存在しない。これらのサービスの WSDL ドキュメントを要求することはできない。
要求 (および応答) のコンテンツ タイプは、以下の 4 つから選択できる。
このサービス タイプはメッセージ ベースである。Web サービスには複数の「操作」という概念はない。したがって、
$operation 変数は空のままになる。
$body 変数内の
<soap:Body> 要素内に受信メッセージがラップされて格納される。
$header 変数はこのサービス タイプでは使用されず、デフォルト値に設定される。
メッセージに添付ファイルがあれば、
$attachments 変数に格納される。
注意 :
SOAP 1.2 プロキシの場合、$body および $header は、SOAP 1.1 ネームスペース本体およびネームスペースではなく SOAP 1.2 ネームスペース本体およびネームスペースである。
メッセージ コンテキスト変数の詳細については、AquaLogic Service Bus ユーザーズ ガイドの「
メッセージ関連の変数 」および「
送信するメッセージの作成 」を参照。
プロキシ サービスのタイプと転送方式
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 サービス ] を選択する。
ドロップダウン リストでデフォルトの [
SOAP 1.1 ] を選択したままにするか、[
SOAP 1.2 ] を選択する。
明示的に定義された具象インタフェースを持たない XML サービスの作成
明示的に定義された具象インタフェースを持たない XML サービスを作成するには、[
任意の XML サービス ] を選択する。
注意 :
HTTP GET に対応しているサービス タイプは、任意の XML サービスとメッセージング サービスのみ。
既存のビジネス サービスからのプロキシ サービスの作成
[既存のサービスから作成 ] の下にある [ビジネス サービス ] を選択する。
[参照 ] をクリックする。[サービス ブラウザ ] が表示される。
[サービス ブラウザ ] で、ビジネス サービスを選択する。
[送信 ] をクリックしてダイアログ ボックスを閉じ、[全般的なコンフィグレーション ] ページに戻る。
これにより、選択したビジネス サービスにルーティングするルート ノードを備えたプロキシ サービスを作成できる。ビジネス サービスの詳細については、「
ビジネス サービスの概要 」を参照。
注意 :
転送タイプのビジネス サービスからプロキシ サービスを作成することはできない。
注意 :
DSP 転送ビジネス サービスからプロキシ サービスを作成する場合、DSP 転送ではプロキシ サービスを使用できないため、プロキシ サービスの転送タイプは自動的に HTTP に切り替わる。その後、プロキシ サービスの転送タイプを他の使用可能な転送方式に変更できる。
既存のプロキシ サービスからのプロキシ サービスの作成
[既存のサービスから作成 ] の下にある [プロキシ サービス ] を選択する。
[参照 ] をクリックする。[サービス ブラウザ ] が表示される。
[サービス ブラウザ ] でプロキシ サービスを選択する。
[送信 ] をクリックしてダイアログ ボックスを閉じ、[全般的なコンフィグレーション ] ページに戻る。
これにより、選択したプロキシ サービスのクローンを新しいプロキシ サービスとして作成できる。
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 で送信するのが安全。
警告 : デフォルトでは、すべてのユーザ (認可ユーザおよび匿名ユーザ) がプロキシ サービスにアクセス可能である。プロキシ サービスにアクセスできるユーザを制限するには、転送レベルの認可ポリシーを作成する必要がある。「転送レベルのアクセス ポリシーの編集 」を参照。
[カスタム認証 ] フィールドを選択して、認証トークンが HTTP ヘッダに含まれていることを示す。クライアントの ID は、ここでクライアントが指定したトークンを使用して設定される。トークンを AquaLogic Service Bus ユーザにマップする ID アサーション プロバイダをコンフィグレーションする必要がある。
カスタム認証トークンには、コンフィグレーションされた WebLogic Server ID アサーション プロバイダがサポートする任意のアクティブなトークン タイプを指定できる。
[詳細設定 ] が自動的に表示される。
[ディスパッチ ポリシー ] フィールドで、このエンドポイントのディスパッチ ポリシーを選択する。デフォルトのディスパッチ ポリシーを使用するには、空白にする。
ディスパッチ ポリシーは、サービスのエンドポイントに使用する 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] が設定される。
[詳細設定 ] の [認証ヘッダ ] フィールドに、AquaLogic Service Bus がトークンを抽出する HTTP ヘッダ ([認可] 以外の任意の値) を入力する。このフィールドが使用可能になるのは、[カスタム認証 ] チェックボックスが選択されている場合のみ。
例 : client-xyz-token
[詳細設定 ] のドロップダウン リストで、[認証トークンの種類 ] を選択する。ID アサーション プロバイダにコンフィグレーションされたアクティブなトークンのタイプのみが使用可能になる(詳細については、「カスタム トークン用 ID アサーション プロバイダのコンフィグレーション 」を参照)。このフィールドが使用可能になるのは、[カスタム認証 ] チェックボックスが選択されている場合のみ。
[クライアント認証 ] フィールドで、クライアント認証方式として [なし ]、[基本 ]、[クライアント証明書 ]、または [カスタム認証 ] を選択する。
警告 : デフォルトでは、すべてのユーザ (認可ユーザおよび匿名ユーザ) がプロキシ サービスにアクセス可能である。プロキシ サービスにアクセスできるユーザを制限するには、転送レベルの認可ポリシーを作成する必要がある。「転送レベルのアクセス ポリシーの編集 」を参照。
[カスタム認証 ] チェックボックスを選択すると、認証トークンが HTTP ヘッダに含まれていることを示す。クライアントの ID は、ここでクライアントが指定したトークンを使用して設定される。トークンを AquaLogic Service Bus ユーザにマップする ID アサーション プロバイダをコンフィグレーションする必要がある。
[詳細設定 ] が自動的に表示される。
[ディスパッチ ポリシー] フィールドで、このエンドポイントのディスパッチ ポリシーを選択する。デフォルトのディスパッチ ポリシーを使用するには、空白にする。ディスパッチ ポリシーは、サービスのエンドポイントに使用する WLS 9.0 ワーク マネージャのインスタンスを参照する。たとえば、プロキシ サービスが JMS 転送プロトコルに対応している場合、サービスのエンドポイントは、そのディスパッチ ポリシーに関連付けることのできる MDB (メッセージ駆動型 Bean) の JAR ファイルになる。
[要求エンコーディング ] フィールドで、HTTPS 転送における要求の文字セット エンコーディングとして、デフォルトの iso-8859-1 を受け入れるか、別の文字セット エンコーディングを入力する。
[応答エンコーディング ] フィールドで、HTTPS 転送における応答の文字セット エンコーディングとして、デフォルトの iso-8859-1 を受け入れるか、別の文字セット エンコーディングを入力する。
[詳細設定] の [認証ヘッダ ] フィールドに、AquaLogic Service Bus がトークンを抽出する HTTP ヘッダ ([認可] 以外の任意の値) を入力する。このフィールドが使用可能になるのは、[カスタム認証 ] チェックボックスが選択されている場合のみ。
例 : client-xyz-token
[詳細設定 ] のドロップダウン リストで、[認証トークンの種類 ] を選択する。ID アサーション プロバイダにコンフィグレーションされたアクティブなトークンのタイプのみが使用可能になる(詳細については、「カスタム トークン用 ID アサーション プロバイダのコンフィグレーション 」を参照)。このフィールドが使用可能になるのは、[カスタム認証 ] チェックボックスが選択されている場合のみ。
[送り先の種類 ] フィールドで [キュー ] または [トピック ] を選択する。
[送り先の種類 ] フィールドで [キュー ] を選択した場合は、必要に応じて [応答が必要 ] を選択する。このオプションにより、メッセージの送信後に応答を受け取るか受け取らないかが決まる。このチェックボックスを選択しない場合は、手順 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 ファイルになる。
[詳細設定 ] をクリックして追加のフィールドを表示する。
要求を TLS/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 である場合、[応答バッファ サブタイプ ] が有効になる。応答バッファに関連付けるバッファのサブタイプを入力する。このフィールドは、[応答が必要 ] フィールドが選択されている場合に有効。
このサービスに応答の送信が想定されている場合は、[応答が必要? ] チェックボックスを選択する。デフォルトは選択された状態、ただしサービスのタイプがメッセージング サービス で、応答メッセージのタイプが [なし ] の場合は選択が解除される。この場合、フィールドは無効。
[要求エンコーディング ] フィールドに、Tuxedo 転送の要求のエンコーディングを設定する文字を指定する。
[応答エンコーディング ] フィールドに、Tuxedo 転送の応答のエンコーディングを設定する文字を指定する。
[トランスフォーメーション スタイル ] フィールドで、以下のいずれかを選択する。
[なし] - (デフォルト) フィールドの順序を無視する。
[順序付け] - すべてのフィールドを正しい順序で表示する。
[グループ別および順序付け] - フィールドが論理的にレコード構造になっている場合、発生順に並べ替えられ、レコードごとにグループ化される。
[次へ ] をクリックします。
このプロキシ サービスがメッセージ レベルのセキュリティをサポートするタイプである場合、[プロキシ サービスの作成 - メッセージ レベル セキュリティのコンフィグレーション ] ページが表示されます。「プロキシ サービスを追加するには - メッセージ レベル セキュリティのコンフィグレーション 」に進みます。
このサービスのタイプがメッセージ レベルのセキュリティをサポートしない場合、サービスに処理があるかどうかによって異なるページが表示されます。
プロキシ サービスを追加するには - メッセージ レベル セキュリティのコンフィグレーション
このサービスがメッセージ レベルのセキュリティをサポートするタイプである場合、[プロキシ サービスの作成 - メッセージ レベル セキュリティのコンフィグレーション ] ページが表示されます。このページでは、カスタム メッセージ レベル認証と WS-Security ポリシーを使用できます。カスタム メッセージ レベル認証および WS-Security ポリシーの詳細については、AquaLogic Service Bus のセキュリティ ガイド を参照してください。
メッセージ レベルのカスタム トークン、およびメッセージ レベルのユーザ名とパスワードが以下のバインディング タイプのプロキシ サービスでサポートされます。
WSDL-SOAP
WSDL-XML
抽象 SOAP
抽象 XML
混合 - XML (要求内)
混合 - MFL (要求内)
カスタム ユーザ名/パスワードとカスタム トークンのコンフィグレーションは、ほぼ同じです。どちらの場合も、AquaLogic Service Bus で必要な情報を検索できるようにするための XPath 式を指定します。これらの XPath 式のルートは以下のとおりです。
サービスのバインディングが AnySOAP または WSDL-SOAP の場合は soap-env:Envelope/soap-env:Header を使用する。
サービスのバインディングが SOAP ベースでない場合は soap-env:Body を使用する。
注意 :
すべての XPath 式は有効な XPath 2.0 形式である必要があります。使用するネームスペースを XPath 式で宣言するには、次のような XPath の "declare namespace" 構文を使用します。
注意 :
declare namespace ns='http://webservices.mycompany.com/MyExampleService';)
[カスタム認証を使用 ] フィールドで、以下のいずれか 1 つを実行します。
表 16-10 メッセージ レベル セキュリティのコンフィグレーション - [カスタム認証を使用]
WS-Policy が付加された WSDL (ポートまたはバインディング) からプロキシ サービスを作成した場合は、[メッセージ レベル セキュリティ コンフィグレーション ] ページに [WS-Security ヘッダの処理 ] フィールドおよび [有効な要求/応答ポリシー ] フィールドも表示される。手順 2 に進む。
WS-Policy が付加された WSDL (ポートまたはバインディング) 以外からプロキシ サービスを作成した場合は、[次へ ] をクリックする。サービスに処理があるかどうかによって異なるページが表示される。
[
カスタム認証設定 ] フィールドで、[
カスタム ユーザ名とパスワード ] または [
カスタム トークン ] を選択する。このフィールドは必須。
[
カスタム ユーザ名とパスワード ] または [
カスタム トークン ] のいずれを選択するかによって、異なる詳細設定が表示される。
[カスタム ユーザ名とパスワード ] を選択した場合は、[ユーザ名 XPath ] と [ユーザ パスワード XPath ] を指定する必要がある。メッセージ ヘッダまたはペイロードに関して XPath 式が評価され、AquaLogic Service Bus はカスタム認証用のユーザ名とパスワードを取得できるようになる。
[カスタム トークン ] を選択した場合は、[トークン タイプ ] と [トークン XPath ] を指定する必要がある。
ドロップダウン リストから [トークン タイプ ] を選択する。WebLogic Server ID アサーション プロバイダにコンフィグレーションされたアクティブなトークンのタイプのみが使用可能になる。詳細については、「カスタム トークン用 ID アサーション プロバイダのコンフィグレーション 」を参照。
[トークン XPath ] フィールドに XPath 式を入力する。ここには、カスタム トークンのパスを指定する。AquaLogic Service Bus は、メッセージ ヘッダまたはペイロードに関して [トークン XPath ] 式を評価し、カスタム認証用のトークンを取得する。
(オプション) [コンテキスト プロパティ ] を指定して、認証 ([カスタム ユーザ名とパスワード ]) または ID アサーション ([カスタム トークン ]) セキュリティ プロバイダに追加コンテキスト情報を渡す。[コンテキスト プロパティ ] は、WebLogic Security Framework に追加情報を渡して、セキュリティ プロバイダがコンテキスト情報を取得できるようにする手段 (ContextHandler インタフェース) を提供する。詳細については、「メッセージレベル認証用の追加のコンテキスト プロパティ 」を参照。
[プロパティ名 ] をリテラル文字列で入力し、[値セレクタ ] に有効な XPath 式を入力する。XPath 式にリテラル文字列を使用することも可能。
XPath 式は、カスタム トークンまたはカスタム ユーザ名/パスワードで使用されているのと同じメッセージ部に関して評価される。つまり、[値セレクタ ] XPath 式は、SOAP ベースのプロキシ サービスの場合はヘッダに関して評価され、非 SOAP ベースのプロキシ サービスの場合はペイロードに関して評価される。
XPath 式は、実行時に評価され、プロパティの値を生成する。ContextHandler は名前と値のリストであるため、セキュリティ プロバイダが検索対象の名前を認識している必要がある。そのため、セキュリティ プロバイダがこれらのユーザ定義プロパティのいずれかの値を要求した場合にのみ XPath 式は評価される。
[プロパティを追加 ] をクリックして、このコンテキスト プロパティを追加する。複数の [コンテキスト プロパティ ] を追加可能。
WS-Policy が付加された WSDL (ポートまたはバインディング) からプロキシ サービスを作成した場合は、[メッセージ レベル セキュリティ コンフィグレーション ] ページに [WS-Security ヘッダの処理 ] フィールドおよび [有効な要求/応答ポリシー ] フィールドも表示されます。
[有効な要求/応答ポリシー ] フィールドには、すべての操作について有効な要求/応答の WS-Policy の読み込み専用ビューが表示されます。
以下のいずれかを実行します。
[次へ ] をクリックします。
このサービスに処理がある場合 (つまり、このサービスが WSDL に基づく場合) は、[プロキシ サービスの編集 - 操作選択コンフィグレーション ] ページが表示されます。「プロキシ サービスを追加するには - 操作選択コンフィグレーション 」に進みます。
このサービスに処理がない場合は、[全般的なコンフィグレーションの確認 ] ページが表示されます。「プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認 」に進みます。
プロキシ サービスを追加するには - 操作選択コンフィグレーション
このサービスに処理がある場合は、[プロトコル転送コンフィグレーション ] ページで [次へ ] をクリックすると、[操作選択コンフィグレーション ] ページが表示されます。このページでは、WS-I を適用し (SOAP 1.1 サービスの場合のみ)、このプロキシ サービスによって呼び出される操作の決定に使用される選択アルゴリズムを選択できます。このオプションは、WSDL に基づいて定義された SOAP サービスまたは XML サービスでのみ使用できます。
WSDL 仕様では、受信する SOAP メッセージのタイプに基づいて呼び出す操作を計算するデフォルトのアルゴリズムが定義されています。ただし、その他の手段に基づいて操作を選択しなければならない場合もあります (パフォーマンスや、署名および暗号化に問題があったり、デフォルトのアルゴリズムが使用できない場合など)。
AquaLogic Service Bus には、アルゴリズムが追加で用意されています。これらはそれぞれ同じパターンに従っており、式の評価に基づいて値を取得し、その値を使用して静的なテーブルから対応する操作をルックアップします。
注意 :
通常、AquaLogic Service Bus は、受信メッセージが不明なデータで処理を判断できない場合や、データが有効な処理に対応していない場合にも、柔軟に対処します。どちらの場合も、$operation は空になります。AquaLogic Service Bus does では、このようなメッセージをすべて拒否するのではなく、コンテキスト内の operation 変数を初期化せずに、メッセージの処理を続行します。
注意 :
ただし、プロキシ サービスが WSDL ベースで、以下の条件の 1 つ以上が当てはまる場合は、セキュリティ要件が適用されます。
WSDL に WS-Security ポリシーが存在し、プロキシがアクティブな仲介になっている。
プロキシにメッセージ レベルのカスタム認証 (カスタム トークンまたはユーザ名/パスワード) が存在する。
注意 :
これらの条件に該当する場合、操作選択アルゴリズムが有効な操作名を返すかどうかを確認する実行時チェックが行われます。操作選択アルゴリズムで null または WSDL に存在しない操作が返された場合、メッセージは拒否され、エラーが発生します。
SOAP 1.1 サービス専用。Web Services Interoperability Organization で定義された Basic Profile にサービスを準拠させるかどうかを指定する場合は、[WS-I 準拠の適用 ] チェックボックスを選択します。
サービスを WS-I 準拠として指定すると、サービス間で送受信されるメッセージの確認が行われます。プロキシの場合、プロキシが受信した要求メッセージの確認が行われます。呼び出されるサービス (つまり、プロキシがサービス コールアウト アクションまたはルート ノード経由で呼び出すサービス) の場合、それらのサービスから受信した応答メッセージの確認が行われます。呼び出されるサービスから受信したメッセージを確認するかどうかを決定するのは、呼び出されるサービス側の WS-I 準拠プロパティであり、プロキシ側ではありません。呼び出されるサービスで WS-I 準拠のテストを指定すると、メッセージ フローによって応答エラーの fault が生成されます。
[選択アルゴリズム ] フィールドで、以下のいずれか 1 つを選択します。
表 16-11 [選択アルゴリズム] フィールド
この選択アルゴリズムを選択すると、ルックアップ値を含む転送ヘッダを定義できる。
この選択アルゴリズムを選択すると、このプロキシ サービスに関連付けられた WSDL から自動的に操作のマッピングが行われる。
この選択アルゴリズムを選択すると、ルックアップ値は SOAP メッセージの SOAP ヘッダ内の WS-Addressing Action タグに入る。
この選択アルゴリズムを選択すると、SOAP ヘッダに対して評価される XPath 式を定義して、ルックアップ値を取得できる。
WSDL 仕様で定義されたデフォルトのアルゴリズム。受信する SOAP メッセージのタイプに基づいて呼び出す操作が計算される。
注意 :
プロキシ サービスをコンフィグレーションする Web サービス セキュリティのパススルー シナリオで本体が暗号化されている場合は、選択アルゴリズムとして [SOAP 本体の種類] を選択することはできない。パススルーの暗号化された SOAP ヘッダについても同様。 同じ入力メッセージで 2 つの操作のある WSDL の場合、入力メッセージを調べて操作をユニークに識別できないため、[SOAP 本体の種類] アルゴリズムを操作に選択しないこと。
注意 :
WSDL ポートや WSDL バインディングに基づく XML サービスを作成しようとする場合は、[転送ヘッダ ] と [ペイロードの種類 ] という選択アルゴリズムがこのページに表示されます。 表示されるフィールドの数は選択した選択アルゴリズムによって異なります。
[選択アルゴリズム ] フィールドで選択した選択アルゴリズムに基づき、以下のいずれか 1 つを実行します。
表 16-12 [選択アルゴリズム] フィールド
[ヘッダ名 ] フィールドに、呼び出される動作を選択するときにキーとして使用される値を抽出する転送ヘッダを入力する。
[操作のマッピング ] フィールドの下にある [値 ] フィールドに、各動作の値を指定する。この値が動作のキーとして使用される。このフィールドは必須。
この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
[
操作のマッピング ] フィールドの下にある [
値 ] フィールドに、各動作の値を指定する。この値が動作のキーとして使用される。このフィールドは必須。
[XPath 式 ] フィールドに、呼び出される動作を選択するときにキーとして使用される値を抽出する XPath 式を指定する。
[操作のマッピング ] フィールドの下にある [値 ] フィールドに、各動作の値を指定する。この値が動作のキーとして使用される。このフィールドは必須。
この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
この選択アルゴリズムを選択した場合は、追加のフィールドが表示されない。
[次へ ] をクリックします。
[全般的なコンフィグレーションの確認 ] ページが表示されます。「プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認 」に進みます。
プロキシ サービスを追加するには - 全般的なコンフィグレーションの確認
[操作選択コンフィグレーション ] ページで [次へ ] をクリックすると、[全般的なコンフィグレーションの確認 ] ページが表示されます。このページでは、このプロキシ サービスについてこれまでに入力したコンフィグレーション データを確認できます。必要であれば、[編集 ] をクリックすると、コンフィグレーションを変更してからプロキシ サービスを保存できます。
注意 :
プロキシ サービス作成後の次の手順では、メッセージ フローをコンフィグレーションします。メッセージ フローは、プロキシ サービスの実装を定義します。メッセージ フローには、パイプライン ペア、および、開始ノード、ルート ノード、ブランチ ノードを入れることができます。詳細については、「メッセージ フローの概要 」および「メッセージ フローの表示と変更 」を参照してください。
注意 :
新しいプロキシ サービスは現在のセッションで保存されます。コンフィグレーションに対する変更が完了したら、左側のナビゲーション ペインで、[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 を上書きできます。
クラスタ ドメインでは、動的 WSDL の生成時に、AquaLogic Service Bus がサーバまたはクラスタのコンフィグレーションに基づいてエンドポイント URL を変更します。フロントエンド HTTP ホスト/ポート (HTTPS エンドポイントの場合はフロントエンド HTTPS ホスト/ポート) が指定されている場合はそのホストまたはポートを使用し、それ以外の場合は管理対象サーバのホストまたはポートを使用します。フロントエンド HTTP または HTTPS のホスト/ポートをクラスタ ドメイン内に割り当てることを強くお勧めします。
サービスの URL に ?WSDL を追加したものをブラウザのアドレス フィールドに入力することで、HTTP(S) ベースのプロキシ サービスの WSDL を取得できます。
関連トピック
プロキシ サービスの表示と検索
プロキシ サービスの表示と変更
プロキシ サービスの削除
メッセージ フローの表示と変更
プロキシ サービスの表示と検索
[プロキシ サービスの概要 ] ページでは、プロキシ サービスのリストを表示できます。プロキシ サービスとは、WebLogic Server 上にローカルに実装されるサービスの AquaLogic Service Bus 定義です。詳細については、「プロキシ サービスの概要 」を参照してください。
プロキシ サービスを表示および検索するには
左側のナビゲーション ペインで、[リソース ブラウザ ] の下にある [プロキシ サービス ] を選択します。[プロキシ サービスの概要 ] ページが表示されます。プロキシ サービスごとに、以下の情報が表示されます。各プロパティの詳細については、「プロキシ サービスの表示と変更 」を参照してください。
表 16-13 [プロキシ サービスの概要] ページ
ユニークなプロキシ サービス名。この名前は [
詳細の表示 ] ページにリンクされている。詳細については、「
プロキシ サービスの表示と変更 」を参照。
このパスは、プロジェクト名、およびプロキシ サービスが格納されるフォルダの名前。このリソースが格納されているプロジェクトまたはフォルダにリンクされている。詳細については、「
プロジェクトの詳細の表示 」または「
フォルダの詳細の表示 」を参照。
プロキシ サービスの場合、[アクション] カラムには最大 3 つのアイコンが表示される。
[テスト コンソールの起動 ] アイコン。クリックすると、テスト コンソールを起動できる。テスト コンソールは、サービスおよびトランスフォーメーションの設計の検証とテストに使用する。詳細については、「サービスのテスト 」を参照。
[メッセージ フローの編集 ] アイコン。このアイコンは特定のサービスに関するパイプラインの編集用画面にリンクされている。詳細については、「メッセージ フローの表示と変更 」を参照。
[WSDL のエクスポート ] アイコン。WSDL ベースのすべてのプロキシ サービスに対して表示される。WSDL のエクスポート機能は、WSDL をすばやく IDE などの外部ツールでの消費に使用できるようにする場合に使用する。これは、システムの管理モジュールにあるリソースのエクスポート機能とは異なる。リソースのエクスポート機能は、2 つのドメイン間でリソースを移動およびステージングする場合に使用する。[WSDL のエクスポート ] アイコンをクリックすると、WSDL がエクスポートされる。詳細については、「WSDL のエクスポート 」を参照。
[
オプション ] カラムに以下のアイコンが表示される。
指定したサービスを削除できる [削除 ] アイコン。詳細については、「プロキシ サービスの削除 」を参照。
AquaLogic Service Bus の他のリソースによって参照されているリソースは削除できない。このようなリソースの場合は、[削除] アイコンではなく、赤い X 印の付いた [削除] アイコンが表示される。
特定のプロキシ サービスを検索するには、以下のいずれか 1 つを実行します。
プロキシ サービス名でフィルタする。[名前 ] フィールドと [パス ] フィールドに、検索対象の名前とパスを入力してから、[検索 ] をクリックします。このパスは、プロジェクト名、およびプロキシ サービスが格納されるフォルダの名前であり、検索条件と一致するサービスが表示されます。
リストを再ソートする。下線付きのカラム名をクリックします。昇順および降順の矢印はソート順を示します。このカラム名をクリックしてソート順を変更します。
ページをスクロールする。表の上下にあるページ コントロールを使用します。ページを移動するには、ページ番号を選択するか、次のページ、前のページ、最初のページ、または最後のページに移動する矢印ボタンを使用します。
注意 :
[すべて表示 ] をクリックして、すべてのプロキシ サービスを表示します。
関連トピック
プロキシ サービスの追加
メッセージ フローの表示と変更
プロキシ サービスの表示と変更
[詳細の表示 ] ページでは、個々のプロキシ サービスの詳細を表示および編集できます。詳細については、「プロキシ サービスの概要 」を参照してください。
プロキシ サービスの詳細を表示および編集するには
対象のプロキシ サービスを検索します。詳細については、「プロキシ サービスの表示と検索 」を参照してください。
プロキシ サービス名をクリックします。
[詳細の表示 ] ページに以下の情報が表示されます。
表 16-14 [詳細の表示] ページ
このプロキシ サービスを作成したか、コンフィグレーションにインポートしたユーザ。
ユーザがこのプロキシ サービスを作成したか、コンフィグレーションにインポートした日時。
このプロキシ サービスが参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「
参照の表示 」を参照。
このプロキシ サービスを参照するオブジェクトの数。該当する参照がある場合は、リンクをクリックするとオブジェクトのリストが表示される。詳細については、「
参照の表示 」を参照。
このプロキシ サービスの説明 (説明が存在する場合)。
[詳細の表示 ] ページに以下の全般的なコンフィグレーション 情報が表示されます。
このプロキシ サービスのサービス タイプがメッセージング サービスの場合は、以下のメッセージ タイプのコンフィグレーション 情報が表示されます。
表 16-16 メッセージのタイプのコンフィグレーション情報
[
なし ]、[
バイナリ ]、[
テキスト ]、[
MFL ]、または [
XML ] で示される要求メッセージのメッセージ タイプ。
[
なし ]、[
バイナリ ]、[
テキスト ]、[
MFL ]、または [
XML ] で示される応答メッセージのメッセージ タイプ。
このページには以下の転送コンフィグレーション 情報が表示されます。
表 16-17 転送コンフィグレーション情報
転送からすべてのヘッダ、定義に該当するヘッダのどちらを取り出すか。
転送プロトコルが [電子メール] の場合は、以下の 電子メール転送コンフィグレーション 情報が表示されます。
表 16-18 電子メール転送コンフィグレーション情報
ポーリング スイープあたりの読み込みメッセージ最大数。無制限の場合は「
0」を指定する。
ファイルをアーカイブ ディレクトリにステージングして、ヘッダに参照として渡すかどうか。
メッセージの読み込み後に、アーカイブ化、削除、移動のどの動作を実行するか。
[アーカイブ] - メッセージがアーカイブ化される。
[削除] - メッセージが削除される。
[移動] - メッセージが移動される。
注意 :
[移動] は、IMAP プロトコルでのみ使用可能。
[アーカイブ] - 添付ファイルがアーカイブ ディレクトリに保存される。
[無視] - 添付ファイルが無視される。
[
読み込み後のアクション ] フィールドで [
移動 ] を選択した場合に使用されるメッセージの移動先フォルダ。
電子メールのダウンロードに使用される一時的な保存先。
[
読み込み後のアクション ] フィールドで [
アーカイブ ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[
アーカイブ ディレクトリ ] フィールドは、[
参照として渡す ] フィールドを選択した場合も必須。
問題が生じた場合にメッセージと添付ファイルが書き込まれるファイル システム ディレクトリへのパス。
電子メール転送の要求用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1。
転送プロトコルがファイルの場合は、以下のファイル転送コンフィグレーション 情報が表示されます。
表 16-19 ファイル転送コンフィグレーション情報
ポーリング スイープあたりの読み込みメッセージの最大数。無制限の場合は「
0」を指定する
。
すべてのディレクトリを再帰的にスキャンするかどうか。
ファイルをアーカイブ ディレクトリにステージングして、ヘッダに参照として渡すかどうか。
処理時にリモート サーバから ftp ファイルを直接ストリーミングするかどうか。
メッセージの読み込み後に、アーカイブ化または削除するかどうか。
[アーカイブ] - メッセージがアーカイブ化される。
[削除] - メッセージが削除される。
ファイルの処理中に一時的にファイルをステージングする中間ディレクトリ。
問題が生じた場合にメッセージと添付ファイルが書き込まれるファイル システム ディレクトリへのパス。
[
読み込み後のアクション ] フィールドで [
アーカイブ ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[
アーカイブ ディレクトリ ] フィールドは、[
参照として渡す ] フィールドを選択した場合も必須。
ファイル転送の要求用文字セット エンコーディングが表示される。デフォルト値は
utf-8。
転送プロトコルが [FTP] の場合は、以下の FTP 転送コンフィグレーション 情報が表示されます。
表 16-20 FTP 転送コンフィグレーション情報
匿名ユーザのメール ID または外部的にコンフィグレーションされたユーザのサービス アカウント。
すべてのディレクトリを再帰的にスキャンするかどうか。
ファイルをアーカイブ ディレクトリにステージングして、ヘッダに参照として渡すかどうか。
メッセージの読み込み後に、アーカイブ化または削除するかどうか。
[アーカイブ] - メッセージがアーカイブ化される。
[削除] - メッセージが削除される。
[
読み込み後のアクション ] フィールドで [
アーカイブ ] を選択した場合に使用されるメッセージのアーカイブ場所へのパス。[
アーカイブ ディレクトリ ] フィールドは、[
参照として渡す ] フィールドを選択した場合も必須。
FTP ファイルのダウンロードに使用される一時的な保存場所。
問題が生じた場合にメッセージと添付ファイルが書き込まれるファイル システム ディレクトリへのパス。
ポーリング スイープあたりの読み込みメッセージの最大数。無制限の場合は「
0」を指定する
。
転送モード : [Binary] または [ASCII]。
FTP 転送の要求用文字セット エンコーディングが表示される。デフォルト値は
utf-8。
転送プロトコルが HTTP の場合は、以下の HTTP 転送コンフィグレーション 情報が表示されます。
表 16-21 HTTPS 転送コンフィグレーション情報
クライアント認証方式 : [なし]、[基本]、または [カスタム認証]
HTTP 転送の要求用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1。
HTTP 転送の応答用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1。
転送プロトコルが HTTPS の場合は、以下の HTTPS 転送コンフィグレーション 情報が表示されます。
表 16-22 HTTPS 転送コンフィグレーション情報
クライアント認証方式 : [なし]、[基本]、[クライアント証明書]、または [カスタム認証]
HTTPS 転送の要求用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1。
HTTPS 転送の応答用文字セット エンコーディングが表示される。デフォルトは、
iso-8859-1。
転送プロトコルが JMS の場合は、以下の JMS 転送コンフィグレーション 情報が表示されます。
表 16-23 JMS 転送コンフィグレーション情報
送り先のタイプ : [キュー] または [トピック]。
JMSCorrelationID
JMSMessageID
JMSCorrelationID の応答 URI。
MessageID の応答接続ファクトリ URI。
JMS 転送の要求用文字セット エンコーディング。デフォルト値は
utf-8。
JMS 転送の応答用文字セット エンコーディング。デフォルト値は
utf-8。
タイムアウトまでクライアント応答を待つ時間 (秒)。
メッセージがエラー送り先に送信されるまでの再試行回数としてコンフィグレーションされた数。
有効期限の経過したメッセージが送り先で検出されたときに使用する有効期限ポリシー。
JMS サーバによって管理される JMS リソースに使用するサービス アカウント。
転送プロトコルが Tuxedo の場合は、以下の Tuxedo 転送コンフィグレーション 情報が表示されます。
表 16-24 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 転送の要求用文字セット エンコーディング。
Tuxedo 転送の応答用文字セット エンコーディング。
FML または FML32 バッファが XML に変換される際の要素の順序またはグループ化。
このページには以下のメッセージ レベルのセキュリティ コンフィグレーション 情報が表示されます。
表 16-25 メッセージ レベルのセキュリティ コンフィグレーション情報
クライアント メッセージレベル認証方式 : [
なし ]、[
カスタム ユーザ名とパスワード ]、または [
カスタム トークン ]
プロキシ サービスがアクティブな仲介として動作するかどうかを示す。
このページには以下の操作選択コンフィグレーション 情報が表示されます。
表 16-26 操作選択コンフィグレーション情報
SOAP 1.1 サービスのみ : このオプションを選択してサービスが 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 ] の下にある [アクティブ化 ] をクリックします。セッションが終了し、コア コンフィグレーションが更新されます。または、セッション中の任意の時点で [破棄 ] をクリックして、現在のセッションでそれまでに行った変更内容を削除します。
関連トピック
プロキシ サービスの追加
プロキシ サービスの表示と変更
メッセージ フローの表示と変更