|
|
BEA AquaLogic Service Bus におけるメッセージ フローは、プロキシ サービスの実装を定義します。この節では、メッセージ フローを作成するためのガイドラインを示します。AquaLogic Service Bus Console での AquaLogic Service Bus のコンフィグレーションについては、『AquaLogic Service Bus Console の使い方』を参照してください。
メッセージ フローは、AquaLogic Service Bus プロキシ サービスの実装を定義するパイプライン、ブランチ ノード、およびルート ノードで構成されます。プロキシ サービスは、AquaLogic Service Bus のローカルでホストされた仲介 Web サービスの AquaLogic Service Bus での定義です。AquaLogic Service Bus Console を使用して、プロキシ サービスのメッセージ フローの定義におけるメッセージ処理ロジックをコンフィグレーションできます。このロジックには、トランスフォーメーション、パブリッシュ、レポートなどのアクティビティがあります。ロジックはメッセージ フロー内の個々のアクションにコンフィグレーションされます。
次の図は、メッセージ フロー定義のコンポーネントの詳細を示します。
メッセージ フローのルートには任意のコンポーネントを使用できます。(コンポーネントの詳細については、「表 2-1 メッセージ フローのコンポーネント」を参照)。最も単純なメッセージ フロー設計の 1 つに、ルート ノードのみでフロー全体を表す方法があります。メッセージ フローの作成時に、任意の 2 つのコンポーネントを連鎖できます。たとえば、間にブランチ ノードを置かずに、2 つのパイプライン ペア ノードをリンクさせることができます。ブランチ ノードの場合、各ブランチ ノードを別々の要素で開始できます。たとえば、1 つのブランチがルート ノードで終了し、もう 1 つのブランチにはパイプライン ペアが続き、さらにもう 1 つのブランチでは子孫を持たないようにできます。この最後の例のように子孫のないブランチは、ブランチの実行時に、すぐに応答処理が開始されます。ただし、一般的には、メッセージ フローは次の形式のいずれかになります。
メッセージ フローは、次の表に示す最上位コンポーネントのインスタンスをリンクさせた構造になっています。このトピックのこの後の節では、ノード タイプについてさらに詳しく説明します。
|
|
|||
|
|
<500) を指定し、これが単一の XPath 式 (たとえば、$body の ./ns: PurchaseOrder/ns: totalCost) に対してメッセージ フローを降順に評価される。最初に満たされた条件によって、次に進むべきブランチが決定される。満たされる条件がない場合、デフォルトのブランチに進む。ブランチ ノードでは、メッセージ フロー内にいくつかの子孫を持つことができる (デフォルトのブランチを含め各ブランチに 1 つずつ)。
|
||
メッセージ フローの作成方法については、『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 では、オペレーションに基づくブランチ ノードを手動でコンフィグレーションする代わりに、オペレーションに基づいて自動的に分岐するようにコンフィグレーションされた、最小限のブランチ ノードが用意されています。つまり、オペレーション ブランチ ノードをメッセージ フローに作成すると、AquaLogic Service Bus Console では、WSDL に定義されたオペレーションがブランチ ノード コンフィグレーション ページに表示されるため、これらのオペレーションに基づいて分岐ロジックをすばやく構築できます (図 2-4)。
プロキシ サービスが複数のオペレーションを定義した WSDL に基づいている場合は、オペレーション ブランチを使用する必要があります。この場合、オペレーション ブランチを使用して、オペレーションごとに個別にメッセージを処理することを検討できます。オペレーション ブランチ ノードのコンフィグレーション方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」にあるオペレーション ブランチ ノードの追加に関する説明と「オペレーション ブランチの詳細の表示と変更」を参照してください。
プロキシ サービスが WSDL に基づいておらず、複数のドキュメント タイプを入力として受信する場合は、条件付きブランチ ノードを使用することを検討してください。
条件付きブランチ処理は、単純でありながらユニークな文字列値のタグが付いたブランチをまとめたルックアップ テーブルを基準に行われます。メッセージ コンテキストの変数をそのノードのルックアップ変数として指定し、実行時に、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ブランチ ノードに到達する前にルックアップ変数の値を設定するように、プロキシ サービスを設定する必要があります。
| 注意 : | メッセージ フローに条件付きブランチがある場合は、デフォルトのブランチを定義することを強くお勧めします。 |
たとえば、プロキシ サービスのタイプが任意の SOAP または任意の XML で、条件付きブランチを実行できるようにメッセージのタイプを判別する必要があるという場合について考えます。この場合、ステージ アクションを設定してメッセージのタイプを判別し、フロー内に条件付きブランチ ノードを設定して、受信するメッセージのタイプに応じて処理を分けることができます。メッセージ フローに条件付きブランチ ノードを設定するときは、前のステージで入力された変数の値の評価に基づいて分岐ロジックを構築します。
条件付きブランチ ノードの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」にある条件付きブランチ ノードの追加に関する説明を参照してください。
また、条件付きブランチを使用して、フロー全体のビューでルーティングのオプションを明示できます。たとえば、ある条件に基づいてサービス A またはサービス B を呼び出す場合、ルート ノード内にルーティング テーブルを使用する条件付きブランチをコンフィグレーションする代わりに、メッセージ フロー自体にこのブランチをエクスポーズし、各ブランチのサブフローとして単純なルート ノードを使用できます。
図 2-5 は、最上位のブランチ ノード (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 を使用したデータの変換を参照してください。
メッセージ フロー内にトランスフォーメーションを指定する位置は、以下の条件によって異なります。
パブリッシュ アクションで、メッセージのターゲット サービスを判別し、メッセージのパッケージおよびサービスへの送信方法をコンフィグレーションします。AquaLogic Service Bus には、パブリッシュ テーブル アクションも用意されています。パブリッシュ テーブル アクションは、切り替え式の条件テーブルに含まれる一連のルートで構成されます。これは、単一の XQuery 式の結果に基づいて各種ルートを選択できる短縮形の構文です。
トランスフォーメーションをパブリッシュ アクション内に設計した場合、トランスフォーメーションは $outbound 変数およびメッセージ関連の変数 ($header、$body、および $attachments) のローカル コピーを保持します。パブリッシュ アクションで発信メッセージに行った変更は、パブリッシュされるメッセージにのみ反映されます。つまり、パブリッシュ アクションで行った変更は、メッセージ フローがその次のアクションに進む前にロールバックされます。詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」および「メッセージ コンテキスト」を参照してください。
たとえば、メッセージ フローで大口の発注書を処理するときに、管理者宛てに発注書の要約を電子メールで送信する必要がある場合について考えます。このような場合、要求パイプラインにパブリッシュ アクションを含めると、着信メッセージの SOAP 本体に発注書の要約が作成されます。パブリッシュ アクションでは、発注書データが発注書の要約に変換されます。たとえば、発注書の要約には添付ファイルは必要ないため、$attachments のすべての添付ファイルを削除できます。
WS-Addressing ヘッダに基づく 2 つの送り先のうち、一方にメッセージをルーティング (コンテキストベースのルーティング) する必要があり、もう一方では SOAP 本体のドキュメントの新しいバージョンが必要であるとします。このような場合、条件に基づいて 2 つの送り先の一方にルーティングされるように、ルート ノードをコンフィグレーションできます。2 つ目の送り先のためにドキュメントを変換するように、ルート ノードでトランスフォーメーションをコンフィグレーションします。
発信コンテキスト変数 ($outbound) の制御要素を設定して、発信メッセージに関するシステムの動作を調整できます (たとえば、サービスの品質を設定できます)。inbound 変数および outbound 変数の下位要素について、およびメッセージのコンテンツを作成するのにメッセージ コンテキスト変数の値がどのように使われるかについては、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」にある「inbound 変数と outbound 変数」および「送信するメッセージの作成」を参照してください。
AquaLogic Service Bus メッセージ フローでは、メッセージ フローのロジックを定義するアクションはステージに格納されます。ほとんどの場合、1 つのパイプラインに 1 つのステージを使用するだけで十分ですが、複数のステージを使用する必要がある場合もあります。パイプラインでの複数のステージの使用方法については、「複数のステージの使用」で説明します。ステージのコンフィグレーションについては、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」にある「ステージの追加」を参照してください。
BEA AquaLogic Service Bus には、メッセージ フローのステージをコンフィグレーションできるさまざまなアクションが用意されています。これらのアクションは、以下のカテゴリに分類されます。
このカテゴリのアクションは、パイプラインのメッセージ フローを制御します。これらのアクションを使用して、メッセージ フローの対象 URL やメッセージ フローのパッケージングのモードを指定します。また、AquaLogic Service Bus に登録済みのプロキシ サービスまたはビジネス サービスに、同期コールアウトをコンフィグレーションするモードを指定することもできます。メッセージ フロー パイプラインのステージの通信アクションは次のとおりです。
通信アクションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。ルート ノードで使用できる通信アクションは次のとおりです。
| 注意 : | ルート ノードのステージへのアクションの追加方法の詳細については、『AquaLogic Service Bus Console の使い方』のプロキシ サービス : メッセージ フローのルート ノード アクションの追加を参照してください。 |
エラー ハンドラ ステージで使用できる通信アクションは次のとおりです。
このカテゴリのアクションは、パイプラインのメッセージ フローを制御します。これらのアクションを使用して、メッセージ フローのステージ内に条件付きルーティング、条件付きループ、およびエラー処理を実装します。また、呼び出し元に成功を通知したり、ステージの残りのアクションをスキップすることもできます。パイプラインのステージのフロー アクションは次のとおりです。
このカテゴリのアクションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
ルート ノードで使用できるフロー制御アクションは、If... Then... です。
| 注意 : | ルート ノードのステージへのアクションの追加方法の詳細については、『AquaLogic Service Bus Console の使い方』のプロキシ サービス : メッセージ フローのルート ノード アクションの追加を参照してください。 |
エラー ハンドラ ステージで使用できるフロー制御アクションは次のとおりです。
| 注意 : | ルート ノードのステージへのアクションの追加方法の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : エラー ハンドラ」を参照してください。 |
このカテゴリのアクションは、要求に応じてメッセージ フローを処理します。このカテゴリのアクションを使用すると、XPath 式の変更、処理用の Java メソッドの呼び出し、メッセージ フォーマットの変換、および転送ヘッダの設定を行うことができます。メッセージ フロー パイプラインのステージのメッセージ処理アクションは次のとおりです。
メッセージ処理アクションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
パイプライン エラー ハンドラのステージで使用できるメッセージ処理アクションは次のとおりです。
このカテゴリのアクションを使用して、ステージ内のメッセージ フローで必要な場合に、エラーのログ記録またはレポート、およびアラートの生成を行います。メッセージ フロー パイプラインのステージのレポート アクションは次のとおりです。
パイプライン エラー ハンドラのステージのレポート アクションは次のとおりです。
レポート アクションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
メッセージ フローに複数のステージがあると、モジュラー レベルでエラー ハンドラを定義できます。メッセージ フローのステージごとに別々のエラー処理パイプラインを持つことができます。次の 2 タイプのアクションを使用して、ステージのアクションのランタイム実行を制御できます。
| 注意 : | メッセージ フロー処理は、パイプラインの次のステージで再開されます。 |
詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : メッセージ フロー」にある「ステージの追加」および「ステージ コンフィグレーションの詳細の表示と変更」を参照してください。
次のパラグラフで説明する処理は、エラー処理ステージのエラー処理パイプラインを構成します。また、エラー パイプラインは、パイプライン (要求または応答) またはプロキシ サービス全体に対して定義することができます。
ステージ レベルのエラー ハンドラがエラー処理に呼び出されます。ステージ レベルのエラー ハンドラが特定タイプのエラーを処理できない場合、パイプライン エラー ハンドラが呼び出されます。パイプライン レベルのエラー ハンドラもそのエラーを処理できない場合は、サービス レベルのエラー ハンドラが呼び出されます。サービス レベルのエラー ハンドラも処理できない場合、システムがエラーを処理します。次の表に、メッセージ フローのさまざまなレベルにおけるエラー ハンドラのスコープの概要を示します。
| 注意 : | エラー ハンドラのスコープには例外があります。たとえば、ステージ レベルの非 XML トランスフォーメーションによって送出された例外を捕捉するのは、サービス レベルのエラー ハンドラのみです。プロキシ サービスの送信応答メッセージ用に XML から MFL に変換する場合、このトランスフォーメーションは常にバインディング レイヤで発生します。したがって、たとえば、非 XML 出力でステージ レベルの必須フィールドが失われた場合、サービス レベルのエラー ハンドラのみがこのエラーを捕捉できます。 |
エラー メッセージとエラー処理の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : エラー ハンドラ」にある「エラー メッセージと処理」を参照してください。
アサーションが true であるかどうかを確認するテストをコンフィグレーションすることでエラーを処理できます。また、失敗にコンフィグレーションされている応答アクションを使用できます。このテストはさまざまなレベルで繰り返すことができます。また、下位レベルでエラー ハンドラのない状態でエラーが発生した場合は、メッセージ フローの上位レベルでエラー ハンドラを使用してそのエラーを処理できます。通常、メッセージ フローのステージ レベルで特定のエラーを処理し、下位レベルでは処理されないエラーのデフォルト処理を上位レベルで行うほうが簡単です。予期されるエラーをパイプラインで明示的に処理し、予期されないエラーをサービスレベルのハンドラで処理することをお勧めします。
| 注意 : | サービス レベルで処理できるのは、WS-Security 関連のエラーのみです。 |
メッセージ処理中に発生したエラーに関する情報はすべて、事前定義されたコンテキスト変数 (fault 変数) に保持されます。エラーが発生すると、この変数に情報が格納されてから、適切なエラー ハンドラが呼び出されます。この fault 変数はエラー ハンドラ パイプラインでのみ定義され、要求パイプラインや応答パイプライン、ルート ノードやブランチ ノードでは設定されません。$fault の詳細については、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」にある「事前定義されたコンテキスト変数」を参照してください。
要求/応答型の着信メッセージでのエラー発生時には、多くの場合、エラーが発生した理由を説明するメッセージを送信元に返送する必要があります。そのためには、送信する応答に対してメッセージ コンテキスト変数をコンフィグレーションした後、失敗時の返信アクションを使用します。たとえば、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 の使い方』の「プロキシ サービス : アクション」を参照してください。
この例では、エラー ハンドラに Report アクションと Reply アクションをコンフィグレーションする方法を示します。図 2-2 のメッセージ フローでは、validate loan application ステージにエラー ハンドラがあります。このエラー ハンドラは、1 つのステージがコンフィグレーションされた単純なメッセージ フローです。AquaLogic Service Bus Console には次のように表示されます。
ステージは次の図に示すように、アクション (置換、レポート、および返信) でコンフィグレーションされています。
アクションによって、パイプライン エラー ハンドラのステージの動作が次のように制御されます。
fault コンテキスト変数のコンテンツで置換されます。body 変数の要素は XPath 式で指定します。コンテンツは、XQuery 式で返される値で置換されます。この例では $fault/ctx:reason/text() です。
エラーが発生すると、fault コンテキスト変数のコンテンツがレポートされます。キー名は errorCode です。キー値は ./ctx:errorCode という XPath 式を使用して fault 変数から抽出されます。キーと値のペアをキー識別子として使用して、実行時にダッシュボードでこれらのメッセージを識別します。
レポート アクションをコンフィグレーションし、実行時にレポートされるデータを使用する方法については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」を参照してください。
コンフィグレーションについては、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : エラー ハンドラ」にある「エラー メッセージと処理」を参照してください。
AquaLogic Service Bus は、従来の Web サービス (WSDL で XML または SOAP バインディングを使用) から非 XML サービスや汎用サービスまで、多くのサービス タイプに対応しています。この節では、サービス タイプを選択する際のガイドラインを示します。
AquaLogic Service Bus に含まれるプロキシ サービスのサービス タイプは次のとおりです。
<soap:Envelope> 要素内の header 変数および body 変数のコンテンツをラップすることで作成されます。| 注意 : | すべてのタイプのサービスで、MIME を使用した添付ファイルの送受信が可能です。 |
| 注意 : | サービス タイプの選択方法の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービスの追加」を参照してください。 |
次の表に、AquaLogic Service Bus でサポートされるサービスのタイプと転送方式を示します。
| 注意 : | HTTP GET に対応しているサービスのタイプは、XML (WSDL なし) サービスとメッセージング サービスのみです。 |
| 注意 : | 転送型付きのビジネス サービスが対応しているのは、EJB タイプのみです。 |
2 つのプロキシ サービス間の通信にはローカル転送を使用することをお勧めします。ローカル転送の詳細については、「ローカル転送」を参照してください。
サービスに Web Services Description Language (WSDL) インタフェースが明確に定義されている場合、WSDL を使用してサービスを定義することをお勧めします。これは必須ではありません。AquaLogic Service Bus の WSDL リソースの詳細については、『AquaLogic Service Bus Console の使い方』の「WSDL」を参照してください。
3 タイプの WSDL を定義できます。次の 3 タイプです。
ドキュメント ラップの Web サービスは、ドキュメント スタイルのサービスとして WSDL に記述されています。ただし、いくつかの追加規約に従います。標準のドキュメント指向の Web サービス操作では、1 つのパラメータまたはメッセージ部分のみ取得します。通常、XML ドキュメントを取得します。つまり、操作を実装する方法にも 1 つのパラメータしか含まれている必要がありません。ただし、ドキュメント ラップの Web サービスでは、パラメータ値が SOAP メッセージ内の 1 つの複雑なデータ型にラップされますが、いくつでもパラメータを取得できます。このラップされた複雑なデータ型は、操作の単一ドキュメントとして WSDL に記述されます。
SOAP ドキュメント ラップの Web サービスの詳細については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービスの追加」を参照してください。
プロキシ サービスは SOAP 型プロキシ サービスとして、ビジネス サービスは SOAP 型ビジネス サービスとしてそれぞれコンフィグレーション可能です。
次のコード リストに、ドキュメント型 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) の値を次のコード リストに示します。
| 注意 : | 次のコード リストでは、わかりやすくするために XML からネームスペース宣言が削除されています。 |
<soap-env:body>
<req:purchaseorg>BEA Systems</req:purchaseorg>
</soap-env:body>
コード リスト 2-2 では、soap-env は事前定義された SOAP ネームスペース、req は PurchaseOrg 要素のネームスペース (<http://example.com/lookup/docs>) です。
プロキシ サービスからルーティングされるビジネス サービスで上記の WSDL を使用した場合、上記の body 変数 ($body) の値はプロキシ サービスの body 変数 ($body) の値になります。
プロキシ サービスが受信する、呼び出されたビジネス サービスからの応答の body 変数 ($body) の値を、次のコード リストに示します。
| 注意 : | 次のコード リストでは、わかりやすくするために XML からネームスペース宣言が削除されています。 |
<soap-env:body>
<req:legacyboolean>true</req:legacyboolean>
</soap-env:body>
これは、この WSDL を使用するプロキシ サービスによって返される応答の body 変数 ($body) の値でもあります。
BEA WebLogic Workshop ツールをはじめとする多くのツールでは、プロキシ サービスの WSDL (ブラウザで、プロキシ サービスの URL に ?WSDL サフィックスを追加することで取得可能) を受け取り、適切な要求パラメータと応答パラメータを持つ Java クラスを生成して、サービスのオペレーションを呼び出します。この Java クラスで、この WSDL を使用するプロキシ サービスを呼び出すことができます。
プロキシ サービスは RPC 型プロキシ サービスとして、ビジネス サービスは RPC 型ビジネス サービスとしてそれぞれコンフィグレーション可能です。
次のコード リストに、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 を使用するプロキシ サービスを呼び出すことができます。
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 ポートにサービスをバインドするのが便利です。理由は次のとおりです。
(テンプレート WSDL は、プロキシ サービスの基礎として使用するサービスの WSDL です。生成される WSDL は、新しいプロキシ サービスに対して作成される WSDL です。)
<service-name>QSService および <port-name>QSPort)。テンプレート WSDL で定義されたどのポートも、生成される WSDL には含まれません。
次の URL をブラウザのアドレス フィールドに入力することで、HTTP または HTTPS ベースのプロキシ サービスの WSDL を取得できます。
http://host:port/sbresource?PROXY/project/proxyname
プロキシ サービスが WSDL のポートにバインドされ、プロキシ サービスの URL が WSDL の URL に正しく反映されている場合、プロキシ サービスの URL から取得した URL (http://host:port/sbresource?PROXY/project/proxyname) または WSDL によって返される WSDL ではそのポート名が保持されます。これは、クライアントを生成するいくつかのツールでは重要な事項です。ビジネス サービスのデフォルト URL として WSDL ポートの URL を作成する場合を除いて、サービスを定義する際に、サービスにバインドされる WSDL ポートの URL は使用されません。サービス定義を行う際に、転送コンフィグレーション画面で転送方式と転送 URL を上書きできます。
ポート レベルのすべての WS-Security ポリシーに適用されます。『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」にある「プロキシ サービスの概要」を参照してください。
1 つのポートだけをエクスポーズしてクライアントにさまざまなエンタープライズ アプリケーションを提供する場合は、[任意の SOAP サービス] または [任意の XML サービス] を使用します。
要求または応答メッセージの 1 つが非 XML の場合、サービス タイプとしてメッセージングを使用する必要があります。
AquaLogic Service Bus では、"misunderstand" SOAP ヘッダのチェックは自動では行われません。ただし、XQuery 条件式および検証アクションを使用してこのようなチェックを明示的に行うことができます。検証アクションの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス : アクション」にある「検証」を参照してください。XQuery 条件式の詳細については、『AquaLogic Service Bus Console の使い方』のプロキシ サービス : エディタにある「XQuery 条件エディタの使用」を参照してください。
AquaLogic Service Bus を使用し、メッセージ フローで検証アクションをコンフィグレーションして XQuery 条件式を使用することで、明示的に検証チェックを行うことができます。
サービスのタイプの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」にある「プロキシ サービスの概要」を参照してください。
AquaLogic Service Bus には、AquaLogic Service Bus に登録されたリソースをエクスポーズする際に使用するリソース サーブレットが用意されています。AquaLogic Service Bus に登録されているリソースは次のとおりです。
リソースのエクスポーズに使用する URL の形式は次のとおりです。
次の URL 形式を使用して、リソースの詳細をエクスポーズできます。
| 注意 : | AquaLogic Service Bus でリソースのエクスポーズに使用する URL は、特殊文字をエスケープするために UTF-8 でコード化する必要があります。 |
作成するプロキシ サービスから呼び出す必要があるサービスがわからない場合に、動的ルーティングを使用できます。
どのプロキシ サービスでも、以下のいずれかの方法を使用して、メッセージを動的にルーティングできます。
| 注意 : | 動的ルーティングはルート ノードで使用でき、動的パブリッシュは要求パイプラインまたは応答パイプラインのステージで使用できます。 |
この方法を使用すると、プロキシ サービスでは、エンドポイント ビジネス サービスのサービス アカウントを動的に使用して、ユーザ名とパスワードをその発信要求に送信します。たとえば、プロキシ サービスがビジネス サービス A に要求をルーティングする場合、プロキシ サービスではビジネス サービス A のサービス アカウントを使用して、ユーザ名とパスワードをその発信要求に送信します。「動的ルーティングの実装」を参照してください。
この方法を使用すると、要求の送信先の URI に関係なく、ユーザ名とパスワードをその発信要求に送信するために、プロキシ サービスは静的に定義されたビジネス サービスのサービス アカウントを使用します。
この方法の使用方法については、「動的ルーティングの実装」を参照してください。
| 注意 : | この方法は、インタフェースの概要が確定している場合に使用します。インタフェースの概要には、メッセージのタイプ、ポート タイプ、およびバインディングが含まれます。具象インタフェースは含まれません。具象インタフェースは、サービスが配置されている転送 URL です。 |
動的ルーティングを使用すると、プロキシ サービスの実行時に送り先を確定できます。これを行うには、XML ファイルのルーティング テーブルを使用して、XQuery リソースを作成します。
| 注意 : | XQuery リソースを使用する代わりに、リソースの作成元の XML ファイルを直接使用することもできます。 |
XML ファイルまたは XQuery リソースは容易に保持できます。実行時に、プロキシ サービスのルーティング先またはパブリッシュ先を決定するルーティング テーブルにエントリを指定します。XML ファイルまたは XQuery リソースには、論理的な識別子 (企業名など) を物理的な識別子 (AquaLogic Service Bus のサービスの完全修飾名) にマップするルーティング テーブルが含まれています。メッセージから抽出された論理的な識別子は、呼び出すサービスの名前である物理的な識別子にマップされます。
| 注意 : | 動的ルート アクションを使用するには、AquaLogic Service Bus のサービスの完全修飾名が必要です。 |
パイプラインでは、論理的な修飾子は XPath を使用してメッセージに取得されます。XQuery リソースの XML テーブルを変数に割り当てます。ルーティング テーブルの変数にクエリを実装し、対応する論理的な修飾子に基づいて物理的な修飾子を抽出します。この変数を使用すると、必要なサービスを呼び出すことができます。以下の節では、動的ルーティングの実装方法を説明します。
以下の XML ファイルから XQuery リソースを作成できます。sampleXquery.xml としてこれを保存します。
<routing>
<row>
<logical>BEA Systems</logical>
<physical>default/goldservice</physical>
</row>
<row>
<logical>ABC Corp</logical>
<physical>default/silverservice</physical>
</row>
</routing>
| 注意 : | これを行うには、手順 11 から 13 を繰り返します。 |
<ctx: route>
<ctx: service>{$routingtable/row[logical/text()=$logicalidentifier]/physical/text()}</ctx: service>
</ctx: route>
上記のコードで、$logicalidentifier を実際の XPath で置換して、メッセージ ($body など) から論理的な識別子を抽出します。
これにより、動的ルート アクションが使用する XML をこの変数に抽出します。
メッセージ コンテキストは、メッセージが 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 と呼ばれるラッパー要素が含まれ、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> 要素内の header 変数および body 変数のコンテンツをラップすることで作成される。body 変数に参照 XML が格納されている場合、この参照 XML が送信されます。つまり、参照されているコンテンツはメッセージに追加されません。
非 SOAP サービスの場合、$body の Body 要素に binary-content 要素が格納されると、対象サービスのタイプに関係なく、内部的に格納された参照先コンテンツがそのまま送信されます。
詳細については、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」を参照してください。
メッセージ コンテキスト変数の型は、メッセージ コンテキスト スキーマ (MessageContext.xsd) によって定義されます。BEA XQuery Mapper でメッセージ コンテキスト変数を使用して作業を行う場合は、MessageContext.xsd と転送固有スキーマを参照する必要があります。このスキーマは、AquaLogic Service Bus インストールの以下の場所の JAR ファイル内にあります。
<BEA_HOME>\weblogic92\servicebus\lib\sb-schemas.jar
ここで、BEA_HOME は AquaLogic Service Bus をインストールしたディレクトリを表します。
メッセージ コンテキスト スキーマおよび転送固有スキーマについては、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」にある「メッセージ コンテキスト スキーマ」を参照してください。
メッセージ コンテキストを検査または変更するときには、以下のガイドラインを考慮してください。
Content-Description を取得します。 $attachments/ctx:attachment[1]/ctx:content-Description
$attachments/ctx:attachment[2]/ctx:body/*
idvar という変数に割り当てる場合、割り当てアクションを次のように指定します。 assign data($header/wsa:messageID to variable idvar
| 注意 : | 上記の例で 2 つの WS-Addressing MessageID ヘッダが存在する場合、idvar 変数には最初の MessageID ヘッダの値が割り当てられます。 |
$header、$body、および $attachments が空になることはありません。ただし、$header には空の SOAP Header 要素、$body には空の SOAP Body 要素、$attachments には空の attachments 要素がそれぞれ含まれる場合があります。$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 では、BEA XQuery Mapper などの外部ツールで作成された XQuery をインポートできます。これらの XQuery は、プロキシ サービスのメッセージ フローのどの場所にも使用できます。XQuery リソースの入力をインライン XQuery にバインドし、XQuery リソースの出力をアクションにバインドすることで、その結果が割り当てアクション、置換アクション、挿入アクションなどの入力として使用されます。
ただし、XQuery をリソースとして入力するのではなく、アクションの定義の一部としてインラインで入力することができます。If...Then... アクションの条件にインライン XQuery を使用することもできます。
インライン XQuery 式エディタは、以下で構成される簡単な XQuery を入力するときに使用します。
| 注意 : | より複雑な XQuery については、XQuery に慣れていない場合は特に、XQuery Mapper を使用することをお勧めします。 |
インライン XQueries は、次のような場合に使用すると効率的です。
$header または $body に含まれる SOAP エンベロープの要素からビジネス ドキュメントまたは RPC パラメータを抽出する、またはアクセスする。$attachments に含まれる添付ドキュメントを抽出する、またはアクセスする。 for loop を実行するために SOAP エンベロープからシーケンスを抽出する。 for loop 内のシーケンスの項目を更新する。| 注意 : | インライン XQuery 式エディタを使用して、変数の構造を作成することもできます。詳細については、「変数の構造の使用」を参照してください。 |
インライン XQuery 式エディタを使用すると、変数の構造を作成することができます。これにより、設計の目的で特定の変数の構造を定義できます。たとえば、XPath 変数の XML スキーマを表示するよりも、コンソールで XPath 変数を参照する方が容易です。
| 注意 : | ランタイムを作動させるために変数の構造を作成する必要はありません。変数の構造によって、変数の構造や変数パスが定義されますが、変数は作成されません。変数は、ステージでの割り当てアクションの対象として実行時に作成されます |
一般的なプログラミング言語において、変数のスコープ (有効範囲) は静的です。変数の名前と型が明示的に宣言されます。定義された静的なスコープ内の任意の場所から変数にアクセスできます。
AquaLogic Service Bus にはいくつかの事前定義された変数が存在しますが、変数を動的に作成し、割り当てアクションまたは for ループ内のループ変数を使用して変数に値を割り当てることもできます。変数に値を割り当てると、プロキシ サービスのメッセージ フローの任意の場所から変数にアクセスできるようになります。変数の型は宣言されませんが、原則として、任意の時点で変数に格納されている基礎になる値の型が変数の型になります。
| 注意 : | for ループの変数のスコープは制限されており、ステージ外からはアクセスできません。 |
インライン XQuery 式エディタを使用すると、XQuery には 0 以上の入力と 1 つの出力が含まれます。式エディタそのもので入力と出力の構造を表示できるため、インライン XQuery を作成するときに、XML スキーマまたは WSDL リソースを開いて構造を確認する必要はありません。構造が視覚的に表示されるため、作成中の XQuery に述部を指定せずに、child 軸に沿って単純な変数パスをドラッグ アンド ドロップすることができます。
変数の構造のマッピングでは、各エントリはラベルを持ち、変数または変数パスを 1 つまたは複数の構造にマップします。これらのマッピングのスコープはステージまたはルート ノードです。変数は静的に型指定されないので、1 つの変数がステージまたはルート ノードのさまざまな位置 (または同じ位置) で複数の異なる構造を持つことができます。つまり、1 つの変数または変数パスを複数の構造にマップし、それぞれに異なるラベルを使用することができます。構造を表示するには、ドロップダウン リストで対応するラベルを選択します。
| 注意 : | インライン XPath 式エディタでも変数の構造のマッピングを作成できます。ただし、変数または変数パスは構造にマップされますが、構造から選択したときに生成される XPath は、変数を基準にした相対 XPath です。./ctx:attachment/ctx:body は、相対 XPath の一例です。 |
以下の節では、さまざまなタイプの変数の構造のマッピングを作成する方法について説明します。
このサンプル 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 を使用するサンプルのビジネス サービスとプロキシ サービスを作成します。
SampleWSDL」と入力します。このフィールドは必須です。| 注意 : | このフィールドは必須です。 |
SampleWSDL がリソースのリストに追加され、現在のセッションで保存されます。次は、この WSDL を使用するプロキシ サービスを作成する必要があります。「サンプル WSDL を使用するプロキシ サービスの作成」を参照してください。ProxywithSampleWSDL」と入力します。このフィールドは必須です。ProxywithSampleWSDL がリソースのリストに追加され、現在のセッションで保存されます。このプロキシ サービスのメッセージ フローを構築するには、「サンプル プロキシ サービスのメッセージ フローの構築」を参照してください。ProxywithSampleWSDL プロキシ サービスの [メッセージ フローの編集] アイコンをクリックします。 ProxywithSampleWSDL] アイコンをクリックし、[パイプライン ペアの追加] をクリックします。PipelinePairNode1 が表示されます。ここには、要求パイプラインと応答パイプラインが含まれています。ProxywithSampleWSDL プロキシ サービスの基本的なメッセージ フローが作成されました。 BusinesswithSampleWSDL」と入力します。このフィールドは必須です。BusinesswithSampleWSDL がリソースのリストに追加され、現在のセッションで保存されます。
この例では、プロキシ サービス ProxyWithSampleWSDL を使用して事前定義された変数の構造を選択します。このサービスのタイプは、SampleWSDL のバインディング POBinding を使用する WSDL Web サービスです。
プロキシ サービスのメッセージ フローが、処理するメッセージの構造を認識している必要があります。このために、AquaLogic Service Bus では事前定義された構造が自動的に提供されます。この構造は、インタフェースのすべてのメッセージで、プロキシ サービスの WSDL での定義に従って、body 変数を SOAP 本体の構造にマップします。この事前定義された構造のマッピングのラベルは body です。
| 注意 : | この事前定義された構造は、型付きインタフェースを備えたメッセージング サービスのためにもサポートされています。 |
[XQuery 式エディタ] ページの [変数の構造] パネルで、組み込み構造のドロップダウン リストから [body] を選択します。
プロキシ サービス ProxyWithSampleWSDL が、ビジネス サービス BusinessWithSampleWSDL へのサービス コールアウトを呼び出すとします。このビジネス サービスも、サービスのタイプは SampleWSDL のバインディング POBinding を使用する WSDL Web サービスです。操作 GetInvoiceType が呼び出されます。
この例では、メッセージ フローが、処理する応答パラメータの構造を認識する必要があります。このためには、応答パラメータ変数を型 InvoiceType にマップする新しい変数の構造を作成します。
InvoiceType」と入力します。この表示名を使用すると、実行時には影響を及ぼさず設計時に構造を認識できるように、構造に意味のある名前を付けることができます。$InvoiceType」と入力します。
一時変数には、SampleWSDL WSDL で記述された要素 Invoice が含まれているとします。この例では、ProxyWithSampleWSDL メッセージ フローは、この変数にアクセスする必要があります。このためには、変数を要素 Invoice にマップする新しい変数の構造を作成します。
プロキシ サービス ProxyWithSampleWSDL は、ドキュメント スタイルが任意の SOAP であるビジネス サービスにルーティングします。このビジネス サービスは、SOAP 本体の発注書を返します。この例では、ProxyWithSampleWSDL プロキシ サービスのメッセージ フローが、その応答を処理する必要があります。このためには、body 変数を PO 要素にマップする新しい構造を作成し、PO 要素を変数の子要素として指定します。body 変数には SOAP Body 要素が格納され、PO 要素は Body 要素の子であるため、子要素として指定する必要があります。
body to PO$body」と入力します。PO 要素を選択するには、次の手順に従います。 PO 要素を body to PO 変数の構造の子として設定するために、[子として設定] チェックボックスを選択します。
プロキシ サービス ProxyWithSampleWSDL は、ビジネス サービス BusinessWithSampleWSDL にメッセージをルーティングします。このビジネス サービスも、サービスのタイプは SampleWSDL のバインディング POBinding を使用する WSDL Web サービスです。この例では、メッセージ フローが応答を処理する必要があります。このためには、body 変数を BusinessWithSampleWSDL ビジネス サービスにマップする新しい構造を定義します。これにより、サービスの WSDL インタフェースで、すべてのメッセージの SOAP 本体に body 変数がマップされます。
| 注意 : | このマッピングは、型付きインタフェースを備えたメッセージング サービスのためにもサポートされています。 |
BusinessService」と入力します。$body] が設定されています。これは、実行時の変数の構造のパスになります。BusinessService が変数の構造のドロップダウン リストの [サービス インタフェース] の下に追加されます。
ProxyWithSampleWSDL プロキシ サービスが単一の添付ファイルを受信するように、SampleWSDL を変更します。添付ファイルは発注書です。この例では、プロキシ サービスのメッセージ フローが発注書を処理する必要があります。このためには、$attachments の body 要素を、子要素として指定されている PO 要素にマップする新しい構造を定義します。body 要素は、以下の形式の変数パスとして指定されます。
$attachments/ctx:attachment/ctx:body
事前定義された attachments 構造の body 要素を選択してコピーし、新しいマッピング定義でマップされる変数パスとして貼り付けます。
変数の構造 attachments は次のように表示されます。
body 子要素を選択します。ページの右側にある [プロパティ インスペクタ] に body 要素の変数パスが表示されます。 $attachments/ctx:attachment/ctx:bodybody 要素の変数パスをコピーします。PO attachment」と入力します。$attachments/ctx:attachment/ctx:bodyPO 要素を選択するには、次の手順に従います。 PO attachment が変数の構造のドロップダウン リストの [XML の種類] の下に追加されます。
$attachments/ctx:attachment/ctx:body/bea:PO/bea:id
以下の節では、AquaLogic Service Bus メッセージングのサービス品質機能について説明します。
BEA AquaLogic Service Bus は、信頼性の高いメッセージ機能を備えています。発信コンテキスト変数の qualityOfService 要素の値により、望ましい配信動作の提案が AquaLogic Service Bus に提供されます。メッセージがルート ノードから別のサービスにルーティングされる場合、$outbound のデフォルトの Quality of Service 要素は exactly-once または best-effort のいずれかになります。
次に、AquaLogic Service Bus に用意された配信の保証のタイプを示します。
次のアクションについてデフォルトの qualityOfService 要素属性をオーバーライドできます。
qualityOfService 要素属性をオーバーライドするには、ルート オプション アクションを使用してルーティングまたはパブリッシュし、サービス コールアウト アクションのチェックボックスを選択する必要があります。『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」にある「メッセージ コンテキスト スキーマ」を参照してください。
プロキシ サービスがメッセージをパブリッシュするか、要求をビジネス サービスにルーティングするときは、次の条件に応じて配信の保証がサポートされます。
ただし、着信プロキシ サービスがローカル転送で、呼び出し元が別のプロキシ サービスである場合、呼び出し元のプロキシ サービスの着信転送が配信の保証を行います。呼び出されたプロキシ サービスの転送がローカル転送の場合、呼び出し元のプロキシ サービスが最適化されて、直接呼び出しになるためです。転送プロトコルの詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービス」にある「プロキシ サービスの追加」および「ビジネス サービスの追加」を参照してください。
| 注意 : | プロキシ サービスからの応答には配信の保証はありません。 |
| 注意 : | JMS により配信の保証として「少なくとも 1 回」および「必ず 1 回」をサポートするには、JMS トランザクションを利用し、サーバがクラッシュした場合、または返信アクションや再開アクションのエラー ハンドラで処理できないエラーが発生した場合にメッセージを再配信できるように、JMS キューの再試行回数と再試行間隔をコンフィグレーションする必要があります。ファイル、FTP、および電子メール転送でも、内部では JMS/XA キューが使用されます。JMS/XA 転送を使用したプロキシ サービスのデフォルトの再試行回数は 1 です。AquaLogic Service Bus で作成されるデフォルトの JMS キューのリストについては、AquaLogic Service Bus のデプロイメント ガイドを参照してください。 |
qualityOfService 要素が exactly-once に設定されている場合、トランザクション対応の送り先への要求フローで実行されるルート ノードおよびパブリッシュ アクションは、同じトランザクションで実行される。qualityOfService 要素が best-effort に設定されている場合、サービス コールアウト アクションまたはパブリッシュ アクションは、要求フローのトランザクションとは別に実行される。特に、JMS、Tuxedo、トランザクション対応の Tuxedo、または EJB タイプの転送の場合、要求フロー トランザクションはサスペンドされ、トランザクション対応の Tuxedo の処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。qualityOfService 要素が exactly-once に設定されている場合、すべてのルート、サービス コールアウト、およびパブリッシュ アクションは同じトランザクションで実行される。 qualityOfService 要素が best-effort に設定されている場合、すべてのパブリッシュ アクションおよびサービス コールアウト アクションは、応答フローのトランザクションとは別に実行される。特に、JMS、EJB、または転送のタイプがトランザクション対応の Tuxedo の場合、応答フロー トランザクションはサスペンドされ、サービス呼び出しの処理はトランザクションなしで、またはすぐにコミットされる別のトランザクションで実行されます。qualityOfService 要素の設定に関係なく、常に同じトランザクションで実行される。| 注意 : | 着信転送がトランザクション対応の Tuxedo で、発信が JMS/XA などの非同期転送の場合、実行時エラーが発生します。 |
BEA AquaLogic Service Bus のスレッディング モデルは次のように作動します。
| 注意 : | 要求フローまたは応答フローのパブリッシュ アクションでは、応答は必ず破棄されます。パブリッシュ アクションは本質的に一方向送信メッセージであるためです。 |
loanGateway1) が別のプロキシ サービス (たとえば loanGateway2) を呼び出すときに、JMS 以外の転送について直接呼出しの最適化を無効にするには、プロキシ サービス loanGateway1 からプロキシ サービス loanGateway2 にルーティングする (プロキシ サービス loanGateway2 が JMS 転送を使用する場合)。qualityOfService 要素に exactly-once を指定し、XA 接続ファクトリを使用します。
JMS を使用してメッセージの着信の再試行をコンフィグレーションするだけでなく、発信の再試行およびロード バランシングもコンフィグレーションできます。ロード バランシング、フェイルオーバ、および再試行の組み合わせによって、パフォーマンスと高可用性を実現できます。各メッセージのフェイルオーバ 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 ではエラーにならない可能性があります。 |
| 注意 : | quality of serviceが exactly once の場合、フェイルオーバや再試行は行われません。 |
AquaLogic Service Bus では、異種のエンドポイント間での相互運用性を確保するため、使用されるコンテンツ タイプ、JMS タイプ、およびエンコーディングをそれぞれ制御できます。
AquaLogic Service Bus では外部のクライアントまたはサービスに必要な情報は想定されず、サービス定義でコンフィグレーション済みの情報が使用されます。発信メッセージのコンテンツ タイプは、サービス タイプとインタフェースから派生します。コンテンツ タイプは、電子メールおよび HTTP(S) プロトコルの一部です。
また、JMS タイプにはバイトまたはテキストを指定できます。AquaLogic Service Bus Console でサービスを定義するときに、使用する JMS タイプをコンフィグレーションします。
サービスを呼び出すプロキシ サービスの発信コンテキスト変数 ($outbound) のコンテンツ タイプ、およびプロキシ サービス応答の着信コンテキスト変数 ($inbound) のコンテンツ タイプはオーバーライドできます。$outbound コンテキスト変数および $inbound コンテキスト変数の詳細については、『AquaLogic Service Bus Console の使い方』の「メッセージ コンテキスト」を参照してください。
すべての発信メッセージのエンコーディングも、サービス定義で明示的にコンフィグレーションします。サービス定義の詳細については、『AquaLogic Service Bus Console の使い方』の「プロキシ サービスの追加」、および「ビジネス サービスの追加」を参照してください。
通常、抑制パターンは、同時実行性の度合いを制限するために HTTP Web サービスで使用します。応答のない未完了の要求の数を制限以下に維持するためのものです。ビジネス サービスに直接アクセスするのではなく、別のプロキシ サービスを介してビジネス サービスにアクセスします。通常、このプロキシ サービスでは、JMS 一方向の転送または JMS 要求応答の転送を使用してビジネス サービスと通信します。JMS 要求キューにワーク マネージャを定義する必要があります。ワーク マネージャの定義の詳細については、「ワーク マネージャ」を参照してください。ワーク マネージャには、スレッド数の最大数をコンフィグレーションします。これにより、要求キューに置かれる要求の数が制限されます。つまり、受信要求の数が、ワーク マネージャにコンフィグレーションされたスレッドの最大数を超えた場合、要求をキューに置くことはできません。
| 注意 : | ビジネス サービス $outbound の qualityOfService を Exactly Once に設定します。ルーティング オプション アクションを使用すると、必要な qualityOfService を設定できます。詳細については、『AquaLogic Service Bus Console の使い方』の「ルーティング オプション」を参照してください。 |
| 注意 : | 抑制パターンをクラスタに実装すると、すべての管理対象サーバの要求合計数は、 ワーク マネージャの最大スレッド数/管理対象サーバ数になります |
BEA AquaLogic Service Bus は、実行時環境で Web サービス相互運用性 (WS-I) 準拠を提供します。WS-I の基本プロファイルの目的を以下に示します。
WS-I 基本プロファイルは、次の URL で入手できます。
http://www.ws-i.org/Profiles/BasicProfile-1.1.html.
プロキシ サービスまたはビジネス サービスを WSDL に基づいてコンフィグレーションするとき、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 準拠の適用] チェックボックスは、図 2-15 のように表示されます。
![[WS-I 準拠の適用] チェックボックス](wwimages/wsi_compliance.gif)
| 注意 : | WS-I 準拠チェックでは、サービスで呼び出される操作をシステムが認識する必要があります。つまり、プロキシ サービスが受信する要求メッセージでは、コンテキスト変数 $operation は null 以外の値であることが必要です。そのためには、操作選択アルゴリズムが適切にコンフィグレーションされていることが前提になります。呼び出されたサービスから受信する応答メッセージでは、ルート、パブリッシュ、およびサービス コールアウトのアクション コンフィグレーションで操作が指定されている必要があります。 |
プロキシ サービスまたはビジネス サービスの WS-I 準拠チェックをコンフィグレーションすると、AquaLogic Service Bus によって以下のチェックが実行されます。
  
|
