|
|
この節では、Oracle Service Bus のサービス構成機能について説明します。サービス コンフィグレーションを可能にする操作機能、メッセージ構造とメッセージ フローの作成に関連する主要な概念について取り上げます。統合を目的とする IT 設計者で、メッセージングとサービス指向アーキテクチャ (SOA) の担当者、サービス モデル作成者または設計者を対象としています。この節では、以下のトピックについて説明します。
Oracle Service Bus は種類の異なるサービス エンドポイント間でサービス要求と応答メッセージを仲介し、これらの間でメッセージをインテリジェントにルーティングします。コンテンツ ベースのルーティングは、Oracle Service Bus が条件付きメッセージの処理とトランスフォーメーション機能に基づいてサポートする仲介機能です。このルーティング機能により、SOA のエンドポイントを疎結合できるのが特に有益であり、またトランスフォーメーションとルーティング機能を組み合わせることによってサービスへの情報の付加と再利用を可能にします。
Oracle Service Bus では、サービスまたは応答を複数の送り先サービスに転送する必要がある場合や、異なるバージョンのサービスをビジネス サービスの要求に基づいてプロビジョニングする必要があるシナリオでは、メッセージのコンテンツに基づいた動的なメッセージのルーティングを行います。動的なルーティングは、ビジネス要件によって、要求の特定の条件により処理を行う場所が指定される場合に有効です。たとえば、金融機関が顧客の信用に関するレポートを要求するときは、その顧客または組織がある場所に基づいて複数の信用サービスを使用することになります。
動的なルーティングでは、ルーティングのロジックを決定する 1 つまたは複数のデータ要素の値を取得するために、メッセージは条件付きブランチ文の条件チェックを使用して分析されます。この条件チェックの結果、異なる値の組み合わせに、異なるビジネス サービスの送り先が割り当てられます。メッセージは、このデータ要素の値に基づいて、複数の送り先ビジネス サービスのいずれか 1 つに動的にルーティングされます。ビジネス サービスの要件に応じて、これらの 1 つまたは複数の送り先に向かう応答メッセージにトランスフォーメーションが適用されることがあります。
Oracle Service Bus では、ビジネス サービス (エンタープライズ サービスやデータベースなど) とサービス クライアント (プレゼンテーション アプリケーションやその他のビジネス サービスなど) との間でプロキシ サービスを介してメッセージをルーティングします。次の節では、コンテンツ ベースのルーティングをサポートするプロキシ サービスの設計と実装に利用できる Oracle Service Bus の機能について詳しく説明します。
プロキシ サービスとは、Oracle Service Bus でローカルにホストされる汎用の仲介 Web サービスを定義したものです。プロキシ サービスは IT インフラストラクチャ内の他のサービスとインタフェースを通じて通信しますが、このインタフェースはサービス プロバイダやサービス コンシューマのビジネス サービスと同一である場合も、同一でない場合もあります。プロキシ サービスでは、コンフィグレーション済みの独立したインタフェースを使用して、メッセージを複数のビジネス サービスにルーティングできます。プロキシ サービスの詳細については、『Oracle Service Bus Console の使い方』の「プロキシ サービス」を参照してください。
プロキシ サービスは Oracle Service Bus Console を使用して定義とコンフィグレーションが行えます。プロキシ サービスは、インタフェース、使用する転送の種類、関連付けられるメッセージ処理ロジックを指定することでコンフィグレーションされます。プロキシ サービスのメッセージ処理機能は、メッセージ フローの定義を使用して実装されます。メッセージ フローの定義の詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「Oracle Service Bus でのメッセージ フローの作成」を参照してください。
プロキシ サービスが複数のビジネス サービスとのインタフェースを行う場合、メッセージ フローの定義は、メッセージが適切なビジネス サービスにルーティングされ、メッセージ データがビジネス サービスのインタフェースで必要なフォーマットにマップされるようにコンフィグレーションされます。プロキシ サービスの構造の詳細については、「メッセージ フローの作成」を参照してください。
ビジネス サービスとは、ビジネス プロセスにおいてメッセージを交換するエンタープライズ サービスの Oracle Service Bus による定義です。ビジネス サービスとそのインタフェースは、Oracle Service Bus Console を使用して定義およびコンフィグレーションできます。ビジネス サービスをコンフィグレーションするには、インタフェース、使用する転送の種類、セキュリティ要件、およびその他の特性を指定します。ビジネス サービスの定義はプロキシ サービスと似ていますが、パイプラインを持ちません。Oracle Service Bus Console を使用してビジネス サービスをコンフィグレーションする方法については、『Oracle Service Bus Console の使い方』の「ビジネス サービス」にあるビジネス サービスの追加を参照してください。
「サービス アカウント」は、ビジネス サービスに接続するときに認証を提供するために作成することができます。サービス アカウントは要求されるユーザ名とパスワードのペアのエリアス リソースとして機能します。詳細については、『Oracle Service Bus Console の使い方』の「ビジネス サービス」および「サービス アカウント」を参照してください。WebLogic Server を使用して、資格レベルの検証を要求するビジネス サービスのセキュリティ資格を直接管理できます。ビジネス サービスのセキュリティに関する考慮事項については、Oracle Service Bus の『セキュリティ ガイド』を参照してください。
Oracle Service Bus には、任意の SOAP または XML メッセージを受け入れる汎用のプロキシ サービスを作成する機能があります。これにより、背後にあるプロトコル仕様の複雑さをサービス コンシューマから隠すことができます。プロキシ サービスは、受信する SOAP または XML メッセージを分析して、コンテンツ ベースのルーティング ロジックによって動的にルーティングするようにコンフィグレーションできます。汎用テンプレートからプロキシ サービスを生成すると、動的なプロトコルの切り替えも促進されて、実行時にエンドポイント プロトコルを選択することができます。
メッセージ フローとは、Oracle Service Bus でプロキシ サービスの実装に使用される定義です。メッセージ フローの作成には、プロキシ サービスのメッセージ フローの定義におけるメッセージ処理ロジックのコンフィグレーションが関係します。このロジックには、トランスフォーメーション、パブリッシュ、レポート、例外管理などのアクティビティが含まれてます。各アクティビティは個別のアクションとしてメッセージ フロー内にコンフィグレーションされます。Workshop for WebLogic と Oracle Service Bus Console ではグラフィカルなモデリング ツールが使用でき、このツールでメッセージの作成を行うことができます。
Oracle Service Bus のプロキシ サービスの実装はメッセージ フローの定義において、パイプラインやブランチ ノード、ルート ノードなどのコンポーネントを使用して定義されます。次の図は、メッセージ フロー定義のコンポーネントの概要を示しています。
メッセージ フロー作成の詳細については、「Oracle Service Bus でのメッセージ フローの作成」
パイプラインとは、分岐のない一方向の処理の流れを表す名前付きのステージ シーケンスです。パイプラインは、サービスの要求と応答に対するメッセージ フローを指定するために使用します。パイプラインは次の 3 つのカテゴリに分類できます。
ステージにある 1 つのサービス レベル要求パイプラインは、必要に応じて複数のオペレーション パイプラインに分岐することができます (1 つのオペレーションに対して最大 1 つのオペレーション パイプラインと、必要に応じてデフォルトのオペレーション パイプライン)。オペレーションはユーザが選択する条件によって決定されます。応答処理は関連するオペレーション パイプラインから開始され、1 つのサービス レベル応答パイプラインに結合されます。次の図に、プロキシ サービスのオペレーション パイプラインの例を示します。
一方向のオペレーションでは、応答パイプラインは空のメッセージで実行されます。これにより、プロキシ サービスに応答を作成でき、双方向 (要求/応答) と一方向のオペレーションの間のブリッジングが可能になります。ブリッジング メカニズムとは、プロキシ サービスの入力が一方向であっても、出力は双方向 (要求/応答) になること (またはその逆) を意味します。プロキシ サービスは、呼び出したサービスからの応答を取得するか、クライアントへの応答を生成します。メッセージがビジネス サービスまたはプロキシ サービスにルーティングされてから、応答フローのアクションを使用してメッセージの後処理を実行することもできます。
ブランチ ノードを使用すると、可能ないくつかのパスのうちの 1 つに限定して処理を進ませることができます。ブランチ処理は、単純でありながらユニークなストリング値のタグが付いたブランチをまとめた簡単なルックアップ表を基準に行われます。メッセージ コンテキストの変数をそのノードのルックアップ変数として指定し、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ルックアップ変数の値は、ブランチ ノードに到達する前に設定する必要があります。このアプローチにより、そのブランチ ノード自体の中での例外の発生を防ぐことができます。ブランチ ノードでは、メッセージ フロー ツリー内にいくつかの子孫を持つことができます (デフォルトのブランチを含め各ブランチに 1 つずつ)。
ルート ノードは他のサービスとの要求通信と応答通信に使用されます。ルート ノードはプロキシ サービスの要求処理と応答処理の境界を表すので、メッセージ フロー ツリー内に子孫を持つことはできません。ルート ノードが要求メッセージをディスパッチすると、要求処理が終了したとみなされます。ルート ノードが応答メッセージを受信したときに、応答処理が始まります。
ルート ノードの仕様には非常に柔軟性があり、発信トランスフォーメーション、応答トランスフォーメーション、および条件付きルーティングに対応します。if 構造と case 構造を結合 (およびネスト) することができ、メッセージをルーティングするための単一のエンドポイントおよびオペレーションを定義できます。ルート ノードのコンフィグレーションの方法については、『Oracle Service Bus Console の使い方』の「プロキシ サービス」にある「ルート ノードの追加」を参照してください。
エコー ノードは要求パイプラインの末尾から応答パイプラインの先頭にメッセージをルーティング (エコー) するルート ノードです。メッセージは、プロキシ サービスから別のサービスへルーティングされずに、プロキシ サービス内に留まります。
パイプライン ロジックは、「要求パイプライン」定義と「応答パイプライン」定義で構成される 1 組の定義です。要求パイプライン定義は、ビジネス サービスまたは別のプロキシ サービスを呼び出す前に、プロキシ サービスへの要求メッセージに対して Oracle Service Bus が実行するアクションを指定します。応答パイプライン定義は、プロキシ サービスが応答を返す前に、プロキシ サービスによって呼び出されたサービスからの応答に対して Oracle Service Bus が実行する処理を指定します。ルーティングは、メッセージ フローの最後にルート ノードによって実行されます。
要求パスおよび応答パスを作成するには、要求パイプラインと応答パイプラインを合わせてペアにして、単一ルートのツリー構造に編成します。ブランチ ノードを使用すると、これらのパイプライン ペアを条件付きで実行して、ブランチ末尾のルート ノードで要求と応答のディスパッチを実行できます。パイプライン ツリーは、パイプライン ペア ノード、ブランチ ノード、ルート ノード、またはエコー ノードの最上位コンポーネントのインスタンスを連鎖させます。
パイプライン ペア ノードは、1 つの要求パイプラインと 1 つの応答パイプラインを 1 つの最上位要素に結び付けたものです。要求の処理中には要求パイプラインのみが実行され、応答処理のためにパスを逆に辿るときには応答パイプラインのみが実行されます。
各パイプラインは、アクションを含む一連のステージで構成されます。1 つのステージは、トランスフォーメーションやパブリッシュなどの、ユーザがコンフィグレーションする処理手順です。メッセージ フローに送られるメッセージには、メッセージのコンテンツを含む一連の「メッセージ コンテキスト変数」が付けられ、パイプライン ステージのアクションによってアクセスしたり変更することができます。
次の表は、Oracle Service Bus のパイプライン ステージ、ブランチ、およびルート ノードでサポートされるアクションを示します。
|
メッセージ フローは通常 WSDL ベースのサービスで使用されるため、操作に固有の処理は頻繁に実行されます。Oracle Service Bus では、操作に基づくブランチ ノードを手動でコンフィグレーションする必要はなく、自動的にブランチ処理を行うコンフィグレーション不要のブランチ ノードが用意されています。つまり、サービス エンドポイントでオペレーション ブランチがコンフィグレーションされていないと、メッセージの処理はメッセージ コンテキストで指定された操作に基づいて自動的に適切な操作にブランチ処理が行われます。
Oracle Service Bus には、より洗練されたメッセージ フローを実現して高い柔軟性を提供するサービス コールアウト アクションが用意されています。サービス コールアウトは、Oracle Service Bus に登録されている他のサービスを呼び出す、メッセージ フローからのメッセージ処理の要求アクションです。このアクションは一般に、複雑な動的ルーティング処理で行われる判断への応答で使用されるか、またはメッセージへの情報の追加を実行するために使用されます。サービス コールアウト アクションはメッセージ フローのルーティング ステージ内で使用され、メッセージについての何らかのアクションを実行するために送り先のサービスを呼び出します。呼び出されたサービスはメッセージ フローに応答を返し、これはローカル変数に割り当てられます。この変数は現在のメッセージ フロー内で条件付きブランチのために使用されます。
サービス コールアウト機能の詳細については、Oracle Service Bus の『ユーザーズ ガイド』の「Oracle Service Bus でのメッセージ フローの作成」にある「サービス コールアウト メッセージの作成」を参照してください。
サービス コールアウトを使用すると、カスタム Java コードをプロキシ サービス内から呼び出すことができます。Oracle Service Bus では、POJO (Plain Old Java Object、通常の従来型 Java オブジェクト) へのコールアウトを可能にする Java コールアウト アクションを使用した Java 終了メカニズムがサポートされます。POJO からは静的メソッドにアクセスすることが可能です。POJO およびそのパラメータは、設計時に Oracle Service Bus Console に表示されます。このパラメータは、メッセージ コンテキスト変数にマップできます。POJO への Java コールアウトのコンフィグレーションについては、『Oracle Service Bus Console の使い方』の「Java コールアウト アクションの追加」を参照してください。
トランスフォーメーションは、ソースと送り先のサービスで種類の異なるメッセージのデータ型が存在し、サービスの互換性を保つためにデータのマッピングが必要となる場合に使用されます。Oracle Service Bus は、XQuery および eXtensible Stylesheet Language Transformation (XSLT) 標準を使用したデータ マッピングに対応しています。メッセージは、次の 2 とおりの方法で変換されます。
トランスフォーメーションは開発者によって外部で作成され、Oracle Service Bus にインポートされるか、または Oracle Service Bus Console の XQuery を使用してスクリプトが作成されます。トランスフォーメーションはプロキシ サービスのメッセージ フロー コンフィグレーションに応じて、さまざまな場所で発生します。
Oracle Service Bus におけるメッセージ フローは、プロキシ サービスの実装を定義します。Oracle Service Bus Console を使用して Oracle Service Bus のプロキシ サービスをコンフィグレーションします。この方法は『Oracle Service Bus の使い方』で説明されています。
Oracle Service Bus は、XQuery および eXtensible Stylesheet Language Transformation (XSLT) 標準を使用したデータ マッピングに対応しています。XSLT マップは、XML から XML へのマッピングを記述するのに対して、XQuery マップでは、XML から XML、XML から非 XML、非 XML から XML へのマッピングを記述できます。トランスフォーメーションの詳細については、Oracle Service Bus の『ユーザーズ ガイド』にある「トランスフォーメーションの実行」を参照してください。
詳細については、『Oracle Service Bus Console の使い方』の「XQuery トランスフォーメーション」および「XSL トランスフォーメーション」を参照してください。Oracle XQuery Mapper を使用した XQuery の作成については、「XQuery Mapper を使用したデータの変換」を参照してください。
トランスフォーメーション マップは、2 つの互換性のないデータ型の間のマッピングを記述したものです。Oracle Service Bus は、XQuery または eXtensible Stylesheet Language Transformation (XSLT) 標準のどちらかを使用したデータ マッピングに対応しています。XSLT マップは、XML から XML へのマッピングを記述するのに対して、XQuery マップでは、XML から XML、XML から非 XML、非 XML から XML へのマッピングを記述できます。また、MFL で記述されたデータは自動的に同等の XML に変換され、XQuery または XSLT でのトランスフォーメーションで使用できます。ターゲット サービスで必要な場合、結果の XML は自動的に MFL に変換されます。詳細については、『Oracle Service Bus Console の使い方』の「XQuery トランスフォーメーション」および「XSL トランスフォーメーション」を参照してください。Oracle XQuery Mapper を使用した XQuery の作成については、「XQuery Mapper を使用したデータの変換」を参照してください。
メッセージ操作はトランスフォーメーションの一種で、メッセージの構造全体ではなくメッセージのコンテンツを操作して、メッセージを送り先のサービスと互換性のあるものにします。これは、メッセージ フローの要求パイプラインまたは応答パイプラインに対して、追加、置換、または削除アクションを実行することによって行われます。コンテンツの操作によってメッセージを変換する場合に使用可能なアクションを次の表に示します。
Oracle Service Bus にはコンフィグレーションされたサービスに対する堅牢で柔軟性のあるエラー処理が用意されています。エラーは次の方法で処理されます。
Oracle Service Bus には、検証アクションを使用して、着信または発信するメッセージを WSDL または XML スキーマに対して検証する機能が用意されています。このアクションは、メッセージ フロー内でいつでも発生する可能性があり、着信または発信するメッセージが送信先サービスのコンシューマまたはプロバイダの予期するフォーマットであることを保証します。検証でエラーとなったメッセージは、エラーをログに記録するか、またはエラーを生成することができます。エラーを生成する場合、エラー ステージを使用して他のアクションを適用することもできます。
メッセージ検証は、スキーマや WSDL の異なるバージョンに対してメッセージを検証することで、サービスのバージョン管理にも使用できます。これにより、メッセージがサービス エンドポイントの適切なバージョンにルーティングされることが保証されます。または、メッセージの送信前にトランスフォーメーションを適用する必要があるかどうかをチェックできます。
Oracle Service Bus にはエラー ハンドラを定義することで、エラー処理を行うメカニズムが用意されています。エラー ハンドラは、ロギング、トランスフォーメーション、パブリッシュなどの各種アクションを実行し、適切にエラーを処理するためのパイプラインです。ステージ内でエラーが発生すると、一連の手順が実行されます。この一連の手順がそのステージのエラー パイプラインを構成しています。
このエラー パイプラインによってエラーを処理できる方法は以下のとおりです。
メッセージ フローの処理中には、さまざまな原因でエラーが発生します。たとえば、ユーザ名が正しく確認または認証されない場合は、セキュリティ エラーが発生します。また、Oracle Service Bus がメッセージを正常に変換または検証できない場合は、変換エラーが発生します。ルーティング サービスが使用不能であるために、ルーティング エラーが発生する場合などもあります。たいていのメッセージ フロー ロジックは特定のステージ、ルート ノード、またはプロキシ サービスで実行されるため、一般的に、これらのエラーは特定のステージ、ルート ノード、またはプロキシ サービスに起因しています。
各ステージは、ステージでエラーが発生した場合に実行される一連の手順を持つことができます。この一連の手順がそのステージのエラー パイプラインを構成しています。また、エラー パイプラインは、パイプライン (要求または応答) またはプロキシ サービス全体に対して定義することができます。最も小さいスコープで指定されたエラー パイプラインがエラー時に呼び出されます。
メッセージ フローの正確な状態を把握するために Oracle Service Bus Console を使用してメッセージを追跡することができます。これにより、エラーを目で確認できるようになります。たとえば、処理を行うために送信されたことを示す、最初にレポートされたメッセージを表示してから、このメッセージが正しく処理されなかったことを示す、次にレポートされたエラーを表示することができます。これにより、メッセージ フローとエラー フローの両方を完全に表示することができます。
|