| Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ 11g リリース1 (11.1.1.7) B61433-07 |
|
 前 |
 次 |
| Oracle Fusion Middleware Oracle Service Busコンセプトおよびアーキテクチャ 11g リリース1 (11.1.1.7) B61433-07 |
|
前 |
次 |
この章では、Oracle Service Busアーキテクチャの概要について説明し、サービスの迅速な統合、プロビジョニング、異なるITインフラストラクチャ間の管理を可能にする操作上の機能について取り上げます。統合を目的とするIT設計者で、メッセージングとサービス指向アーキテクチャ(SOA)の担当者を対象としています。
この章の内容は以下のとおりです。
Oracle Service BusはEnterprise Service Busを中心としたアーキテクチャです。このバスでは、SOAP、HTTP、およびJavaメッセージング・サービス(JMS)を含む標準に基づいたメッセージ配信サービスが提供されます。これは、通常、高スループットを保証するメッセージ配信を各種サービスのプロデューサおよびコンシューマに提供するために設計されるものです。ネイティブのデータ型としてXMLがサポートされており、他のデータ型を処理するために、その他のデータ型も提供されます。
Oracle Service Busはポリシー駆動型であり、「サービス・クライアント」と「ビジネス・サービス」との間に疎結合を確立する一方で、セキュリティ制御とモニターを一元的に管理できます。ステージングによって開発環境から本番環境へ必要に応じてカスタマイズおよび伝播可能なメタデータとして、ポリシー、プロキシ・サービス、および関連するリソース構成を永続化して保存します。メッセージ・ブローカリング・エンジンは、メタデータ・キャッシュからこの構成情報にアクセスします。
Oracle Service Busは、着信するサービス・リクエスト・メッセージを処理して、ルーティング・ロジックを決定し、メッセージを他のサービス・コンシューマと互換性があるように変換を行う仲介機能です。HTTP (S)、JMS、ファイル、FTPなどの転送プロトコルを介してメッセージを受信し、同じ転送プロトコルまたは別の転送プロトコルを使用してメッセージを送信します。サービスのレスポンス・メッセージは、これと逆のパスを辿ります。Oracle Service Busによって処理されるメッセージは、プロキシ・サービスの「メッセージ・フローの定義」によって指定されるメタデータによって駆動されます。
次の上位レベル・アーキテクチャ・ダイアグラムは、Oracle Service Busとその機能サブシステムを示しています。
この項では、Oracle Service Busのアーキテクチャの主要なコンセプトについて説明します。
メッセージには、アプリケーション・プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。Oracle Service Busでは、コンテンツに基づいてメッセージをルーティングし、コンテンツに対して変換を実行できます。この処理は、Oracle Service Busのトランスポート・レイヤーおよびバインディング・レイヤーを介して実行されます。
図2-2 Oracle Service Busのバインディング・レイヤーおよびトランスポート・レイヤー
メッセージの処理では、次の一連のイベントが実行されます。
インバウンド・トランスポートの処理
メッセージ・フローの実行
アウトバウンド・トランスポートの処理
エンドポイント(ビジネス・サービスまたは別のプロキシ・サービス)にメッセージが送信されると、Oracle Service Busは上記のイベント・シーケンスと同様のモデルでレスポンス・メッセージを処理します。
次の図にOracle Service Busにおけるインバウンド・エンドポイント(プロキシ・サービス)からアウトバウンド・エンドポイント(ビジネス・サービスまたは他のプロキシ・サービスであるサービス・トランスポートURL)までの上位レベルのメッセージ・フロー処理を示します。
以降の項では、このメッセージ処理に関連する各レイヤーについて説明します。
バインディング・レイヤーでは次の処理が行われます。
必要に応じたメッセージをパックおよびアンパックします。
メッセージのセキュリティを扱います。
メッセージを渡してメッセージ・フローを開始します(リクエストおよびレスポンス)
インバウンド・トランスポート・レイヤーは、クライアント・サービス(またはサービス・コンシューマ)とOracle Service Busとの間にある通信レイヤーです。サービス・クライアント・エンドポイントと通信を処理して、Oracle Service Busへのメッセージのエントリ・ポイントとして機能します。インバウンド・トランスポート・レイヤーは主に入力または出力ストリームのメッセージ・データを生のバイトとして処理します。
トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、および電子メールを含む互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、レスポンス・メッセージをサービス・コンシューマに返し、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。
アウトバウンド・トランスポート・レイヤーは、ビジネス・サービス(またはサービス・プロデューサ)とOracle Service Busとの間の通信機能を担います。Oracle Service Busからビジネス・サービスまたはプロキシ・サービスにメッセージを渡し、サービスからレスポンスを受信します。トランスポート・レベルでは、メッセージ・データは入力または出力ストリームの形式の生のバイトです。アウトバウンド・トランスポート・レイヤーは、HTTP(S)、JMS、FTP、ファイル、電子メールを含む互換性のあるトランスポート・プロトコルをサポートします。データ処理には関与しませんが、エンドポイントURIやトランスポート・ヘッダーなどのメッセージのメタデータを処理します。
プロキシ・サービスは、Oracle Service Busのアーキテクチャで基礎となるコンセプトです。プロキシ・サービスは、サービス・コンシューマが管理対象のバックエンド・サービスに接続するために使用するインタフェースです。プロキシ・サービスは、Service Busがローカルに実装する仲介Webサービスの定義になっています。Oracle Service Bus管理コンソールではプロキシ・サービスの構成が可能で、Web Services Description Language (WSDL)でそのインタフェースを定義し、また使用されるトランスポートの種類も定義することができます。メッセージの処理ロジックは、プロキシ・サービスの定義時に「メッセージ・フローの定義」で指定されます。プロキシ・サービスの詳細は、5.1.1.1項「プロキシ・サービス」を参照してください。
プロキシ・サービスのコンテキストは、リクエスト・フローとレスポンス・フローとで共有される一連のXML変数です。コンテキストに新しい変数を動的に追加したり、または削除できます。あらかじめ定義されたコンテキスト変数には、メッセージに関する情報、トランスポート・ヘッダー、セキュリティ・プリンシパル、現在のプロキシ・サービスのメタデータ、およびプロキシ・サービスから呼び出されるプライマリ・ルーティング・サービスとパブリッシュ・サービスのメタデータが含まれます。
コンテキストは読み込まれて、XQuery式による変更や、変換やインプレース更新アクションによる更新が行われることがあります。コンテキストの中核は、$header、$body、$attachments変数で構成されます。これらのラッパー変数には、Simple Object Access Protocol (SOAP)ヘッダー要素、SOAP本体要素、およびMultipurpose Internet Mail Extensions (MIME)添付がそれぞれ含まれます。コンテキストによって、すべてのメッセージがSOAPメッセージであり、非SOAPメッセージがこのパラダイムにマップされるように見えます。
プロキシ・サービスはメッセージを複数のビジネス・サービスにルーティングできるため、プロキシ・サービスは通信先のビジネス・サービスとは独立したインタフェースで構成できます。汎用のプロキシ・テンプレートを使用すると、コンテンツ・ベースのルーティング・ロジックに基づいてメッセージを適切なビジネス・サービスに動的にルーティングするメッセージ・フローの定義としてプロキシ・サービスを構成できます。プロキシ・サービスは、メッセージ・データをエンドポイントのビジネス・サービスによって必要とされる適切なプロトコル形式にマッピングすることもでき、その結果、動的な実行時プロトコル切替えが可能になります。
プロキシ・テンプレートの詳細は、第5章「サービス・コンポジション」を参照してください。
プロキシ・サービスの実装は、「メッセージ・フローの定義」によって指定されます。メッセージ・フローの定義は、プロキシ・サービスを通過するリクエスト・メッセージとレスポンス・メッセージのフローを定義します。メッセージ・フローには、次の4つの構成要素があります。
パイプライン・ペア。一方はリクエストで使用され、他方はレスポンスで使用されます。パイプラインは、要求処理または応答処理で実行されるアクションを指定する一連のステージで構成されます。
ブランチ・ノード。メッセージまたはメッセージ・コンテキストの指定部分の値に基づいて分岐するか、呼び出されたオペレーションに基づいて分岐するために使用されます。
ルート・ノード。メッセージの宛先の定義に使用されます。デフォルト・ルート・ノードは、リクエストそのものをレスポンスとして返すエコー・ノードです。
開始ノード。
メッセージ・フロー要素を任意で組み合せて、「開始ノード」をルート(root)位置に必ず(1つだけ)配置し、ルート(route)ノードを持つツリー構造を形成します。ブランチの最後のノード(リーフ・ノード)は、ルート・ノードまたはエコー・ノードになります。
リクエスト・メッセージは開始ノードから始まり、リクエスト・パイプラインのアクションを実行しながらリーフ・ノードまでの経路を辿ります。リーフがルート・ノードの場合、応答が生成されます。一方向のサービスの場合は空の応答になることがあります。リーフがエコー・ノードの場合、要求そのものが応答として扱われます。応答では、ブランチ・ノードのアクションをスキップしながらツリーの経路を逆に辿ります。ただし、応答パイプラインのアクションは実行されます。
インタフェースまたはオペレーションがリクエスト/レスポンスであれば、最後にツリーの一番上からレスポンスが送信されます。それ以外の場合、レスポンスは破棄されます。メッセージ・フローの定義の詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項を参照してください。
コンテキスト変数に影響する一連の変換は、選択したエンドポイントへのメッセージの送信前、またはレスポンスの受信後に定義できます。XQueryまたはXSLT変換のかわりにWebサービス・コールアウトを使用して、コンテキスト変数を設定できます。Oracle Service Bus変換マップを構成する方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』を参照してください。
WS-Securityの処理も認可と同様に、WS-Policyを使用するビジネス・サービスの呼出し時に開始ノードで透過的に実行されます。Oracle Service Busのセキュリティの構成方法については、『Oracle Fusion Middleware Oracle Service Bus開発者ガイド』のセキュリティに関する項を参照してください。
この項では、Oracle Service Busのデプロイメント機能について説明します。
Oracle Service Busは、多数の分散サービス・エンドポイントを集中的に管理して制御するように設計されています。Oracle Service Busは、次の構成にデプロイできます。
管理サーバーとしても機能する単一サーバー。
複数のサーバーで構成されるクラスタ。
Oracle Service Busを使用することで、自律的なESBインスタンスを企業全体に構成できます。これらのインスタンスは、サービスや変換などの、構成アーティファクトの独自のセットを持っています。通常、このようなデプロイメントでは、組織内の様々なIT部門にマップします。異なる部門間の通信は、多くの場合ファイアウォールを介して互いにやり取りする、ESBの連携ネットワークを介して行われます。Oracle Service Busのデプロイメントの詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』を参照してください。
Oracle Service Busでは多数の分散サービス・エンドポイントを管理および調整できるため、企業内の集中管理が可能になります。さらに、基になるOracle WebLogic Serverをクラスタリングすることで異種のOracle Service Busハブを水平方向に拡大し、分散Oracle Service Busネットワークを作成できます。
クラスタは、メッセージを処理する一連のクラスタリングされた管理対象サーバーで構成されます。1つのドメインに含まれるOracle Service Busをデプロイしたクラスタは1つに限られます。このクラスタは、Oracle Service Bus以外にも他のアプリケーションをホストできます。管理サーバーはクラスタ・ドメインごとに1つだけあります。クラスタリングの詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』のOracle Service Busクラスタに関する項およびOracle Service Busデプロイメント・トポロジに関する項を参照してください。
この場合、Oracle Service Busの中央のデプロイメントがガバナンスと調整を処理し、ネットワーク内のすべてのESBは、中央のESBを介して通信します。管理対象サーバーに構成とメタデータを自動的に伝播してローカルでの取得時間を節約し、モニター用のメトリックをすべての管理対象サーバーから自動的に収集して、Oracle Service Bus管理コンソールで集約して表示します。
次の図は、基本的なOracle Service Busクラスタ・トポロジでのメッセージ・データ・フローを示します。
Oracle Service Busは、JMSストア・アンド・フォワードを使用して、連携ネットワーク間の信頼性の高い、保証されたメッセージングを可能にします。また、動的ルーティング機能も、このネットワークの構成を簡略化します。メッセージングの負荷をクラスタ内のサーバー間で均一に分散することで、システムのボトル・ネックを取り除くことができます。
Oracle Service Busでは、制御された環境でのリソースおよびサービスの構成により、エンタープライズ・システムの変更管理のベスト・プラクティスをサポートします。システムの構成をテスト用に別のステージング・ドメインにエクスポートして、プロモーションの最終準備を行ってから、本番ドメインにエクスポートできます。JavaプログラムやJavaスクリプトを使って、アプリケーションのデプロイメントを自動化したり、構成をステージング環境から本番環境に移行したりすることができます。
Oracle Service Bus管理コンソールでは、多数のデプロイメント・カスタマイズ・オプションを選択することができます。様々な環境変数を使用して、環境を移行する際の設定を保持または調整することが可能です。詳細は、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』の環境値の検索と置換およびカスタマイズ・ファイルの作成に関する項を参照してください。
大規模な開発では、リソースの開発、テスト、ステージング、および本番システムへのデプロイを行う機能が重要です。Oracle Service Bus管理コンソールでは、Oracle Service Busリソース構成をメタデータとして保存し、他のOracle Service Busドメインへのインポート用にJARファイルとしてエクスポートできます。この機能により、Oracle Service Busリソース構成の環境を、ステージング、テスト、本番という順序に従って移行していくことができ、各種のデプロイメント・シナリオを達成するために必要となる専門知識、時間、リソースを最小限に抑えることができます。
リソースのエクスポートとインポートに加えて、プロジェクト全体のエクスポートとインポートも可能です。既存のソース・コード・コントロール・システムの機能と構成JARファイルを組み合せると、Oracle Service Bus構成のバージョン管理および変更管理を行うことができます。
エクスポート機能では、JARファイルを使用して、既存の構成を他のOracle Service Busドメインにエクスポートできます。この機能では、Oracle Service Busのソース・ドメインにデプロイメントされたリソースのすべて、またはサブセットをエクスポートすることで、システム構成をOracle Service Busのあるインスタンスから別のインスタンスに伝播できます。エクスポート可能なデータに制限はありません。1つまたは複数のプロジェクト、または1つまたは複数のプロジェクトから選択したリソースをエクスポートできます。
Oracle Service Bus管理コンソールでは、依存関係の追跡機能により、特定のリソースとそのリソースが依存している他のすべてのリソースをエクスポートすることもできます。構成をエクスポートするには、セッションの外部で作業する必要があります。有効化されている(実行時にデプロイされている)構成のみがエクスポート可能です。
操作値には、グローバル操作設定と、プロキシ・サービスおよびビジネス・サービス用の操作値の2種類があります。グローバル操作設定はシステム・プロジェクト・フォルダにあるリソースで、他のすべてのリソースと同様にエクスポートできます。インポートしているドメインの操作設定がインポート中に上書きされないように保持することが可能です。これはPreserve Operational Values設定を指定することで実現されます。Preserve Operational Valuesが指定されていない場合は、インポートするJARファイルの値がドメインに設定されます。
インポート機能では、リソース構成を別のOracle Service Busドメインのセッションにインポートできます。このインポート機能を使用するには、構成JARファイルがインポートされるセッションで作業を行う必要があります。多数の構成の更新と複数のJARファイルのインポートは1つのセッション内で許可されます。また、エクスポートされたデータのサブセットのみをインポートすることもできます。
Oracle Service Busには、Oracle Service Bus管理コンソールのチェンジ・センターを使用して、インポートするドメインの要件を満たすように環境に固有の再構成を行う機能があります。このカスタマイズ機能を使用して、インポートされたリソースはアクティブ化する前に新しいドメインに合わせて調整できます。
インポート機能と検索および置換機能をと同時に使用することで、リソースに対する環境に固有の属性のグローバルな変更がサポートされます。これは、同様の多くの環境値を変更するときに便利です。この機能による置換は、複雑なデプロイメント・シナリオで構成を慎重に調整する必要がある場合には適しません。詳細は、『Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド』を参照してください。
Oracle Service Bus管理コンソールを使用して、構成メタデータをエクスポートおよびインポートする方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のカスタマイズに関する項を参照してください。Oracle Service Bus管理コンソールのチェンジ・センターを使用して、新しい環境用に構成を変更する方法については、『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のチェンジ・センターの使用に関する項を参照してください。
Oracle Service Busの構成とデプロイメントはOracle Service Bus管理コンソールを使用してすべて実行することができますが、Oracle WebLogic Server Scripting Tool (WLST)を使用するとデプロイメント・タスクを自動化できます。WLSTの詳細は、Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのWLSTコマンドおよび変数リファレンスに関する項を参照してください。
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Busでのメッセージ・フローのモデリングに関する項
『Oracle Fusion Middleware Oracle Service Bus管理者ガイド』のOracle Service Bus APIに関する項
Oracle Fusion Middleware Oracle Service Busデプロイメント・ガイド
