AquaLogic Service Bus Console の使い方
|
 |
 |
|
この節では、BEA AquaLogic Service Bus メッセージ コンテキスト モデルと特に AquaLogic Service Bus メッセージ フローで使用する事前定義されたコンテキスト変数について説明します。内容は以下のとおりです。
BEA AquaLogic Service Bus メッセージ コンテキストは、メッセージが AquaLogic Service Bus を介してルーティングされるときにメッセージ コンテキストとメッセージに関する情報を保持する一連のプロパティです。これらのプロパティはコンテキスト変数と呼ばれ、たとえば、サービス エンドポイントに関する情報は事前定義されたコンテキスト変数によって表されます。AquaLogic Service Bus は、ユーザ定義のコンテキスト変数もサポートします。
メッセージ コンテキストは、XML スキーマで定義されます。通常は、XQuery 式を使用して、プロキシ サービスを定義するメッセージ フローのコンテキスト変数を操作します。
以下の表は、事前定義されたコンテキスト変数について説明しています。事前定義されたコンテキスト変数の型は、メッセージ関連の変数、inbound および outbound 変数、operation 変数、fault 変数に分けられます。
メッセージ コンテキスト変数の要素の型については、「メッセージ コンテキスト スキーマ」を参照してください。
表 A-1 AquaLogic Service Bus で事前定義されたコンテキスト変数
|
| ||
|---|---|---|
|
|
||
メッセージ関連の変数である header、body、attachments は、AquaLogic Service Bus を介して送信されるメッセージの標準書式を表します。これらの変数は、プロキシ サービスが受信したメッセージ コンテンツを使用して初期化され、他のサービスにルーティングまたはパブリッシュされる送信メッセージを作成するために使用されます。
メッセージの処理の一部としてメッセージを変更するには、これらの変数を変更する必要があります。
メッセージ ペイロード (つまり、ヘッダや添付ファイルを除くメッセージ コンテンツ) は、body 変数に格納されます。送信メッセージにどの変数のコンテンツを含めるかについては、メッセージが AquaLogic Service Bus から送信 (パブリッシュまたはルーティング) されるときに決定されます。この決定は、ターゲット エンドポイントが SOAP メッセージを受信するか非 SOAP メッセージを受信するかによって異なります。
header 変数と body 変数が SOAP エンベロープで結合され、メッセージが作成される。body 変数の Body 要素のコンテンツによってメッセージ全体が構成される。 attachments 変数から MIME パッケージが作成される。header 変数には、メッセージに関連付けられている SOAP ヘッダが格納されます。header 変数は、下位要素にヘッダを含む <SOAP:Header> 要素を参照します。非 SOAP メッセージまたはヘッダがない SOAP メッセージの場合、<SOAP:Header> 要素は空になり、下位要素を持ちません。
body 変数はコアのメッセージ ペイロードを表し、常に <SOAP:Body> 要素を参照します。SOAP メッセージでも非 SOAP メッセージでも、コアのペイロードは同じ変数とパッケージで使用できます。つまり、<SOAP:Body> 要素でラッピングされます。
body 変数に割り当てられる。 <SOAP:Body> 要素内にメッセージ コンテンツ全体が挿入される。body 変数に挿入されるのではなく、<binary-content/> 参照要素が作成され、<SOAP:Body> 要素に挿入される。バイナリ コンテンツの処理方法については、「body 変数と attachments 変数内のバイナリ コンテンツ」を参照してください。attachments 変数には、メッセージに関連する添付ファイルが格納されます。attachments 変数は、XML スキーマで定義されます。これは、単一のルート ノードである <ctx:attachments> と、添付ファイルごとに 1 つの <ctx:attachment> 下位要素で構成されます。この下位要素には、添付ファイルに関する情報 (MIME ヘッダから派生) と添付コンテンツが含まれます。他のメッセージ関連の変数と同様に、attachments は常に設定されます。ただし、添付ファイルがない場合は、attachments 変数は空の <ctx:attachments> 要素で構成されます。
各添付要素には、以下の表で示された一連の下位要素が含まれます。
型なしの body 要素以外のすべての要素には MIME での解釈と同じ方法で解釈された文字列値が含まれます。たとえば、Content-Type 要素の有効な値は、text/xml と text/xml; charset=utf-8 などです。
添付ファイルの解析は再帰的ではありません。添付ファイルの Content-Type が multipart/... の場合、body 要素には元の MIME コンテンツがパッケージ化されずにバイトのストリームとして保持され、添付ファイルの下位要素は含まれません。MIME ストリームにはバイナリ データが含まれることがあり、その場合このストリームは <binary-content> 参照要素で表します。
バイナリ コンテンツの処理方法については、「body 変数と attachments 変数内のバイナリ コンテンツ」を参照してください。
body 変数と attachments 変数では、テキスト ベース、XML ベース、および MFL ベースのコンテンツが XML 要素内に直接挿入されます。バイナリ データの場合、XML で使用できないバイト値が含まれることがあるため、AquaLogic Service Bus ではバイナリ コンテンツは XML 要素内に挿入されません。したがって、バイナリ コンテンツを操作することはできませんが、処理は効率的です。
バイナリ コンテンツが受信されると、AquaLogic Service Bus ランタイムによってバイナリ コンテンツがメモリ内ハッシュ テーブルに格納され、そのコンテンツへの参照が XML (body または attachments) 要素に挿入されます。この参照は、以下の XML コードで表されます。
この ref 属性に、バイナリ コンテンツをユニークに識別する URI または URN を指定します。この XML は、AquaLogic Service Bus パイプライン、ブランチ、またはルート ノードで他のコンテンツと同様に操作できます。ただし、影響を受けるのは、元のバイナリ コンテンツではなく参照だけです。
body 変数のバイナリ コンテンツを添付ファイルにコピーするには、参照 XML を添付要素の body 下位要素にコピーする。 メッセージが AquaLogic Service Bus から送信されると、参照 XML の URI を使用して、関連バイナリ コンテンツが送信メッセージ内に復元されます。発信メッセージの作成方法については、「送信するメッセージの作成」を参照してください。
クライアントと特定の転送 (特に、電子メール、ファイル、FTP) では、この同じ参照 XML を使用して参照渡しを実装できます。この場合、実行時のプロキシ サービスではなく転送またはクライアントによって、参照 XML が作成されます。また、ref 属性内の URI の値は、参照 XML を作成するユーザによって指定されます。参照 XML が実行時のプロキシ サービスによって作成されない場合 (特に、URI の参照先が、内部で管理されているバイナリ コンテンツであると認識されない場合)、URI は AquaLogic Service Bus により逆参照されず、送信メッセージにコンテンツが挿入されません。
inbound コンテキスト変数と outbound コンテキスト変数には、着信エンドポイントと発信エンドポイントに関する情報が格納されます。inbound 変数 ($inbound) には要求メッセージを受信したプロキシ サービスに関する情報が格納され、outbound 変数 ($outbound) にはメッセージの送信先であるターゲット ビジネス サービスに関する情報が格納されます。
outbound 変数は、ルート ノードのルート アクションとパブリッシュ アクションで設定されます。ルーティング ノードで設定した要求アクションとパブリッシュ アクションで (さらに、ルーティング ノードの応答アクションでも) $outbound を変更できます。
警告 : inbound コンテキスト変数と outbound コンテキスト変数に対して行った変更の一部は、実行時には無視されます。つまり、特定のヘッダとメタデータの値は、上書きされる場合や、AquaLogic Service Bus ランタイムで無視される場合があります。転送ヘッダとサービス コールアウト アクションを使用して転送ヘッダおよびメタデータを設定する場合、およびテスト コンソールを使用してプロキシ サービスまたはビジネス サービスをテストする場合、同じ制限が適用されます。制限のあるヘッダおよびメタデータの詳細については、「テスト コンソールでのランタイムによる転送設定の使用方法」を参照してください。メッセージ フローで、ルーティング ノードの要求または応答アクションとパブリッシュ アクション以外で $outbound に行った変更は無視されます。つまり、これらの変更は、ルーティング ノードとパブリッシュ アクションで $outbound が初期化されるときに上書きされます。
outbound 変数はサービス コールアウト アクションで変更できません。
inbound 変数と outbound 変数の特性は以下のとおりです。
inbound コンテキスト変数と outbound コンテキスト変数は、「メッセージ コンテキスト スキーマ」で説明されているように endpoint 要素のインスタンスです。name 属性を含む。name 属性は、inbound、outbound いずれの場合も読み込み専用として扱う必要があります。service、transport、security を含む。この節では、コンテキスト変数 inbound および outbound の下位要素について説明します。また、どの下位要素が実行時に初期化されるかについての情報も示します。コンテキスト変数が初期化される方法については、「コンテキスト変数の初期化」を参照してください。以下の下位要素があります。
service 要素は、inbound、outbound いずれの場合も読み込み専用です。下位要素としては providerName、operation があります。
|
|
|
|
|
transport 要素は inbound の場合は読み込み専用です。ただし例外として、response 要素ではこの要素を変更して応答転送ヘッダを設定できます。transport 要素の下位要素を次の表に示します。
|
| |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|---|---|
|
|
|
|
|
|
|
|
標準 HTTP ヘッダの詳細については、http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html を参照してください。
標準 JMS ヘッダの説明については、http://edocs.beasys.co.jp/e-docs/wls/docs91/jms/fund.html#jms_features を参照してください。
operation 変数は、読み込み専用の変数です。この変数には、プロキシ サービスで呼び出される操作を指定する文字列が格納されます。プロキシ サービスに対する処理が定義されていない場合は、operation 変数が設定されず、null と等価の値が返されます。
AquaLogic Service Bus では、パフォーマンスを最適化するために operation 変数が inbound 変数の下位要素ではなくスタンドアロン変数として提供されます。処理の計算は、inbound 変数がアクセスされたときではなく、operation 変数が明示的にアクセスされるまで延期されることがあります。
fault 変数は、メッセージ処理中に発生したすべてのエラーに関する情報を保持するために使用します。エラーが発生すると、この変数に情報が格納されてから、適切なエラー ハンドラが呼び出されます。
注意 : この変数はエラー ハンドラ パイプラインでのみ定義され、要求パイプラインや応答パイプライン、ルート ノードやブランチ ノードでは設定されません。
fault 変数には、以下の表に示された下位要素 errorCode、reason、details、および location が含まれます。
|
|
|
|---|---|
|
|
fault 変数のコンテンツは、SOAP ベースのプロキシ サービスからの返信時にエラーを生成しやすいよう、SOAP エラーに基づいてモデル化されています。AquaLogic Service Bus によって生成されるエラー コードの値はシステム エラー コードに対応し、エラー コードの先頭には BEA という文字列が付加されます。
エラーに関連付けられたエラー コードは、fault コンテキスト変数の要素内に表示されます。次の XQuery ステートメントを使用して値にアクセスできます。
AquaLogic Service Bus は、考えられる 3 つのクラスのエラー用に 3 つの汎用エラー コードを定義します。汎用コードの形式は BEA-xxx000 です。ここで、xxx は汎用カテゴリを次のように表します。
AquaLogic Service Bus では、特定のエラーを示すユニークなコードが定義されています。次に例を示します。
BEA-382030 - メッセージ解析エラーを示します (SOAP プロキシ サービスが非 SOAP メッセージを受信したなど)。
BEA-382500 - サービス コールアウト アクションが SOAP エラー応答を受け取った場合のために予約されています。
これらのエラー コードおよびその他の特定のエラー コードについては、「エラー コード」を参照してください。
メッセージ コンテキストとその変数は、メッセージ受信時およびメッセージ処理の開始前にバインディング レイヤで初期化されます。以下の表は、コンテキスト変数の初期化方法についてまとめたものです。
|
|
|
|
|
|
|
|
|
attachments コンテキスト変数は、メッセージに含まれるすべての MIME 添付ファイルで初期化されますが、メイン メッセージを表す部分は含まれません (SOAP、XML、MFL など形式を問わず)。各 <attachment> 要素は、MIME パッケージの各部分に伴う MIME ヘッダを使用して初期化されます。
<attachment> の <body> 要素のコンテンツは、添付ファイルの Content-Type に応じて以下のいずれかになります。
この節では、コンテキスト変数 header および body の初期化が行われる方法について説明します。これらの変数の初期化方法は、プロキシ サービスのタイプが SOAP サービス、XML サービス (非 SOAP)、メッセージング サービスのいずれであるかによって異なります。
SOAP ベースのサービスへのメッセージは、<soap:Envelope> 要素に含まれる XML を含む SOAP メッセージです。添付ファイルを含むメッセージの場合、着信メッセージのコンテンツは、SOAP エンベロープをその一部として (通常は最初の部分、または最上位の Content-Type ヘッダで指定される部分) 含む MIME パッケージです。コンテキスト変数は以下のように初期化されます。
XML ベースのサービスへのメッセージは XML ですが、プロキシ サービス コンフィグレーションで許可された型を使用できます。添付ファイルを含むメッセージの場合、着信メッセージのコンテンツは、プライマリ XML ペイロードをその一部として (通常は最初の部分、または最上位の Content-Type ヘッダで指定される部分) 含む MIME パッケージです。
メッセージング サービスは、あるデータ型のメッセージを受信し、応答として別のデータ型のメッセージを返すことができるサービスです。サポートされるデータ型は、XML、MFL、テキスト、または型なしバイナリです。コンテキスト変数は以下のように初期化されます。
header - 空の <soap:Header/> 要素で初期化されます。body - ペイロード全体をラッピングする <soap:Body> 要素で初期化されます。 <soap:Body> 要素内に直接挿入される。 <soap:Body> 要素内に挿入される (「body 変数と attachments 変数内のバイナリ コンテンツ」を参照)。バイナリ コンテンツに対してアクセスまたは変更を行うことはできませんが、参照 XML を検証および変更し、インライン コンテンツと置き換えることができます。
メッセージ コンテキストに対する対話および操作は、プロキシ サービスを定義するパイプライン、ブランチ、またはルート ノードでのアクションを通じて行います。ほとんどのアクションについては、それを実行するための XQuery 言語がエクスポーズされています。各コンテキスト変数は、同じ名前の XQuery 変数として表されます。たとえば、header 変数は、XQuery では $header としてアクセスでき、body 変数は $body としてアクセスできます。この節の例では、XQuery を使用してコンテキスト変数に対するチェックおよび操作を行っています。
$body 変数は <soap-env:Body>...</soap-env:Body> 要素を含みます。
たとえば、割り当てアクションを使用して body コンテキスト変数にデータを割り当てる場合、そのデータを <soap-env:Body> 要素でラッピングする必要があります。つまり、コンテキスト変数内に <soap-env:Body> 要素を含ませることで、SOAP パッケージを構築します。
ただし、AquaLogic Service Bus のこの動作は、サービス コールアウト アクションの要求ドキュメント変数を構築する場合は例外です。サービス コールアウト アクションはコアのペイロード (RPC パラメータ、ドキュメントなど) を作業対象とし、AquaLogic Service Bus は、コアのペイロードに基づいて SOAP パッケージを構築します。つまり、サービス コールアウト アクションの要求ドキュメント変数をコンフィグレーションする場合は、入力ドキュメントを <soap-env:Body>...</soap-env:Body> でラッピングしません。
サービス コールアウト アクションのコンフィグレーションの詳細については、「サービス コールアウト」を参照してください。
$header 変数は <soap-env:Header>...</soap-env:Header> 要素を含みます。
たとえば、割り当てアクションを使用してヘッダ コンテキスト変数にデータを割り当てる場合、そのデータを <soap-env:Header> 要素でラッピングする必要があります。つまり、コンテキスト変数内に <soap-env:Header> 要素を挿入して、SOAP パッケージを構築します。これは、サービス コールアウト要求の 1 つまたは複数の SOAP ヘッダを設定できる場合を含めて、すべての $header 操作に当てはまります。サービス コールアウト アクションの SOAP ヘッダのコンフィグレーションの詳細については、「サービス コールアウト」を参照してください。
コード リスト A-1 WS-Addressing ヘッダ (From) を抽出する
$header/wsa:From
コード リスト A-2 非 SOAP メッセージからペイロードを抽出する
$body/*
コード リスト A-3 発信応答メッセージからユーザヘッダを抽出する
$outbound/ctx:transport/ctx:response/tp:user-header[@name='myheader']/@value
SOAP サービスへのサービス コールアウト内の要求パラメータに使用される body 入力変数を作成する場合、ラッパー soap-env:Body を削除するため、body/* を使用します ($body を使用すると soap-env:Body ラッパーが保持されます)。
コード リスト A-4 サービス コールアウト内の要求パラメータの変数コンテンツを割り当てる
$body/*
AquaLogic Service Bus Console の XQuery エディタおよび XPath エディタによるコンテキスト変数の処理の詳細については、以下のトピックを参照してください。
BEA AquaLogic Service Bus の『ユーザーズ ガイド』の「AquaLogic Service Bus でのメッセージ フローの作成」にある「変数の構造」
AquaLogic Service Bus によってメッセージがパブリッシュまたはルーティングされるとき、メッセージのコンテンツはメッセージ コンテキストの変数の値を使用して作成されます。たとえば、転送ヘッダと転送固有のメタデータは、$outbound/transport/request から取得されます。コンテキストの初期化と同様に、発信メッセージのメッセージ コンテンツはターゲット サービスのタイプに応じて異なって処理されます。以下のトピックで説明されているように、発信メッセージ コンテンツの作成方法はターゲット サービスのタイプによって異なります。
送信 SOAP メッセージは、header 変数と body 変数のコンテンツを <soap:Envelope> 要素でラッピングして作成します。body 変数に参照 XML コードが格納されている場合、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。
attachments 変数で添付ファイルが定義されている場合は、メイン メッセージと添付データから MIME パッケージが作成されます。各添付部分のコンテンツの処理方法は、メッセージング サービスのコンテンツの処理方法に類似しています。
AquaLogic Service Bus の XML ベースのサービスへのメッセージは、body 変数のコンテンツから作成されます。
body 変数が空の場合は、サイズがゼロのメッセージが送信される。 body 変数に複数の XML コードが含まれる場合は、最初のコードのみが発信メッセージで使用される。たとえば、<soap:Body> に <abc/><xyz/> が含まれる場合は、<abc/> のみが送信されます。 body 変数のコンテンツが XML ではなくテキストである場合は、エラーが発生する。 body 変数に参照 XML コードが格納されている場合、メッセージは現状のまま送信される。つまり、参照されているコンテンツはメッセージに追加されません。 attachments 変数で添付ファイルが定義されている場合は、XML メッセージと添付データから MIME パッケージが作成される。XML メッセージが null の場合は、対応する MIME 本文部分は空になります。各添付部分のコンテンツの処理方法は、メッセージング サービスのコンテンツの処理方法に類似しています。含まれているデータの種類によらず、header 変数は発信メッセージにコンテンツを提供しません。
サービス コールアウト アクションのメッセージの作成方法を示す例については、「サービス コールアウト」を参照してください。
AquaLogic Service Bus のメッセージング サービスへのメッセージは、body 変数のコンテンツから作成されます。
body 変数が空の場合、サイズがゼロのメッセージが送信される。 body 変数のコンテンツがテキストとして解釈され送信される。このため、AquaLogic Service Bus では、ターゲット サービスにテキストとして配信する必要がある着信 XML メッセージを処理できます。つまり、このようなメッセージを処理するためにメッセージ フローをコンフィグレーションする必要はありません。body 変数に参照 XML コードを格納する必要がある。参照 URI は、AquaLogic Service Bus のメモリ内ハッシュ テーブルに格納されたバイナリ データを参照します。参照されたコンテンツは、ターゲット サービスに送信されます。 クライアント、転送、またはプロキシ サービスの設計者によって参照 URI が指定される場合、参照されるデータは AquaLogic Service Bus に格納されないため、発信メッセージに含めることはできません。したがって、参照 XML がメッセージで送信されます。
body 変数に参照 XML コードが含まれ、ターゲット サービスでバイナリ以外のメッセージが要求される場合は、body 変数内の参照 XML はコンテンツとして処理されます。つまり、メッセージは XML として送信されるか、テキストに変換されるか、または MFL に変換されます。これは、参照 XML の URI に関係なく当てはまります。
含まれているデータの種類によらず、header 変数は発信メッセージにコンテンツを提供しません。
サービス コールアウト アクションのメッセージの作成方法を示す例については、「サービス コールアウト」を参照してください。
バイナリ メッセージの場合、AquaLogic Service Bus では body 変数にメッセージ コンテンツは挿入されません。代わりに、<binary-content/> 参照要素が作成され <SOAP:Body> 要素に挿入されます (「メッセージ関連の変数」を参照)。ただし、電子メール規格では、バイナリ コンテンツ タイプをメッセージの主要な部分として送信することがサポートされていません。テキストまたは XML のドキュメントと任意の添付ファイルを受信するメッセージング サービスに、電子メールでバイナリ メッセージを送信する場合は、以下の手順に従います。
送信メッセージのタイプが MFL の場合は、$body のコンテンツが、MFL トランスフォーメーションに基づいて XML からテキストまたはバイナリに変換されます。
$outbound で Content-Type (MFL メッセージでのデフォルトはバイナリ) を text/plain として設定できる。バイナリ コンテンツの処理方法の詳細については、「body 変数と attachments 変数内のバイナリ コンテンツ」を参照してください。
コード リスト A-5 には、メッセージ コンテキスト変数の型を指定するメッセージ コンテキスト スキーマ (MessageContext.xsd) が示されています。
メッセージ コンテキスト変数を使用して作業を行う場合は、MessageContext.xsd と AquaLogic Service Bus インストールの以下の場所にある JAR ファイルで利用できる転送固有スキーマを参照する必要があります。
BEA_HOME\weblogic91\servicebus\lib\sb-schemas.jar
ここで、BEA_HOME は AquaLogic Service Bus がインストールされたディレクトリを表します。sb-schemas.jar には以下のコンテキスト関連スキーマが含まれます。
EmailTransport.xsd)FileTransport.xsd)FTPTransport.xsd)HttpTransport.xsd)HttpsTransport.xsd)MessageContext.xsd)JmsTransport.xsd)ServiceBusReference.xsd)TransportCommon.xsd)コード リスト A-5 Message Context.xsd
<schema targetNamespace="http://www.bea.com/wli/sb/context"
xmlns:mc="http://www.bea.com/wli/sb/context"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!--============================================================== -->
<!-- コンテキスト変数 'fault' はこの要素のインスタンスです -->
<element name="fault" type="mc:FaultType"/>
<!-- コンテキスト変数 'inbound' と 'outbound' は、この要素のインスタンスです -->
<element name="endpoint" type="mc:EndpointType"/>
<!-- 'inbound' 変数と 'outbound' 変数内の 3 つの下位要素 -->
<element name="service" type="mc:ServiceType"/>
<element name="transport" type="mc:TransportType"/>
<element name="security" type="mc:SecurityType"/>
<!-- コンテキスト変数 'attachments' はこの要素のインスタンスです -->
<element name="attachments" type="mc:AttachmentsType"/>
<!-- 'attachments' 変数の各添付ファイルは、この要素のインスタンスによって表されます -->
<element name="attachment" type="mc:AttachmentType"/>
<!-- バイナリ ペイロードと参照渡しコンテンツを表すために使用する要素 -->
<element name="binary-content" type="mc:BinaryContentType"/>
<!-- =================================================================== -->
<!-- スキーマ タイプ -->
<complexType name="AttachmentsType">
<sequence>
<!-- 'attachments' 変数は、単なる一連の添付要素です -->
<element ref="mc:attachment" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="AttachmentType">
<all>
<!-- 添付ファイルに関連付けられた一連の MIME ヘッダ -->
<element name="Content-ID" type="string" minOccurs="0"/>
<element name="Content-Type" type="string" minOccurs="0"/>
<element name="Content-Transfer-Encoding" type="string" minOccurs="0"/>
<element name="Content-Description" type="string" minOccurs="0"/>
<element name="Content-Location" type="string" minOccurs="0"/>
<element name="Content-Disposition" type="string" minOccurs="0"/>
<!-- 添付コンテンツ自体をインラインで指定するか、または <binary-content/> として指定します -->
<element name="body" type="anyType"/>
</all>
</complexType>
<complexType name="BinaryContentType">
<!-- バイナリまたは参照渡しペイロードへの URI 参照 -->
<attribute name="ref" type="anyURI" use="required"/>
</complexType>
<!-- =================================================================== -->
<complexType name="EndpointType">
<all>
<!-- エンドポイントのサービス、転送、およびセキュリティの詳細を保持する下位要素 -->
<element ref="mc:service" minOccurs="0" />
<element ref="mc:transport" minOccurs="0" />
<element ref="mc:security" minOccurs="0" />
</all>
<!-- このエンドポイントによって表されるサービスの完全修飾名 -->
<attribute name="name" type="string" use="required"/>
</complexType>
<!-- =================================================================== -->
<complexType name="ServiceType">
<all>
<!-- サービス プロバイダの名前 -->
<element name="providerName" type="string" minOccurs="0"/>
<!-- 呼び出されるサービス処理 -->
<element name="operation" type="string" minOccurs="0"/>
</all>
</complexType>
<!-- =================================================================== -->
<complexType name="TransportType">
<all>
<!-- エンドポイントの URI -->
<element name="uri" type="anyURI" minOccurs="0" />
<!-- 要求および応答に関する転送固有のメタデータ (転送ヘッダを含む) -->
<element name="request" type="anyType" minOccurs="0"/>
<element name="response" type="anyType" minOccurs="0" />
<!-- 一方向 (要求のみ) または双方向 (要求/応答) の通信を指定します -->
<element name="mode" type="mc:ModeType" minOccurs="0" />
<!-- サービス品質を指定します -->
<element name="qualityOfService" type="mc:QoSType" minOccurs="0" />
<!-- 再試行の値 (発信のみ) -->
<element name="retryInterval" type="integer" minOccurs="0" />
<element name="retryCount" type="integer" minOccurs="0" />
</all>
</complexType>
<simpleType name="ModeType">
<restriction base="string">
<enumeration value="request"/>
<enumeration value="request-response"/>
</restriction>
</simpleType>
<simpleType name="QoSType">
<restriction base="string">
<enumeration value="best-effort"/>
<enumeration value="exactly-once"/>
</restriction>
</simpleType>
<!-- =================================================================== -->
<complexType name="SecurityType">
<all>
<!-- 転送レベルのクライアント情報 (着信のみ) -->
<element name="transportClient" type="mc:SubjectType" minOccurs="0"/>
<!-- メッセージレベルのクライアント情報 (着信のみ) -->
<element name="messageLevelClient" type="mc:SubjectType" minOccurs="0"/>
<!-- 発信 WSS 処理を無効にするために使用するブール型フラグ (発信のみ) -->
<element name="doOutboundWss" type="boolean" minOccurs="0"/>
</all>
</complexType>
<complexType name="SubjectType">
<all>
<!-- この転送レベルまたはメッセージ レベルのサブジェクトに関連付けられたユーザ名 -->
<element name="username" type="string"/>
</all>
</complexType>
<!-- =================================================================== -->
<complexType name="FaultType">
<all>
<!-- エラーを識別する短い文字列 (たとえば、BEA38229) -->
<element name="errorCode" type="string"/>
<!-- エラーの理由を説明するテキスト -->
<element name="reason" type="string" minOccurs="0" />
<!-- エラーに関する追加情報 -->
<element name="details" type="anyType" minOccurs="0" />
<!-- プロキシでエラーが発生した場所に関する情報 -->
<element name="location" type="mc:LocationType" minOccurs="0" />
</all>
</complexType>
<complexType name="LocationType">
<all>
<!-- エラーが発生したパイプライン/ブランチ/ルート ノードの名前 -->
<element name="node" type="string" minOccurs="0" />
<!-- エラーが発生したパイプラインの名前 (該当する場合) -->
<element name="pipeline" type="string" minOccurs="0" />
<!-- エラーが発生したステージの名前 (該当する場合) -->
<element name="stage" type="string" minOccurs="0" />
<!-- エラー ハンドラ内でエラーが発生したかどうかを示す -->
<element name="error-handler" type="boolean" minOccurs="0" />
</all>
</complexType>
<!-- エラーの <details> に追加されるスタック トレースをカプセル化する -->
<element name="stack-trace" type="string"/>
</schema>
|
|
|