ユーザーズ ガイド
|
 |
 |
|
BEA AquaLogic Service Bus におけるメッセージ フローは、プロキシ サービスの実装を定義します。この節では、AquaLogic Service Bus でメッセージ フローを作成するときのガイドラインを示します。AquaLogic Service Bus のコンフィグレーションは AquaLogic Service Bus Console で行います。AquaLogic Service Bus Console の詳細については、AquaLogic Service Bus Console のオンライン ヘルプを参照してください。
メッセージ フローは、プロキシ サービスの実装を定義します。パイプライン ペア、ルート、ブランチ、エコーのいずれかの種類のノードを 1 つまたは複数接続することによって、メッセージ フローを作成します。メッセージ フローの実装方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「メッセージ フローの表示と変更」を参照してください。
「パイプライン」は、プロキシ実装の基準となるコンポーネントです。パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージ シーケンスです。
要求パスと応答パスを作成するには、要求パイプラインと応答パイプラインをペアにして、「パイプライン ペア ノード」と呼ばれる単一のノードに編成します。パイプライン ペア ノードは、他の 2 種類のノードとともに、メッセージ フローを表す単一ツリー構造に編成されます。ブランチ ノードを使用すると、これらのパイプライン ペアを条件付きで実行して、ブランチ末尾のルート ノードで要求と応答のディスパッチを実行できます。フロー構造になっているため、設計時にメッセージ フローの明瞭な動作概要を把握することができ、ルートとブランチ条件の両方を、パイプライン ステージまたはルート ノード内部の見えない場所に配置するのではなく、全体的な設計に明示的に含めることができます。
メッセージ フローは、次の表に示す最上位コンポーネントのインスタンスを連鎖させた構造になっています。
|
|
|
|
|
|
|
|
|
|
|
以下の表に、一般的なメッセージ フローでのメッセージの流れを示します。
|
|
|
メッセージ フローのルートには任意の要素を使用できます。最も単純なメッセージ フロー設計の 1 つに、ルート ノードのみでフロー全体を表す方法があります。任意の 2 つの要素を連鎖できます。たとえば、間にブランチ ノードを置かずに、2 つのパイプライン ペア ノードを連鎖させることもできます。分岐を構成する場合、各ブランチを異なる要素で開始することができます。たとえば、1 つのブランチがルート ノードで終了し、もう 1 つのブランチにはパイプライン ペアが続き、さらにもう 1 つのブランチでは子孫を持たないようにできます。この最後の例のように子孫のないブランチは、すぐに応答処理が開始されます。ただし、一般的には、メッセージ フローの多くは次の 2 つの形式で使用されます。まず、非オペレーション サービスの場合のフローは、ルートに単一のパイプライン ペアがあり、それにルート ノードが続く形式が一般的です。また、オペレーション サービスの場合のフローは、ルートに単一のパイプライン ペアがあり、オペレーションに基づくブランチ ノードがそれに続く形式で、さらに各ブランチにはパイプライン ペアが 1 つあり、その後にルート ノードが続くのが一般的です。
通常、メッセージ フローは WSDL ベースのサービスで使用されるため、多くの場合オペレーション固有の処理が必要になります。AquaLogic Service Bus では、オペレーションに基づくブランチ ノードを手動でコンフィグレーションする必要はなく、オペレーションに基づいて自動的に分岐するようにコンフィグレーションされた、最小限のブランチ ノードが用意されています。
オペレーション ブランチ ノードの追加方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「オペレーション ブランチ ノードの追加」を参照してください。
この節では、トランスフォーメーション設計に関するガイドラインを示します。トランスフォーメーション マップには 2 つのデータ型の間のマッピングが記述されます。AquaLogic Service Bus は、XQuery および eXtensible Stylesheet Language Transformation (XSLT) 標準を使用したデータ マッピングに対応しています。XSLT マップは、XML から XML へのマッピングを記述するのに対して、XQuery マップでは、XML から XML、XML から非 XML、非 XML から XML へのマッピングを記述できます。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「XQuery トランスフォーメーション」および「XSL トランスフォーメーション」を参照してください。BEA XQuery Mapper を使用して XQuery を作成する方法については、BEA XQuery Mapper のオンライン ヘルプの「XQuery Mapper を使用したデータの変換」を参照してください。
トランスフォーメーションを実行する場所は、次の条件に応じて異なります。
変換前または変換後のメッセージ フォーマットが対象サービスに依存する場合、ルート アクションまたはパブリッシュ アクションでトランスフォーメーションを実行する必要があります。パブリッシュ アクションの場合、トランスフォーメーションは $outbound 変数およびメッセージ関連の変数 ($header、$body、および $attachments) のローカル コピーを保持します。パブリッシュ アクションで発信メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ アクションで行った変更は、メッセージ フローがその次のアクションに進む前にロールバックされます。
たとえば、大口の発注書を処理するときに、管理者宛てに発注書の要約を電子メールで送信する必要があるとします。このような場合、要求パイプラインにパブリッシュ アクションを含めることで、着信メッセージの SOAP 本体に含まれる発注書の主要部分を含む要約を作成します。パブリッシュ アクションで、発注書のデータが注文要約の形式に変換され、注文要約に含まれない $attachements のすべての添付が削除されます。
もう 1 つ例を挙げます。WS-Addressing ヘッダに基づく 2 つの送り先のうち、一方にメッセージをルーティングし、もう一方に対しては SOAP 本体のドキュメントを新しいバージョンに変換する必要があるとします。このような場合、条件に基づいて 2 つの送り先の一方にルーティングされるように、ルート ノードをコンフィグレーションします。もう一方の送り先に対して、ルート アクションでドキュメントを変換します。
発信コンテキスト変数 ($outbound) の制御要素を設定して、発信メッセージに関するシステムの動作を調整できます (たとえば、サービスの品質を設定できます)。inbound 変数および outbound 変数の下位要素について、およびメッセージのコンテンツを作成するのにメッセージ コンテキスト変数の値がどのように使われるかについては、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「inbound 変数と outbound 変数」および「送信するメッセージの作成」を参照してください。
ルートの送り先に関係なく、要求メッセージまたは応答メッセージに対してトランスフォーメーションを実行する場合、要求または応答パイプラインのステージにトランスフォーメーションをコンフィグレーションする必要があります。
パイプラインの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」の「メッセージ フローの概要」で「パイプライン」を参照してください。アクションの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「アクションの追加」を参照してください。また、ルート ノードの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「ルート ノードの追加」を参照してください。
この節では、オペレーション ブランチを使用する状況、および条件付きブランチが使用可能な状況について説明します。
複数のオペレーションを行うプロキシ サービスが Web Services Description Language (WSDL) に基づいている場合、オペレーション ブランチを使用してメッセージをオペレーションごとに個別に処理する必要があります。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「オペレーション ブランチの詳細の表示と変更」を参照してください。ただし、複数のドキュメント タイプを受信するプロキシ サービスが WSDL に基づいていない場合は、代わりに条件付きブランチ ノードを使用することを検討してください。
たとえば、プロキシ サービスのタイプが [任意の SOAP サービス] または [任意の XML サービス] で、条件付きブランチを実行するためにメッセージ タイプを判別する必要がある場合、ステージ アクションを使用してメッセージ タイプを識別し、フロー内で条件付きブランチ ノードを使用して受信したメッセージをタイプごとに個別に処理します。[任意の SOAP サービス] または [任意の XML サービス] の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「プロキシ サービスの追加」を参照してください。
また、条件付きブランチを使用して、フロー全体のビューでルーティングのオプションを明示できます。たとえば、ある条件に基づいてサービス A またはサービス B が呼び出される場合、ルート ノード内に条件付きブランチをコンフィグレーションする代わりに、メッセージ フロー自体にこのブランチを明示または強調表示して、各ブランチのサブフローとして単純なルート ノードを使用することができます。
メッセージ フロー、ステージ、またはルート ノードのどの場所にブランチをコンフィグレーションするかを決定する前に、ビジネス シナリオを検討してください。メッセージ フローにブランチをコンフィグレーションする場合、ブランチ ノードからさらに分岐してブランチの数が多くなると、設計インタフェースが煩雑になる可能性があることに注意してください。
詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「メッセージ フローの概要」を参照してください。
ほとんどの場合、1 つのパイプラインに 1 つのステージを使用するだけで十分ですが、複数のステージを使用する必要がある場合もあります。この節では、パイプラインで複数のステージを使用する場合とその理由について説明します。ステージのコンフィグレーションの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「ステージの追加」を参照してください。
ステージはアクションのコンテナです。アクションで以下の任意のタスクを実行できます。
WSCallout を使用してルックアップを実行し、メッセージに情報を追加したりルーティングの決定を容易にしたりする。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「アクションの追加」の Web サービス コールアウト アクションの説明を参照してください。複数のステージを設計するか、複数のアクションを持つ単一のステージをコンフィグレーションするかを決定する際には、ステージに関する以下の特徴を考慮します。
詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「ステージの追加」および「ステージ コンフィグレーションの詳細の表示と変更」を参照してください。
この節では、エラーの処理方法の概要について説明し、エラー処理オプションをコンフィグレーションするときのガイドラインを示します。エラー メッセージとその処理の詳細な説明については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「エラー メッセージと処理」を参照してください。
メッセージ処理中に発生したエラーに関する情報はすべて、事前定義されたコンテキスト変数 (fault 変数) に保持されます。エラーが発生すると、この変数に情報が格納されてから、適切なエラー ハンドラが呼び出されます。この fault 変数はエラー ハンドラ パイプラインでのみ定義され、要求パイプラインや応答パイプライン、ルート ノードやブランチ ノードでは設定されません。$fault の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「事前定義されたコンテキスト変数」を参照してください。
通常、メッセージ フローの最下位レベルで特定のエラーを処理し、下位レベルでは処理されないエラーのデフォルト処理を上位レベルで行うほうが簡単です。予期されるエラーをパイプラインで明示的に処理し、予期されないエラーをサービスレベルのハンドラで処理することをお勧めします。ただし、予期されるエラーをパイプラインで処理する場合、サービス レベルで処理できるのは WS-Security 関連のエラーのみです。
要求/応答型の着信メッセージで発生するエラーについては、多くの場合、エラーが発生した理由を説明するメッセージを生成して送信元に送り返す必要があります。そのためには、送信する応答に対してメッセージ コンテキスト変数をコンフィグレーションした後、失敗時の返信アクションを使用します。たとえば、HTTP メッセージが失敗した場合は、失敗時の返信アクションで HTTP 500 ステータスが生成されます。JMS メッセージが失敗した場合は、失敗時の返信アクションで JMS_BEA_Error プロパティが true に設定されます。AquaLogic Service Bus のエラー アクションの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「エラー メッセージと処理」を参照してください。
プロキシ サービスが呼び出したサービスが SOAP エラーまたは転送エラーを返すと、エラー処理パイプラインが呼び出されます。受信した SOAP エラーはすべて $body に格納されるため、$body を変更せずに失敗時の返信アクションを実行すると、サービスの呼び出し元のクライアントには元の SOAP エラーが返されます。返信アクションがコンフィグレーションされていない場合、システム エラー ハンドラによって新しい SOAP エラー メッセージが生成されます。プロキシ サービスでは、HTTP エラー ステータスが設定されたか、JMS プロパティ JMS_BEA_Error が true に設定されているために SOAP エラーが返されたと認識されます。
用途によっては、エラー レポートが必要な場合があります。このような場合は、レポート アクションを使用します。たとえば、要求パイプラインで追跡用にメッセージをレポートするレポート アクションを実行した後、ルート ノードによって呼び出されたサービスが失敗するというシナリオを想定します。このような場合、メッセージはレポート システムによってログに記録されますが、メッセージが正常に処理されたという保証はありません。メッセージが正常に受信されたことを示すだけです。
AquaLogic Service Bus Console では、メッセージを追跡することによって、メッセージ フローの正確な流れを把握することができます。したがって、元のレポート メッセージで、メッセージが処理用に送信されたことを確認でき、後続のエラー レポートで、メッセージが正常に処理されなかったことを確認できます。
詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「エラー メッセージと処理」を参照してください。
AquaLogic Service Bus は、従来の Web サービス (WSDL で XML または SOAP バインディングを使用) から非 XML サービスや汎用サービスまで、多くの種類のサービスに対応しています。この節では、サービスの種類を選択する際のガイドラインを示します。
AquaLogic Service Bus に含まれるサービスの種類は以下のとおりです。
<soap:Envelope> 要素内の body 変数のコンテンツをラップすることで作成されます。注意 : すべての種類のサービスで、MIME を使用した添付の送受信が可能です。
次の表に、AquaLogic Service Bus でサポートされるサービスの種類と転送方式を示します。
サービスに Web Services Description Language (WSDL) インタフェースが明確に定義されている場合、WSDL を使用してサービスを定義することをお勧めします。これは必須ではありません。WSDL の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「WSDL」を参照してください。
上記の場合に WSDL を使用するメリットは以下のとおりです。
soapaction ヘッダが自動的に作成される。<url>?WSDL 構文に対応しているため、HTTP プロキシ サービスの WSDL を動的に取得できる。この機能は、BEA WebLogic Workshop をはじめとする多くの SOAP クライアント生成ツールで有用です。$body のデフォルト マッピングが提供されるため、body コンテキスト変数 ($body) の操作が容易である。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」を参照してください。注意 : 特定のアクションにおける $body の実行時のコンテンツは、エディタに表示されるデフォルト マッピングと異なる場合があります。これは、AquaLogic Service Bus が型付きの変数を宣言して使用するプログラミング言語ではないためです。変数は型なしであり、値が割り当てられると実行時に動的に作成されます。また、変数の型は、メッセージ フローの任意の位置でコンテンツに基づく型になります。XQuery 式および XPath 式の作成を容易にするために、設計時エディタでは任意の変数に型をマッピングできます。
サービスの種類として WSDL を使用する場合、バインディングではなく、WSDL ポートにサービスをバインドするのが便利です。理由は次のとおりです。
<service-name>QSService および <port-name>QSPort)。テンプレート WSDL で定義されたどのポートも、生成される WSDL には含まれません。サービスの URL に?WSDL を追加したものをブラウザのアドレス フィールドに入力することで、HTTP(S) ベースのプロキシ サービスの WSDL を取得できます。
プロキシが WSDL のポートにバインドされていて、プロキシ サービスの URL が WSDL の URL に正確に反映されている場合、?WSDL 構文で生成される WSDL ではそのポート名が保持されます。これは、いくつかのクライアント ツールでは重要な事項です。サービスの定義時にビジネス サービスのデフォルト URL として WSDL ポートの URL を作成する場合を除いて、サービスにバインドされる WSDL ポートの URL は使用されません。サービス定義を行う際に、転送コンフィグレーション画面で転送方式と転送 URL を上書きできます。
ポート レベルのすべての WS-Security ポリシーに適用されます。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「プロキシ サービスの概要」を参照してください。
1 つのポートだけをエクスポーズしてクライアントにさまざまなエンタープライズ アプリケーションを提供する場合は、[任意の SOAP サービス] または [任意の XML サービス] を使用します。
要求または応答メッセージの 1 つが非 XML の場合、サービスの種類としてメッセージングを使用する必要があります。
AquaLogic Service Bus では、"mustunderstand" SOAP ヘッダのチェックは自動では行われません。ただし、XQuery 条件式および検証アクションを使用してこのようなチェックを明示的に行うことができます。検証アクションの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「アクションの追加」を参照してください。XQuery 条件式の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「XQuery 条件の編集」を参照してください。
AquaLogic Service Bus では、WSDL 定義であるかメッセージング インタフェース定義であるかにかかわらず、サービス インタフェース定義に対して送信または受信されたメッセージの検証は自動では行われません。ただし、メッセージ フローで検証アクションをコンフィグレーションして XQuery 条件式を使用することで、明示的に検証チェックを行うことができます。
サービスの種類の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「プロキシ サービスの概要」を参照してください。
プロキシ サービスの設計時に、呼び出す具象サービスがわからなくてもインタフェースの形式さえわかっていれば、応答メッセージで呼び出すサービスを直接的または間接的に指定できます。
注意 : サービスの形式は、具象インタフェースではなく、抽象インタフェース (メッセージの種類、ポートの種類、およびバインディング) を示します。具象インタフェースは、サービスが配置されている転送 URL です。
このような場合、正しい形式のビジネス サービスを登録します。転送 URL は任意です。サービス URL は、$outbound をコンフィグレーションすることで、呼び出すサービスの URL に置き換えることができます。つまり、URL は実行時に提供され、サービスを設計してコンフィグレーションするときにこの URL を知っている必要はありません。
メッセージ コンテキストは、メッセージが AquaLogic Service Bus を介してルーティングされるときにメッセージ コンテキストとメッセージに関する情報を保持する一連の変数です。header 変数、body 変数、および attachments 変数 (XQuery では$header、$body、$attachments) は、AquaLogic Service Bus を介して送受信されるメッセージを表します。メッセージの標準書式は SOAP です。サービスの種類が SOAP でなくても、メッセージはコンテキスト内で SOAP として表示されます。
$header には SOAP Header 要素が含まれ、$body には SOAP Body 要素が含まれます。$attachments には attachments と呼ばれるラッパー要素が含まれ、attachment ごとに 1 つの attachment 子要素を持ちます。attachment 要素には、body 要素と実際の添付が含まれます。
プロキシ サービスでメッセージを受信すると、メッセージのコンテンツを使用して header 変数、body 変数、および attachments 変数が初期化されます。SOAP サービスの場合、受信した SOAP メッセージのエンベロープから Header 要素および Body 要素が直接取得され、それぞれ $header および $body に割り当てられます。非 SOAP サービスの場合、通常はメッセージのコンテンツが Body 要素でラップされて $body に割り当てられ、空の Header 要素が $header に割り当てられます。
バイナリ メッセージと MFL メッセージは別の方法で初期化されます。MFL メッセージの場合、$body に割り当てられる Body 要素には、MFL と同等の XML ドキュメントが挿入されます。バイナリ メッセージの場合、メッセージ データは内部的に格納され、$body に割り当てられる Body 要素には参照 XML だけが挿入されます。参照 XML は <binary-content ref="..."/> のような形式になります。"..." には、プロキシによって割り当てられるユニークな識別子が入ります。
メッセージ コンテキストは、XML スキーマで定義されます。通常は、XQuery 式を使用して、プロキシ サービスを定義するメッセージ フローのコンテキスト変数を操作します。
AquaLogic Service Bus で事前定義されているコンテキスト変数は、以下のように分類されます。
事前定義されている変数の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「事前定義されたコンテキスト変数」を参照してください。
メッセージのペイロードは body 変数に含まれています。送信メッセージに含める変数のコンテンツは、メッセージが AquaLogic Service Bus からディスパッチされるときに決定されます。この決定は、対象のエンドポイントが SOAP メッセージを受信するか非 SOAP メッセージを受信するかによって異なります。
$body の Body 要素に任意のテキストまたは XML コンテンツが格納されて送信される。$body の Body 要素に MFL ドキュメントと同等の XML が格納される。 $body の Body 要素にテキストが格納される。テキスト添付では、$attachments の Body 要素にテキストが格納されます。コンテンツがシンプル テキストではなく XML の場合、XML はテキスト メッセージとして送信されます。$body の Body 要素に XML が格納される。XML 添付では、$attachments の Body 要素に XML が格納されます。<soap:Envelope> 要素内の body 変数のコンテンツをラップすることで作成される。body 変数に参照 XML が格納されていても、メッセージは現状のまま送信されます。つまり、参照されているコンテンツはメッセージに追加されません。非 SOAP サービスの場合、$body の Body 要素に binary-content 要素が格納されると、対象サービスの種類に関係なく、内部的に格納された参照先コンテンツが現状のまま送信されます。
詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」を参照してください。
メッセージ コンテキスト変数の型は、メッセージ コンテキスト スキーマ (MessageContext.xsd) によって定義されます。BEA XQuery Mapper でメッセージ コンテキスト変数を使用して作業を行う場合は、MessageContext.xsd と適切な転送固有スキーマを参照する必要があります。このスキーマは、AquaLogic Service Bus インストールの以下の場所の JAR ファイル内にあります。
BEA_HOME\weblogic90\servicebus\lib\sb-schemas.jar
ここで、BEA_HOME は AquaLogic Service Bus をインストールしたディレクトリを表します。
メッセージ コンテキスト スキーマおよび転送固有スキーマの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「メッセージ コンテキスト スキーマ」を参照してください。
コンテキストを変更する際には、以下のガイドラインを考慮してください。
Content-Description を取得します。$attachments/ctx:attachment[1]/ctx:Content-Description
idvar という変数に割り当てる場合、割り当てアクションを次のように指定します。変数 idvar に data($header/wsa:MessageID) を割り当てる
注意 : 上記の例で 2 つの WS-Addressing MessageID ヘッダが存在する場合、idvar 変数には最初の MessageID ヘッダの値が割り当てられます。
$header、$body、および $attachments が空になることはない。ただし、$header には空の SOAP Header 要素、$body には空の SOAP Body 要素、$attachments には空の attachments 要素がそれぞれ含まれる場合があります。$body/* [1] を使用して、トランスフォーメーションへの入力として、メッセージの Body 要素 ($body) にビジネス ドキュメントを渡すことができます。トランスフォーメーションの結果は、コンテンツ置換アクションを使用して $body に戻すことができます (Body 要素のコンテンツ、つまり$body のコンテンツを置換します)。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「XQuery トランスフォーメーション」および「XSL トランスフォーメーション」を参照してください。$inbound から $outbound に一連の転送ヘッダをコピーすることができます。アクションの追加については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「アクションの追加」を参照してください。使用例については、「JMS プロパティのコピー」を参照してください。AquaLogic Service Bus では、プロキシ サービスとそれによって呼び出されるビジネス サービスのインタフェースが異なると想定されています。そのため、inbound 変数から outbound 変数への情報 (転送ヘッダや JMS プロパティなど) の伝播は行われません。
プロキシ サービスの要求メッセージおよび応答メッセージの転送ヘッダは $inbound にあり、呼び出されるビジネス サービスの要求および応答の転送ヘッダは $outbound にあります。
たとえば、一方向メッセージ (応答を伴わない呼び出し) でユーザ定義の JMS プロパティが inbound から outbound にコピーされる必要がある場合、次の XQuery 式を使用します。
変数 outbound の ./ctx:transport/ctx:request/tp:headers の最初の子として $inbound/ctx:transport/ctx:request/tp:headers/tp:user-header を挿入する
AquaLogic Service Bus Console で挿入アクションおよび他のアクションをコンフィグレーションする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「アクションの追加」を参照してください。
AquaLogic Service Bus は、Remote Procedure Calls (RPC) 型 SOAP およびドキュメント型 SOAP に対応しています。詳細については、以下を参照してください。
プロキシ サービスは RPC 型プロキシとして、ビジネス サービスは RPC 型ビジネス サービスとしてそれぞれコンフィグレーション可能です。
次のコードリストに、RPC 型 Web サービスの WSDL の例を示します。
コードリスト 2-1 RPC 型 Web サービスの WSDL
<definitions name="Lookup" targetNamespace="http://example.com/lookup/service/defs" xmlns:tns="http://example.com/lookup/service/defs" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:docs="http://example.com/lookup/docs" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified">
<xs:complexType name="RequestDoc">
<xs:sequence>
<xs:element name="PurchaseOrg" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="ResponseDoc">
<xs:sequence>
<xs:element name="LegacyBoolean" type="xs:boolean"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</types>
<message name="lookupReq">
<part name="request" type="docs:RequestDoc"/>
</message>
<message name="lookupResp">
<part name="result" type="docs:ResponseDoc"/>
</message>
<portType name="LookupPortType">
<operation name="lookup">
<input message="tns:lookupReq"/>
<output message="tns:lookupResp"/>
</operation>
</portType>
<binding name="LookupBinding" type="tns:LookupPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="lookup">
<soap:operation/>
<input>
<soap:body use="literal" namespace="http://example.com/lookup/service"/>
</input>
<output>
<soap:body use="literal" namespace="http://example.com/lookup/service"/>
</output>
</operation>
</binding>
上記のサービスには lookup というオペレーション (java クラスのメソッドと同等) が含まれています。バインディングは、これが SOAP RPC Web サービスであることを示しています。つまり、この Web サービスのオペレーションは、一連の要求パラメータを受信して一連の応答パラメータを返します。この lookup オペレーションには、request というパラメータと result という戻りパラメータがあります。バインディングでのオペレーションのネームスペースは "http://example.com/lookup/service" です。
上記の WSDL を要求で使用した場合に、SOAP RPC プロキシによって取得される body 変数 ($body) の値を次のコードリストに示します。
注意 : 次のコードでは、わかりやすくするために XML からネームスペース定義が除外されています。
<soap-env:Body>
<ns:lookup>
<request>
<req:PurchaseOrg>BEA Systems</req:PurchaseOrg>
</request>
</ns:lookup>
上記の例では、soap-env は事前定義された SOAP ネームスペース、ns はオペレーションのネームスペース (<http://example.com/lookup/service>)、req は PurchaseOrg 要素のネームスペース (<http://example.com/lookup/docs>) です。
プロキシからルーティングされるビジネス サービスで上記の WSDL を使用した場合、上記の body 変数 ($body) はプロキシ サービスの body 変数 ($body) の値です。
上記の WSDL を要求で使用した場合にプロキシ サービスが受信する、呼び出されたビジネス サービスからの応答の body 変数 ($body) の値を、次のコードリストに示します。
<soap-env:Body>
<ns:lookupResponse>
<result>
<req:LegacyBoolean>true</req:LegacyBoolean>
</result>
</ns:lookupResponse>
これは、この WSDL を使用するプロキシ サービスによって返される応答の body 変数 ($body) の値でもあります。
BEA WebLogic Workshop ツールをはじめとする多くのツールでは、プロキシ サービスの WSDL (ブラウザで、プロキシの URL に ?WSDL サフィックスを追加することで取得可能) を受け取り、適切な要求パラメータと応答パラメータを持つ java クラスを生成して、サービスのオペレーションを呼び出します。この java クラスで、この WSDL を使用するプロキシ サービスを呼び出すことができます。
プロキシ サービスは SOAP 型プロキシとして、ビジネス サービスは SOAP 型ビジネス サービスとしてそれぞれコンフィグレーション可能です。
次のコードリストに、ドキュメント型 Web サービスの WSDL の例を示します。
コードリスト 2-4 ドキュメント型 Web サービスの WSDL
<definitions name="Lookup" targetNamespace="http://example.com/lookup/service/defs" xmlns:tns="http://example.com/lookup/service/defs" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:docs="http://example.com/lookup/docs" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<xs:schema targetNamespace="http://example.com/lookup/docs" elementFormDefault="qualified">
<xs:element name="PurchaseOrg" type="xs:string"/>
<xs:element name="LegacyBoolean" type="xs:boolean"/>
</xs:schema>
</types>
<message name="lookupReq">
<part name="request" element="docs:PurchaseOrg"/>
</message>
<message name="lookupResp">
<part name="result" element="docs:LegacyBoolean"/>
</message>
<portType name="LookupPortType">
<operation name="lookup">
<input message="tns:lookupReq"/>
<output message="tns:lookupResp"/>
</operation>
</portType>
<binding name="LookupBinding" type="tns:LookupPortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="lookup">
<soap:operation/>
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
このサービスには lookup というオペレーション (java クラスのメソッドと同等) が含まれています。バインディングは、これが SOAP ドキュメント型 Web サービスであることを示しています。
上記の WSDL を要求で使用した場合に、ドキュメント型プロキシによって取得される body 変数 ($body) の値を次のコードリストに示します。
<soap-env:Body>
<req:PurchaseOrg>BEA Systems</req:PurchaseOrg>
soap-env は事前定義された SOAP ネームスペース、req は PurchaseOrg 要素のネームスペース (<http://example.com/lookup/docs>) です。
プロキシからルーティングされるビジネス サービスで上記の WSDL を使用した場合、上記の body 変数 ($body) はプロキシ サービスの body 変数 ($body) の値になります。
プロキシ サービスが受信する、呼び出されたビジネス サービスからの応答の body 変数 ($body) の値を、次のコードリストに示します。
<soap-env:Body>
<req:LegacyBoolean>true</req:LegacyBoolean>
これは、この WSDL を使用するプロキシ サービスによって返される応答の body 変数 ($body) の値でもあります。
BEA WebLogic Workshop ツールをはじめとする多くのツールでは、プロキシ サービスの WSDL (ブラウザで、プロキシの URL に ?WSDL サフィックスを追加することで取得可能) を受け取り、適切な要求パラメータと応答パラメータを持つ java クラスを生成して、サービスのオペレーションを呼び出します。この java クラスで、この WSDL を使用するプロキシ サービスを呼び出すことができます。
この節では、サービスの品質に関する以下の問題について説明します。
AquaLogic Service Bus は、信頼性の高いメッセージ機能を備えています。プロキシ転送が JMS/XA である場合、メッセージがルート ノードから別のサービスにルーティングされるときのデフォルトのサービスの品質 (QoS) は exactly once になります。それ以外の場合は best-effort になります。exactly once では、発信メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージが着信から発信に 1 回だけ配信されます。exactly once の配信の信頼性は提案に過ぎず、必ず実現されるわけではありません。exactly once を指定すると、可能であれば exactly once の信頼性が提供されます。exactly once が不可能な場合は、at least once の配信セマンティクスが試行され、それでも不可能な場合は best effort の配信が実行されます。
at least once では、発信メッセージの送信が開始されるまでは終了エラーが発生しないことを前提として、メッセージが着信から発信に少なくとも 1 回配信されます。フェイルオーバ URL が指定されている場合は、少なくとも 1 つの URL について at least once のセマンティクスが提供されます。
best effort では、メッセージングの機能に信頼性はなく、重複するメッセージは除去されませんが、パフォーマンスが最適化されます。
サービス品質の属性をオーバーライドするには、発信メッセージのコンテキスト変数 ($outbound) に qualityOfService を設定する必要があります。詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「メッセージ コンテキスト スキーマ」を参照してください。
プロキシの着信が JMS/XA で、パブリッシュ アクションまたはルート アクションの発信転送が JMS/XA である場合、入力転送から出力転送へのメッセージ転送が「必ず 1 回 (exactly once)」だけ行われ、メッセージの消失または配信の重複が発生しないことが保証されます。その他の転送プロトコル (電子メール、FTP、ファイル、HTTP、HTTPS、JMS/非 XA) でプロキシの着信が JMS/XA である場合、入力転送から出力転送へのメッセージ転送が「1 回以上 (at least once)」行われ、メッセージの消失が発生しないことが保証されます。転送プロトコルの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「プロキシ サービスの追加」および「ビジネス サービスの追加」を参照してください。
配信の保証は、JMS 着信の再試行に基づきます。retrycount の値と、再試行回数が使い果たされたときの動作は、WebLogic Server Administration Console でコンフィグレーションできます (AquaLogic Service Bus Console ではコンフィグレーションできません)。デフォルトでは、AquaLogic Service Bus で作成されたキューの再試行回数は 1 で、再試行回数が使い果たされるとメッセージは破棄されます。AquaLogic Service Bus で作成されるデフォルトの JMS キューのリストについては、『BEA AquaLogic Service Bus デプロイメント ガイド』を参照してください。
HTTP(S) における at least once のメッセージ配信の保証について、以下に詳細を説明します。対象サービスがエラーまたは HTTP ステータスを伴う応答を返す場合でも、配信は完了したと想定されます。つまり、対象サービスが認証エラーや「ページが見つからない」エラーなどを返すような場合でも、サーバは利用可能であり、サービスによってメッセージが処理されたと見なされます。ただし、メッセージの転送時にプロキシ サーバまたは対象サーバがクラッシュするか、対象サーバが稼動していないか、応答がタイムアウトした場合、メッセージは再配信されます。
HTTP のような信頼性の低い転送方式を使用するビジネス サービスまたはプロキシ サービスをコンフィグレーションする必要がある場合に信頼性を高めるには、以下のガイドラインに従います。
JMS メッセージの着信の再試行をコンフィグレーションするだけでなく、発信の再試行およびロード バランシングもコンフィグレーションできます。ロード バランシング、フェイルオーバ、および再試行の組み合わせによって、パフォーマンスと高可用性を実現できます。各メッセージのフェイルオーバ URL として指定した URL のリストは、ロード バランシング アルゴリズムに基づいて自動的に並べ替えられ、フェイルオーバのシーケンスが形成されます。再試行回数が N の場合、シーケンス全体が N 回再試行されてから終了します。システムは指定された再試行間隔の時間だけ待機してから、シーケンスの次のループを開始します。再試行回数が完了してもまだエラーがある場合、ルート ノードのエラー処理パイプラインが呼び出されます。エラー処理パイプラインの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「パイプラインへのエラー処理の追加」を参照してください。
AquaLogic Service Bus では、HTTP(S) 転送方式の 200 または 202 以外の HTTP ステータスはエラーとして扱われ、再試行する必要があります。このアルゴリズムにより、AquaLogic Service Bus では、解決することのできない認証エラーなどのエラーを、その URL で一定期間再試行することが可能です。これに対して、AquaLogic Service Bus で任意のメッセージの送信を再試行するときに別の URL にフェイルオーバする場合は、新しい URL ではエラーにならない可能性があります。
AquaLogic Service Bus では、異種のエンドポイント間での相互運用性を確保するため、使用されるコンテンツ タイプ、JMS タイプ、およびエンコーディングをそれぞれ制御できます。
AquaLogic Service Bus では外部のクライアントまたはサービスに必要な情報は想定されず、サービス定義でコンフィグレーション済みの情報が使用されます。発信メッセージのコンテンツ タイプは、サービスの種類とインタフェースから派生します。コンテンツ タイプは、電子メールおよび HTTP(S) プロトコルの一部です。
サービスを呼び出すプロキシ サービスの発信コンテキスト変数 ($outbound) のコンテンツ タイプ、およびプロキシ サービス応答の着信コンテキスト変数 ($inbound) のコンテンツ タイプはオーバーライドできます。コンテキスト変数 $outbound および $inbound の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」を参照してください。
また、JMS タイプにはバイトまたはテキストを指定できます。AquaLogic Service Bus Console でサービスを定義するときに、使用する JMS タイプをコンフィグレーションします。
すべての発信メッセージのエンコーディングも、サービス定義で明示的にコンフィグレーションします。サービス定義の詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「プロキシ サービス」で「プロキシ サービスの追加」および「ビジネス サービスの追加」を参照してください。
この節では、非同期の要求/応答メッセージングを使用する利点について説明し、その利点を活用した簡単な例を示します。
非同期の要求/応答メッセージを使用する利点は次のとおりです。
WebSphere MQ を使用している場合、特定のメインフレームとの対話においては一般に非同期の要求/応答メッセージを使用する必要があります。非同期サービスでは、相関 ID を返す必要があります。AquaLogic Service Bus で内部的に使用される相関 ID の形式は WebSphere MQ の形式と互換性があり、対象サービスで MQ ネイティブのインタフェースが使用されている場合でも動作します。詳細については、「JMS 相関 ID」を参照してください。
非同期の要求/応答メッセージは、発信転送によって処理されます。つまり、転送方式固有のデータである $outbound を除き、JMS 要求/応答と HTTP 要求/応答のメッセージ フローに違いはありません。
一般的に、非同期の要求および応答を使用する必要があるのは、クライアントが HTTP 経由でプロキシ Web サービスを呼び出し、プロキシ サービスによって呼び出されたバックエンドのシステムが JMS 要求/応答を使用しているような場合です。
この項では、JMS 相関 ID を使用して要求メッセージと応答メッセージをリンクする方法について説明します。
JMS を使用して AquaLogic Service Bus と通信するビジネス サービスの要求メッセージと応答メッセージをリンクするには、JMS 相関 ID を使用する必要があります。Java でビジネス サービスを設計するときは、キューまたはトピックに JMS 応答を送信する前に、着信メッセージに対して getJMCCorrelationID を、発信メッセージに対して setJMCCorrelationID を使用する必要があります。ビジネス サービスのコンフィグレーションの詳細については、AquaLogic Service Bus Console のオンライン ヘルプの「ビジネス サービス」を参照してください。
メッセージの受信時に JMCCorrelationID を取得するには、次のようにします。
String getJMSCorrelationID()
上記のメソッドは、特定のメッセージ ID またはアプリケーション固有の文字列値を表す相関 ID の値を返します。
メッセージの送信時に JMSCorrelationID() を設定するには、次のようにします。
void setJMSCorrelationID(String correlationID)
ビジネス サービスのコンフィグレーションに JMS バインディングを使用する場合に、AquaLogic Service Bus Console で指定する必要のある SOAP/JMS URI 形式は次のとおりです。
jms://host:port/factoryJndiName/destJndiName
これに対して、BEA WebLogic Workshop では次の形式を受け取ります。
://host:port/factoryJndiName/destJndiName?URI=/process/myprocess.jpd
この問題を解決するには、メッセージを送信する前に、メッセージ フロー内で発信変数 ($outbound) に JMS プロパティとしてこの URI を設定する必要があります。$outbound の設定については、AquaLogic Service Bus Console のオンライン ヘルプの「メッセージ コンテキスト」で「inbound 変数と outbound 変数」を参照してください。
|
|
|