ユーザーズ ガイド
|
 |
 |
|
BEA AquaLogic Service Bus におけるメッセージ フローは、プロキシ サービスの実装を定義します。この節では、AquaLogic Service Bus でメッセージ フローを作成するときのガイドラインを示します。AquaLogic Service Bus のコンフィグレーションは AquaLogic Service Bus Console で行います。AquaLogic Service Bus Console の詳細については、『AquaLogic Service Bus Console の使い方』を参照してください。
メッセージ フローは、AquaLogic Service Bus プロキシ サービスの定義です。パイプライン、ブランチ ノード、およびルート ノードは、AquaLogic Service Bus プロキシ サービスの実装を定義します。AquaLogic Service Bus Console を使用して、プロキシ サービスのメッセージ フローの定義におけるメッセージ処理ロジックをコンフィグレーションします。このロジックには、トランスフォーメーション、パブリッシュ、レポートなどのアクティビティがあります。ロジックはメッセージ フロー内の個々のアクションにコンフィグレーションされます。
次の図は、メッセージ フロー定義のコンポーネントの概要です。
メッセージ フローのルートには任意の要素を使用できます。最も単純なメッセージ フロー設計の 1 つに、ルート ノードのみでフロー全体を表す方法があります。任意の 2 つの要素を連鎖できます。たとえば、間にブランチ ノードを置かずに、2 つのパイプライン ペア ノードを連鎖させることもできます。分岐を構成する場合、各ブランチを異なる要素で開始することができます。たとえば、1 つのブランチがルート ノードで終了し、もう 1 つのブランチにはパイプライン ペアが続き、さらにもう 1 つのブランチでは子孫を持たないようにできます。この最後の例のように子孫のないブランチは、ブランチの実行時に、すぐに応答処理が開始されます。ただし、一般的には、メッセージ フローは次の 2 つの形式になります。
メッセージ フローは、次の表に示す最上位コンポーネントのインスタンスを連鎖させた構造になっています。このトピックのこの後の節では、ノード タイプについてさらに詳しく説明します。
|
|
|
|
|
|
|
|
メッセージ フローの作成方法の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」の「メッセージ フローの表示と変更」を参照してください。
以下の表に、一般的なメッセージ フローでのメッセージのパスを示します。
|
|
|
「パイプライン」は、プロキシ サービスの実装の基準となるコンポーネントです。パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージ シーケンスです。
要求パスと応答パスを作成するには、要求パイプラインと応答パイプラインをペアにして、「パイプライン ペア ノード」と呼ばれる単一のノードに編成します。
次の図は、単純なメッセージ フローの例を示しています。loanGateway3 という名前のプロキシ サービスが定義されています。
loanGateway3 プロキシ サービスのツリー構造のルートです。PipelinePairNode1)。要求と応答のパイプラインが含まれます。要求パイプラインには 1 つのステージ (validate loan application) が含まれます。validate loan application ステージの 
アイコンは、このステージにエラー ハンドラが定義されていることを示します。メッセージ フローとしても実装されるエラー ハンドラの詳細については、「エラー処理」を参照してください。Route to Normal Loan Processing Service)。前の図に示したメッセージ フロー ビューに加えて、AquaLogic Service Bus Console にはメッセージ フローに対応するツリー ビュー マップが表示されます。これにより、設計時に、メッセージ フローのコンポーネント間での移動が容易になります。
メッセージ フローのコンポーネントを表示または編集するには、グラフィック表示のメッセージ フロー ビューまたはマップ (ツリー) ビューでコンポーネントをクリックします。
フロー構造になっているため、設計時にメッセージ フローの明瞭な動作概要を把握することができ、ルートとブランチ条件の両方を、パイプライン ステージまたはルート ノード内部の見えない場所に配置するのではなく、全体的な設計に明示的に含めることができます。ブランチ ノードを使用すると、これらのパイプライン ペアを条件付きで実行して、ブランチ末尾のルート ノードで要求と応答のディスパッチを実行できます。ブランチ ノードの詳細については、「メッセージ フローの分岐」を参照してください。
メッセージ フローでは、オペレーション ブランチと条件付きブランチという 2 つの分岐がサポートされています。この節では、オペレーション ブランチを使用する状況、および条件付きブランチが使用可能な状況について説明します。
メッセージ フローで Web Services Description Language (WSDL) ベースのプロキシ サービスが定義される場合、操作固有の処理が必要になることがよくあります。AquaLogic Service Bus では、操作に基づくブランチ ノードを手動でコンフィグレーションする必要はなく、操作に基づいて自動的に分岐するようにコンフィグレーションされた、最小限のブランチ ノードが用意されています。つまり、図 2-4 のようにオペレーション ブランチをメッセージ フローに作成すると、AquaLogic Service Bus Console では、ブランチ ノード コンフィグレーション ページでこれらの操作が表示されるため、WSDL に定義された操作に基づいて分岐ロジックをすぐに構築できます (図 2-5)。
オペレーション ブランチ ノードのコンフィグレーション方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」の「オペレーション ブランチ ノードの追加」と「オペレーション ブランチの詳細の表示と変更」を参照してください。
複数の操作を行うプロキシ サービスが WSDL に基づいている場合は、オペレーション ブランチを使用して、操作ごとに個別にメッセージを処理します。ただし、複数のドキュメント タイプを受信するプロキシ サービスが WSDL に基づいていない場合は、代わりに条件付きブランチ ノードを使用することを検討してください。
条件付きブランチ処理は、単純でありながらユニークな文字列値のタグが付いたブランチをまとめたルックアップ テーブルを基準に行われます。メッセージ コンテキストの変数をそのノードのルックアップ変数として指定し、実行時に、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ルックアップ変数の値は、ブランチ ノードに到達する前に設定する必要があります。
たとえば、プロキシ サービスのタイプが任意の SOAP または任意の XML で、条件付きブランチを実行できるようにメッセージ タイプを判別する必要があるというシナリオについて考えます。ステージ アクションを使用してメッセージ タイプを判別し、条件付きブランチ ノードをフローで使用して、受信したメッセージ タイプに応じて処理を分けることができます。
この場合、メッセージ フローで条件付きブランチ ノードを作成するときは、前のステージで入力された変数の値の評価に基づく分岐ロジックを構築します。
オペレーション ブランチ ノードのコンフィグレーション方法の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」の「条件付きブランチ ノードの追加」を参照してください。
また、条件付きブランチを使用して、フロー全体のビューでルーティングのオプションを明示できます。たとえば、ある条件に基づいてサービス A またはサービス B が呼び出される場合、ルート ノード内にルーティング テーブルを使用する条件付きブランチをコンフィグレーションする代わりに、メッセージ フロー自体にこのブランチを明示して、各ブランチのサブフローとして単純なルート ノードを使用することができます。
次の図は、最上位のブランチ ノード (BranchNode1) と 2 つの下位ルート ノードを含む単純なメッセージ フローです。実行時には 1 つのブランチが実行され、メッセージはサービス A とサービス B のどちらかにルーティングされます。
ルート ノードでの条件付きブランチのコンフィグレーション方法の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」の「ルート ノード アクションの追加」を参照してください。
メッセージ フロー、ステージ、またはルート ノードのどの場所にブランチをコンフィグレーションするかを決定する前に、ビジネス シナリオを検討してください。メッセージ フローにブランチをコンフィグレーションする場合、ブランチ ノードからさらに分岐してブランチの数が多くなると、設計インタフェースが煩雑になる可能性があることに注意してください。
詳細については、『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 を作成する方法については、『XQuery Mapper を使用したデータの変換』の「XQuery Mapper を使用したデータの変換」を参照してください。
メッセージ フロー内にトランスフォーメーションを指定する位置は、次の条件によって異なります。
パブリッシュ アクションで、メッセージのターゲット サービスを判別し、メッセージのパッケージおよびサービスへの送信方法をコンフィグレーションします。パブリッシュ テーブル アクションも使用できます。パブリッシュ テーブル アクションは、切り替え式の条件テーブルに含まれる一連のルートで構成されます。単一の XQuery 式の結果に基づいて各種ルートを選択できる簡単な構文です。
変換前または変換後のメッセージ フォーマットがターゲット サービスに依存する場合、ルート アクションまたはパブリッシュ アクションでトランスフォーメーションを実行する必要があります。パブリッシュ アクション内に設計されるトランスフォーメーションの場合、トランスフォーメーションで $outbound 変数およびメッセージ関連の変数 ($header、$body、および $attachments) のローカル コピーを保持します。パブリッシュ アクションで発信メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ アクションで行った変更は、メッセージ フローがその次のアクションに進む前にロールバックされます。パブリッシュ アクションおよびルート ノードのメッセージ コンテキスト情報のスコープを理解することが重要です。詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」および「メッセージ コンテキスト」を参照してください。
たとえば、メッセージ フローで大口の発注書を処理するときに、発注書の要約を電子メールで管理者宛てに送信する必要があるというシナリオについて考えます。このような場合、要求パイプラインにパブリッシュ アクションを含めることで、着信メッセージの SOAP 本体に含まれる発注書の主要部分を含む要約を作成できます。パブリッシュ アクションでは、発注書データを注文要約に変換することができます。たとえば、注文要約では添付ファイルは必要ないため、$attachments のすべての添付ファイルを削除できます。
もう 1 つの例は、WS-addressing ヘッダに基づいてメッセージを 2 つの送り先の 1 つにルーティングする場合 (コンテンツ ベース ルーティング) です。このとき、2 つ目の送り先では、SOAP 本体のドキュメントが新しいバージョンに変換されている必要があります。このような場合、条件に基づいて 2 つの送り先の一方にルーティングされるように、ルート ノードをコンフィグレーションできます。2 つ目の送り先のためにドキュメントを変換するように、ルート ノードでトランスフォーメーションをコンフィグレーションします。
発信コンテキスト変数 ($outbound) の制御要素を設定して、発信メッセージに関するシステムの動作を調整できます (たとえば、サービスの品質を設定できます)。inbound 変数および outbound 変数の下位要素について、およびメッセージのコンテンツを作成するのにメッセージ コンテキスト変数の値がどのように使われるかについては、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」で「inbound 変数と outbound 変数」および「送信するメッセージの作成」を参照してください。
AquaLogic Service Bus メッセージ フローでは、メッセージ フローのロジックを定義するアクションはステージに格納されます。ほとんどの場合、1 つのパイプラインに 1 つのステージを使用するだけで十分ですが、複数のステージを使用する必要がある場合もあります。この節では、パイプラインで複数のステージを使用する場合とその理由について説明します。ステージのコンフィグレーションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」の「ステージの追加」を参照してください。
メッセージ フローのアクションで実行されるタスクを次に示します (メッセージ フローでのアクションの作成とコンフィグレーションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」の情報を参照してください)。
複数のステージを設計するか、複数のアクションを持つ単一のステージをコンフィグレーションするかを決定する際には、ステージに関する以下の特徴を考慮して役立てます。
詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」で「ステージの追加」および「ステージ コンフィグレーションの詳細の表示と変更」を参照してください。
この節では、エラーの処理方法の概要について説明し、エラー処理オプションをコンフィグレーションするときのガイドラインを示します。
各ステージは、ステージでエラーが発生した場合に実行される一連の手順を持つことができます。この一連の手順がそのステージのエラー パイプラインを構成しています。また、エラー パイプラインは、パイプライン (要求または応答) またはプロキシ サービス全体に対して定義することができます。最も小さいスコープで指定されたエラー パイプラインがエラー時に呼び出されます。
図 2-7 ステージ、ノード、およびサービスレベルのエラー ハンドラ
エラー メッセージと処理の詳細については、『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 プロパティ SERVER_Error が true に設定されているために SOAP エラーが返されたと認識されます。
用途によっては、エラー レポートが必要な場合があります。このような場合は、レポート アクションを使用します。たとえば、要求パイプラインで追跡用にメッセージをレポートするレポート アクションを実行した後、ルート ノードによって呼び出されたサービスが失敗するというシナリオを想定します。このような場合、メッセージはレポート システムによってログに記録されますが、メッセージが正常に処理されたという保証はありません。メッセージが正常に受信されたことを示すだけです。
AquaLogic Service Bus Console では、メッセージを追跡することによって、メッセージ フローの正確な流れを把握することができます。したがって、元のレポート メッセージで、メッセージが処理用に送信されたことを確認でき、後続のエラー レポートで、メッセージが正常に処理されなかったことを確認できます。レポート アクションのコンフィグレーション方法や実行時にレポートされるデータの使用方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
この例では、エラー ハンドラにレポート アクションと返信アクションをコンフィグレーションする方法を示します。図 2-2 のメッセージ フローでは、validate loan application ステージにエラー ハンドラがあります。このエラー ハンドラは、1 つのステージがコンフィグレーションされた単純なメッセージ フローです。AquaLogic Service Bus Console には次のように表示されます。
ステージは次の図に示すように、アクション (置換、レポート、および返信) でコンフィグレーションされています。
アクションによってステージ エラー ハンドラの動作が次のように指定されます。
fault コンテキスト変数のコンテンツで置換することを指定します。body 変数の要素は XPath 式で指定します。コンテンツは、XQuery 式で返される値で置換されます。この例では $fault/ctx:reason/text() です。この例では、エラーが発生すると fault コンテキスト変数のコンテンツがレポートされます。errorCode はキー名です。キー値は fault 変数から XPath 式 ./ctx:errorCode で抽出されます。キーと値のペアをキー識別子として使用して、実行時にダッシュボードでこれらのメッセージを識別します。
レポート アクションのコンフィグレーション方法や実行時にレポートされるデータの使用方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
失敗時] です。実行時には、loanGateway3 プロキシ サービスの呼び出し元に返信が即時に送信され、メッセージにエラーがあったことを知らせます (図 2-2 を参照)。コンフィグレーションの詳細については、『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 式の作成を容易にするために、設計時エディタでは任意の変数に型をマッピングできます。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 でなくても、メッセージは AquaLogic Service Bus のメッセージ コンテキスト内で SOAP として表示されます。
$header には SOAP Header 要素が含まれ、$body には SOAP Body 要素が含まれます。$attachments には attachments というラッパー要素が含まれ、1 つの添付ファイルにつき 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 には空の attachment 要素がそれぞれ含まれる場合があります。$body) にビジネス ドキュメントを渡すことができます。トランスフォーメーションの結果は、置換アクションを使用して $body に戻すことができます (Body 要素のコンテンツ、つまり$body のコンテンツを置換します)。詳細については、『AquaLogic Service Bus Console の使い方』の「XQuery トランスフォーメーション」および「XSL トランスフォーメーション」を参照してください。
$inbound から $outbound に一連の転送ヘッダをコピーすることができます。アクションの追加については、『AquaLogic Service Bus Console の使い方』の「プロシキ サービス : アクション」にある「アクションの追加」を参照してください。使用例については、「inbound から outbound への JMS プロパティのコピー」を参照してください。AquaLogic Service Bus では、プロキシ サービスとそれによって呼び出されるビジネス サービスのインタフェースが異なると想定されています。そのため、inbound 変数から outbound 変数への情報 (転送ヘッダや JMS プロパティなど) の伝播は行われません。
プロキシ サービスの要求メッセージおよび応答メッセージの転送ヘッダは $inbound にあり、呼び出されるビジネス サービスの要求および応答の転送ヘッダは $outbound にあります。
たとえば、一方向メッセージ (応答を伴わない呼び出し) でユーザ定義の JMS プロパティが inbound から outbound にコピーされる必要がある場合、次の XQuery 式を使用します。
転送ヘッダ アクションを使用して、outbound 変数に次のように設定します。
$inbound/ctx:transport/ctx:request/tp:headers/tp:user-header
./ctx:transport/ctx:request/tp:headers
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>
</definitions>
前のコード リストのサービスには lookup という操作 (java クラスのメソッドと同等) が含まれています。バインディングは、これが SOAP RPC Web サービスであることを示しています。つまり、この Web サービスの操作は、一連の要求パラメータを受信して一連の応答パラメータを返します。この lookup 操作には、request というパラメータと result という戻りパラメータがあります。バインディングでの操作のネームスペースは次のようになります。
http://example.com/lookup/service
コード リスト 2-2 の WSDL を要求で使用した場合に、SOAP RPC プロキシ サービスによって取得される body 変数 ($body) の値を次のコード リストに示します。
注意 : 次のコードでは、わかりやすくするために XML からネームスペース定義が除外されています。
<soap-env:Body>
<ns:lookup>
<request>
<req:PurchaseOrg>BEA Systems</req:PurchaseOrg>
</request>
</ns:lookup>
<soap-env:Body>
上記の例では、soap-env は事前定義された SOAP ネームスペース、ns は操作のネームスペース (<http://example.com/lookup/service>)、req は PurchaseOrg 要素のネームスペース (<http://example.com/lookup/docs>) です。
プロキシ サービスでのメッセージのルーティング先のビジネス サービスがコード リスト 2-2 の WSDL を使用している場合、コード リスト 2-3 のbody 変数 ($body) の値は、プロキシ サービスの body 変数 ($body) の値です。
この WSDL を要求で使用した場合にプロキシ サービスが受信する、呼び出されたビジネス サービスからの応答の body 変数 ($body) の値を、次のコード リストに示します。
<soap-env:Body>
<ns:lookupResponse>
<result>
<req:LegacyBoolean>true</req:LegacyBoolean>
</result>
</ns:lookupResponse>
<soap-env:Body>
これは、この 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>
</definitions>
このサービスには lookup という操作 (Java クラスのメソッドと同等) が含まれています。バインディングは、これが SOAP ドキュメント型 Web サービスであることを示しています。
前のコード リストの WSDL を要求で使用した場合に、ドキュメント型プロキシ サービスによって取得される body 変数 ($body) の値を次のコード リストに示します。
<soap-env:Body>
<req:PurchaseOrg>BEA Systems</req:PurchaseOrg>
<soap-env:Body>
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>
<soap-env:Body>
これは、この WSDL を使用するプロキシ サービスによって返される応答の body 変数 ($body) の値でもあります。
BEA WebLogic Workshop ツールをはじめとする多くのツールでは、プロキシ サービスの WSDL (ブラウザで、プロキシ サービスの URL に ?WSDL サフィックスを追加することで取得可能) を受け取り、適切な要求パラメータと応答パラメータを持つ Java クラスを生成して、サービスの操作を呼び出します。この Java クラスで、この WSDL を使用するプロキシ サービスを呼び出すことができます。
AquaLogic Service Bus では、BEA XQuery Mapper などの外部ツールで作成された XQuery をインポートできます。これらの XQuery は、プロキシ サービスのメッセージ フローのどの場所にも使用できます。XQuery リソースの入力をインライン XQuery にバインドし、XQuery リソースの出力をアクションにバインドすることで、その結果が割り当てアクション、置換アクション、挿入アクションなどのアクション入力として使用されます。
ただし、XQuery をリソースとして入力するのではなく、アクションの定義の一部としてインラインで入力することができます。If...Then... アクションの条件にインライン XQuery を使用することもできます。
インライン XQuery 式エディタは一般に、以下で構成される簡単な XQuery を入力するときに使用します。
注意 : より複雑な XQuery については、XQuery に慣れていない場合は特に、XQuery Mapper を使用することをお勧めします。
インライン XQuery は、次のような使用例に適しています。
$header または $body に含まれる SOAP エンベロープの要素からビジネス ドキュメントまたは RPC パラメータを抽出する、またはアクセスする。$attachments に含まれる添付ドキュメントを抽出する、またはアクセスする。 for loop を実行するために SOAP エンベロープからシーケンスを抽出する。 for loop 内のシーケンスの項目を更新する。注意 : インライン XQuery 式エディタを使用すると、変数の構造を作成することができます。詳細については、「変数の構造の使用」を参照してください。
インライン XQuery 式エディタを使用すると、変数の構造を作成することができます。これにより、設計の目的 (たとえば、簡単に作成できる XPath、変数の用途の理解、XML スキーマを表示せずにコンソールで構造を確認できるなど) で、変数の構造を添付したり定義したりできます。
注意 : ランタイムを作動させるために変数の構造を作成する必要はありません。
一般的なプログラミング言語において、変数のスコープ (有効範囲) は静的に定義され、変数の名前と型は明示的に宣言されます。定義された静的なスコープ内の任意の場所から変数にアクセスできます。
AquaLogic Service Bus では、事前定義された変数が存在しますが、変数に値を割り当てることによって動的に変数を作成することもできます。変数に値を割り当てると、プロキシ サービスのメッセージ フローの任意の場所から変数にアクセスできるようになります。変数の型は宣言されませんが、原則として、任意の時点で変数に格納されている基礎になる値の型が変数の型になります。
インライン XQuery 式エディタを使用すると、XQuery には 0 以上の入力と 1 つの出力が含まれます。式エディタそのもので入力と出力の構造を表示できるため、インライン XQuery を作成するときに、XML スキーマまたは WSDL リソースを開いて構造を確認する必要はありません。構造が視覚的に表示されるため、作成中の XQuery に述部を指定せずに、child 軸に沿って単純な変数パスをドラッグ アンド ドロップすることができます。
変数の構造のマッピングでは、各エントリはラベルを持ち、変数または変数パスを 1 つまたは複数の構造にマップします。これらのマッピングのスコープはステージまたはルート ノードです。変数は静的に型指定されないので、1 つの変数がステージまたはルート ノードのさまざまな位置 (または同じ位置) で複数の異なる構造を持つことができます。つまり、1 つの変数を複数の構造にマップし、それぞれに異なるラベルを使用することができます。構造を表示するには、ドロップダウン リストで対応するラベルを選択します。
注意 : インライン XPath 式エディタでも変数の構造のマッピングを作成できます。ただし、変数は構造にマップされますが、構造から選択したときに生成される XPath は、変数を基準にした相対 XPath です。./ctx:attachment/ctx:body は相対 XPath の例です。ただし、この XPath を生成するために使用されたマッピングでは $attachments がマップされます。
このサンプル WSDL は、この節のほとんどの例で使用します。この WSDL をリソースとしてコンフィグレーションに保存してください。詳細については、「例で必要なリソースの作成」を参照してください。
<definitions
name="samplewsdl"
targetNamespace="http://example.org"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:s0="http://www.bea.com"
xmlns:s1="http://example.org"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types>
<xs:schema
attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="http://www.bea.com"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="PO" type="s0:POType"/>
<xs:complexType name="POType">
<xs:all>
<xs:element name="id" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
</xs:all>
</xs:complexType>
<xs:element name="Invoice" type="s0:InvoiceType"/>
<xs:complexType name="InvoiceType">
<xs:all>
<xs:element name="id" type="xs:string"/>
<xs:element name="name" type="xs:string"/>
</xs:all>
</xs:complexType>
</xs:schema>
</types>
<message name="POTypeMsg">
<part name="PO" type="s0:POType"/>
</message>
<message name="InvoiceTypeMsg">
<part name="InvReturn" type="s0:InvoiceType"/>
</message>
<portType name="POPortType">
<operation name="GetInvoiceType">
<input message="s1:POTypeMsg"/>
<output message="s1:InvoiceTypeMsg"/>
</operation>
</portType>
<binding name="POBinding" type="s1:POPortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetInvoiceType">
<soap:operation soapAction="http://example.com/GetInvoiceType"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>
この後の例を利用するには、サンプル WSDL をリソースとしてコンフィグレーションに保存する必要があります。また、サンプル WSDL を使用するサンプルのビジネス サービスとプロキシ サービスを作成することも必要です。
例を使用するときは、ステージの編集で [ステージ コンフィグレーションの編集] ページにアクセスし、式を使用するアクションを追加して [XQuery 式エディタ] ページにアクセスする必要があります。まず、SampleWSDL を使用するビジネス サービスを作成する必要があります。「サンプル WSDL を使用するビジネス サービスを作成する」に進みます。
プロキシ サービス ProxyWithSampleWSDL のサービス タイプは、SampleWSDL のバインディング POBinding を使用する WSDL バインディングです。
この例では、プロキシ サービス メッセージ フローが、処理するメッセージの構造を認識する必要があります。このために、AquaLogic Service Bus では事前定義された構造が自動的に提供されます。この構造は、インタフェースのすべてのメッセージで body 変数を SOAP 本体にマップします。事前定義されたこの構造のマッピングのラベルは body です。
注意 : この事前定義された構造は、型付きインタフェースを備えたメッセージング サービスのためにもサポートされています。
プロキシ サービス ProxyWithSampleWSDL が、ビジネス サービス BusinessWithSampleWSDL へのサービス コールアウトを呼び出すとします。このビジネス サービスも、サービス タイプは、SampleWSDL のバインディング POBinding を使用する WSDL バインディング です。操作 GetInvoiceType が呼び出されます。
この例では、メッセージ フローが、処理する応答パラメータの構造を認識する必要があります。このためには、応答パラメータ変数を型 InvoiceType にマップする新しい変数の構造を作成します。
![[変数の構造] - body](wwimages/variable_structures_body.gif "[変数の構造] - body")
![[変数の構造] - [新しい構造の追加]](wwimages/variable_structures_AddNew.gif "[変数の構造] - [新しい構造の追加]")
InvoiceType を入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。一時変数には、SampleWSDL WSDL で記述された要素 Invoice が含まれているとします。この例では、ProxyWithSampleWSDL メッセージ フローは、この変数にアクセスする必要があります。このために、変数を要素 Invoice にマップする新しい変数の構造を作成します。
ProxyWithSampleWSDL プロキシ サービスは、ドキュメント型が任意の SOAP であるビジネス サービスにルーティングします。このビジネス サービスは発注書を SOAP 本体に格納して返します。この例では、ProxyWithSampleWSDL プロキシ サービスのメッセージ フローが、その応答を処理する必要があります。このためには、body 変数を PO 要素にマップする新しい構造を作成し、PO 要素を変数の子要素として指定します。body 変数には SOAP Body 要素が含まれ、PO 要素は Body 要素の子であるため、子要素として指定する必要があります。
ProxyWithSampleWSDL プロキシ サービスは、BusinessWithSampleWSDL ビジネス サービスにルーティングします。このビジネス サービスのサービス タイプは、SampleWSDL のバインディング POBinding を使用する WSDL バインディングです。この例では、メッセージ フローが応答を処理する必要があります。このためには、body 変数を BusinessWithSampleWSDL ビジネス サービスにマップする新しい構造を定義します。これにより、インタフェースのすべてのメッセージについて body 変数が SOAP 本体にマップされます。
注意 : このマッピングは、型付きインタフェースを備えたメッセージング サービスのためにもサポートされています。
SampleWSDL を変更して、ProxyWithSampleWSDL プロキシ サービスが 1 つの添付ファイルを受け取るようにします。添付ファイルは発注書です。この例では、プロキシ サービスのメッセージ フローが発注書を処理する必要があります。このためには、$attachments の body 要素を PO 要素 (子要素として指定されている) にマップする新しい構造を定義します。body 要素は、変数パスとして次の形式で指定されます。
事前定義されている attachments 構造の body 要素を選択してコピーし、新しいマッピング定義でマップされる変数パスとしてこの要素を貼り付け、貼り付けた値を変更して述部を追加します。
BEA AquaLogic Service Bus は、信頼性の高いメッセージ機能を備えています。メッセージがルート ノードから別のサービスにルーティングされるときの $outbound のデフォルトのサービスの品質 (QoS) 要素は、exactly-once または best-effort です。outbound コンテキスト変数の qualityOfService 要素の値により、望ましい配信動作のヒントが AquaLogic Service Bus に提供されます。qualityOfService 要素の値が使用されるのは、HTTP、HTTPS、または JMS 転送でのプロキシ サービスの発信転送のみです。
次のアクションについてデフォルトの qualityOfService 要素属性をオーバーライドできます。
注意 : サービス コールアウト アクションの qualityOfService 要素属性はオーバーライドできません。
qualityOfService 要素属性をオーバーライドするには、発信メッセージ コンテキスト変数 ($outbound) に qualityOfService を設定する必要があります。詳細については、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」の「メッセージ コンテキスト スキーマ」を参照してください。
プロキシ サービスがメッセージをパブリッシュするか、要求をビジネス サービスにルーティングするとき、次の条件に応じて配信の保証がサポートされます。
ただし、着信プロキシ サービスが JMS ではなく、呼び出し元が別のプロキシ サービスである場合、呼び出し元のプロキシ サービスの着信転送が配信の保証を行います。呼び出されたプロキシ サービスの転送が JMS でない場合、呼び出し元のプロキシ サービスが最適化されて、直接呼び出しになるためです。転送プロトコルの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」で「プロキシ サービスの追加」および「ビジネス サービスの追加」を参照してください。
注意 : プロキシ サービスからの応答には配信の保証はありません。
注意 : 配信の保証として at least once および exactly once をサポートするには、JMS トランザクションを利用し、サーバのクラッシュまたは、返信アクションや再開アクションのエラー ハンドラで処理できないエラーの際に、メッセージを再配信するように JMS キューの再試行回数と再試行間隔をコンフィグレーションする必要があります。ファイル、FTP、および電子メール転送でも、内部では JMS/XA キューが使用されます。JMS/XA 転送を使用するプロキシ サービスのデフォルトの再試行回数は 1 です。AquaLogic Service Bus で作成されるデフォルトの JMS キューのリストについては、BEA AquaLogic Service Bus の『デプロイメント ガイド』を参照してください。
![[変数の構造] - InvoiceType](wwimages/variable_structures_InvoiceType.gif "[変数の構造] - InvoiceType")
![[変数の構造] - Invoice](wwimages/variable_structures_InvoiceElement.gif "[変数の構造] - Invoice")
![[変数の構造] - body to PO](wwimages/variable_structures_bodytoPO.gif "[変数の構造] - body to PO")
![[変数の構造] - BusinessService](wwimages/variable_structures_BusinessService.gif "[変数の構造] - BusinessService")
![[変数の構造] - attachments](wwimages/variable_structures_attachments.gif "[変数の構造] - attachments")
qualityOfService 要素が exactly-once に設定されているとき、JMS/XA 送り先への要求フローで実行されるルート ノードおよびパブリッシュ アクションは、同じトランザクションで実行される。qualityOfService 要素が best-effort に設定されているとき、ルート ノード、サービス コールアウト アクション、またはパブリッシュ アクションは、要求フローのトランザクションとは別に実行される。特に、JMS の場合、要求フロー トランザクションはサスペンドされ、JMS の処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。qualityOfService 要素が exactly-once に設定されているとき、すべてのパブリッシュ アクションは同じトランザクションで実行される。 qualityOfService 要素が best-effort に設定されているとき、すべてのパブリッシュ アクションとサービス コールアウト アクションは、応答フローのトランザクションとは別に実行される。特に、JMS の場合、応答フロー トランザクションはサスペンドされ、JMS の処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。qualityOfService 要素の設定に関係なく、常に同じトランザクションで実行される。HTTP および HTTPS における at least once のメッセージ配信の保証について、以下に詳細を説明します。ターゲット サービスがエラーまたは HTTP ステータスを伴う応答を返す場合でも、配信は完了したと想定されます。つまり、ターゲット サービスが認証エラーや「ページが見つからない」エラーなどを返すような場合でも、サーバは利用可能であり、サービスによってメッセージが処理されたと見なされます。ただし、次の場合、メッセージは再配信されます。
フェイルオーバ URL が指定されている場合は、少なくとも 1 つの URL について at least once のセマンティクスが提供されます。
BEA AquaLogic Service Bus のスレッディング モデルは次のように作動します。
qualityOfService 要素の値が best-effort の場合、HTTP ルートまたはパブリッシュ アクションはブロックしません (要求/応答または一方向呼び出しの場合)。 注意 : 要求フローまたは応答フローのパブリッシュ アクションでは、応答は必ず破棄されます。パブリッシュ メッセージは本質的に一方向送信メッセージであるためです。
qualityOfService 要素に exactly-once を指定し、XA 接続ファクトリを使用します。メッセージの着信の再試行をコンフィグレーションするだけでなく、発信の再試行およびロード バランシングもコンフィグレーションできます。ロード バランシング、フェイルオーバ、および再試行の組み合わせによって、パフォーマンスと高可用性を実現できます。各メッセージのフェイルオーバ URL として指定した URL のリストは、ロード バランシング アルゴリズムに基づいて自動的に並べ替えられ、フェイルオーバのシーケンスが形成されます。再試行回数が N の場合、シーケンス全体が N 回再試行されてから終了します。システムは指定された再試行間隔の時間だけ待機してから、シーケンスの次のループを開始します。再試行回数が完了してもまだエラーがある場合、ルート ノードのエラー処理パイプラインが呼び出されます。エラー処理パイプラインの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」で「パイプラインへのエラー処理の追加」を参照してください。
AquaLogic Service Bus では、HTTP および HTTPS 転送方式の 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 を、発信メッセージに対して setJMSCorrelationID を使用する必要があります。ビジネス サービス のコンフィグレーションの詳細については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」を参照してください。
メッセージの受信時に JMSCorrelationID を取得するには、次のようにします。
String getJMSCorrelationID()
上記のメソッドは、特定のメッセージ ID またはアプリケーション固有の文字列値を表す相関 ID の値を返します。
メッセージの送信時に JMSCorrelationID() を設定するには、次のようにします。
void setJMSCorrelationID(String correlationID)
BEA AquaLogic Service Bus は、実行時環境で WS-I (Web サービス相互運用性) 準拠を提供します。WS-I の基本プロファイルの目標を以下に示します。
WS-I 基本プロファイルは、次の URL で入手できます。
http://www.ws-i.org/Profiles/BasicProfile-1.1.html
プロキシ サービスまたはビジネス サービスをコンフィグレーションするとき、AquaLogic Service Bus Console を使用すると、AquaLogic Service Bus で WS-I 準拠をそれらのサービスに適用するかどうかを指定できます。この方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」の「プロキシ サービスの追加」を参照してください。
プロキシ サービスについて WS-I 準拠をコンフィグレーションすると、そのプロキシ サービスが受信する着信要求メッセージでチェックが実行されます。呼び出されたサービスについて WS-I 準拠をコンフィグレーションすると、その呼び出されたサービスからの応答メッセージを任意のプロキシが受信したときに、チェックが実行されます。デフォルトではプロキシ サービスの SOAP クライアントはシステム エラー ハンドラ定義のエラーを受け取るため、このようなエラーのためにエラー ハンドラを作成することを強くお勧めします。エラー ハンドラの作成方法の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」の「エラー メッセージと処理」を参照してください。
プロキシ サービスから送信されるメッセージについては、それが発信要求でも着信応答でも、WS-I 準拠のチェックは明示的には実行されません。これは、ほとんどのメッセージ コンテンツの生成はパイプライン設計者によって行われるためです。ただし、メッセージの AquaLogic Service Bus によって生成される部分は、サポートされる WS-I 準拠のすべてのチェックを満たします。次のコンテンツが含まれます。
[WS-I 準拠の適用] チェックボックスは、AquaLogic Service Bus Console に次のように表示されます。
注意 : WS-I 準拠チェックでは、サービスで呼び出される操作をシステムが認識する必要があります。つまり、プロキシ サービスによって受信される要求メッセージでは、コンテキスト変数 $operation が null であってはなりません。そのためには、操作選択アルゴリズムが適切にコンフィグレーションされていることが前提になります。呼び出したサービスから受信する応答メッセージでは、操作は、ルート、パブリッシュ、およびサービス コールアウトのアクション コンフィグレーションで指定されているはずです。
サービスについて WS-I 準拠チェックをコンフィグレーションすると、AquaLogic Service Bus によって次のチェックが実行されます。
|
|
|
![[WS-I 準拠の適用] チェックボックス](wwimages/wsi_compliance.gif "[WS-I 準拠の適用] チェックボックス")