概念とアーキテクチャ
|
 |
 |
|
BEA の新しいサービス インフラストラクチャ製品ファミリ (AquaLogic) の一部である BEA AquaLogic Service Bus では、インテリジェントなメッセージ ブローカリングとサービスのモニタおよび管理を統合しているため、1 つのソフトウェア製品でサービス指向アーキテクチャ (SOA) の実装とデプロイを行うことができます。この統合により、企業のインフラストラクチャにスケーラブルで動的なルーティングとトランスフォーメーションのレイヤを組み込み、さらにサービス登録、サービス使用状況、およびサービス レベル アグリーメント (SLA) 適用を管理するサービス ライフサイクル管理機能を追加できます。
AquaLogic Service Bus は、コンフィグレーションベースでポリシー駆動の Enterprise Service Bus (ESB) です。サービスやポリシーの動的なコンフィグレーション、システム モニタ、およびオペレーション タスクのための多機能コンソールが用意されています。AquaLogic Service Bus Console を使用すると、企業のサービス指向環境への変更に対して迅速かつ効率的に対応できます。
AquaLogic Service Bus は、WebLogic Server ランタイム機能に基づきます。WebLogic Server の機能を利用して、可用性、拡張性、および信頼性に優れた機能を提供します。
このトピックでは、AquaLogic Service Bus について説明します。このトピックは、メッセージングおよび SOA を担当するエンタープライズ設計者、運用スペシャリスト、およびセキュリティ設計者を対象としています。内容は以下のとおりです。
今日の企業では、メッセージングや SOA を担当するエンタープライズ設計者は次に示すような多数の課題に直面しています。
つまり、エンタープライズ設計者やその他のスペシャリストの目標は、所有する IT インフラストラクチャを再利用して合理化し、常に制御できる状態にしておくことです。AquaLogic Service Bus は、これらの目標達成を支援するように設計されています。
AquaLogic Service Bus は、サービス指向の統合を行ったり、Web サービスを管理したり、異なる IT 環境に対して従来のメッセージ ブローカリングを提供したりすることに特化した ESB 製品です。AquaLogic Service Bus の軽量でステートレスな高性能アーキテクチャは、分散サービス ネットワークを中継する中核要素として機能します。
AquaLogic Service Bus はポリシー駆動です。次の図に示すように、「サービス クライアント」と「ビジネス サービス」との間に疎結合を確立し、一方でセキュリティ制御やモニタは一元的に管理できます。
図 1-1 AquaLogic Service Bus の高度なアーキテクチャ
AquaLogic Service Bus では、「ポリシー」と「プロキシ サービス」のコンフィグレーションを通じてサービス統合の関係を動的に実装します。この方法により、次のシステム特性に関するサービス アーキテクチャを迅速に進化させることができます。
プロキシ サービスには仲介役としての性質があるため、AquaLogic Service Bus を使用して、次の分野に関するサービス クライアントの要件とビジネス サービスの要件の相違点を解決できます。
AquaLogic Service Bus では、ポリシー、プロキシ サービス、および関連するリソースのコンフィグレーションがメタデータとして永続化されます。このメタデータを開発環境、ステージング環境、プロダクション環境へと伝播させ、必要に応じて変更することができます。AquaLogic Service Bus メッセージ ブローカリング エンジンは、メタデータ リポジトリからこのコンフィグレーション情報にアクセスします。
AquaLogic Service Bus の設計方針のポイントは、管理機能とサービス実装を物理的に分離することにあります。この分離により、ビジネスの要求に応じて実装だけを動的に進化させることができ、コストのかかるインフラストラクチャの開発作業は不要です。AquaLogic Service Bus は、会社のメッセージング構成の一部として、多くのアプリケーションおよびシステムで共用でき、異なるチームによって構築されたサービス実装を異なる部署にまたがって適用することも可能です。
ESB、メッセージ ブローカリング、および Web サービス管理 (WSM) の概念を 1 つの製品に融合することにより、AquaLogic Service Bus ではメッセージやサービスの管理および統合の基盤を提供しています。
次の表は、AquaLogic Service Bus の中核となる機能を示します。
表 1-1 AquaLogic Service Bus の中核となる機能
|
|
|
AquaLogic Service Bus は、メッセージを取得し、それを処理してルーティング先を決定し、指定どおりに変換する仲介役として機能します。JMS などの転送プロトコルからメッセージを受信して、同じ転送プロトコルまたは指定された別の転送プロトコルを使用して再度メッセージを送信します。メッセージへの応答はこの逆の処理になります。AquaLogic Service Bus によるメッセージ処理は、AquaLogic Service Bus Console でプロキシ サービスの「メッセージ フロー定義」で指定されたメタデータを基準に行われます。
AquaLogic Service Bus は WebLogic Server 9.0 上で動作し、次のコンフィグレーションにデプロイできます。
AquaLogic Service Bus では多数の分散サービス エンドポイントを管理および制御できるため、企業内の集中管理が可能になります。たとえば、企業内のすべての Web サービス トラフィックを管理する単一のハブとして AquaLogic Service Bus をデプロイできます。
基底にある WebLogic Server をクラスタ化することにより、AquaLogic Service Bus ハブを水平方向に拡張できます。メッセージングの負荷をクラスタ内のサーバ間で均一に分散できるため、システムのボトルネックを取り除くことができます。さらに、異種の AquaLogic Service Bus ハブを接続し、分散 AquaLogic Service Bus ネットワークを作成できます。
AquaLogic Service Bus は、WebLogic 管理対象サーバのクラスタ化をサポートします。管理対象サーバにコンフィグレーションとメタデータを自動的に伝播してローカルでの取得時間を節約し、モニタ用のメトリックをすべての管理対象サーバから自動的に収集して、AquaLogic Service Bus Console で集約して表示します。
次の図は、基本的な AquaLogic Service Bus クラスタ トポロジでのメッセージ データ フローを示します。
AquaLogic Service Bus では、制御された環境でのリソースおよびサービスのコンフィグレーションを可能にすることにより、企業の変更管理のベスト プラクティスをサポートします。コンフィグレーションをエクスポートし、別のテスト用ステージング ドメインにインポートしてプロモーションの最終準備を行ってから、プロダクション ドメインにインポートできます。AquaLogic Service Bus では、インポート先ドメインの要件に合わせて環境固有の要素を再コンフィグレーションできます。
AquaLogic Service Bus には、SOA 用にインテリジェントなメッセージ ブローカリング機能が用意されています。以降の節では、AquaLogic Service Bus のメッセージ構造とメッセージ処理に関連する主要な概念について説明します。
AquaLogic Service Bus では、AquaLogic Service Bus Console を使用してコンフィグレーションするプロキシ サービスを通じて、ビジネス サービス (エンタープライズ サービスとデータベースなど) とサービス クライアント (プレゼンテーション アプリケーションやその他のビジネス サービス) との間にインテリジェントなメッセージ ブローカリングを確立します。
ビジネス サービスは、メッセージの交換先となるエンタープライズ サービスの AquaLogic Service Bus での定義です。AquaLogic Service Bus Console を使用して、ビジネス サービスのインタフェースの WSDL、使用する転送の種類、セキュリティの要件、およびその他の特性を定義することにより、ビジネス サービスをコンフィグレーションします。
AquaLogic Service Bus Console を使用してビジネス サービスをコンフィグレーションする方法については、AquaLogic Service Bus Console のオンライン ヘルプの「ビジネス サービス」で「ビジネス サービスの追加」を参照してください。
プロキシ サービスは、AquaLogic Service Bus のローカルにホストされた仲介 Web サービスの AquaLogic Service Bus での定義です。AquaLogic Service Bus Console を使用して、プロキシ サービスのインタフェースの WSDL、使用する転送の種類、およびメッセージ フローの定義におけるメッセージ処理のロジックを定義し、ポリシーをコンフィグレーションすることにより、プロキシ サービスをコンフィグレーションします。
AquaLogic Service Bus メッセージ ブローカリングを使用すると、サービス クライアントはビジネス サービスと直接メッセージを交換するのではなく、仲介プロキシ サービスを介してメッセージを交換します。プロキシ サービスは、通信するビジネス サービスと同じ (同じ WSDL および転送) インタフェースか、WSDL、転送の種類、またはその両方が異なるインタフェースを持つことができます。
プロキシ サービスは複数のビジネス サービスにメッセージをルーティングできるため、通信するビジネス サービスに依存しないインタフェースを持つプロキシ サービスをコンフィグレーションできます。その場合、メッセージを適切なビジネス サービスにルーティングして、ビジネス サービスのインタフェースで必要とされるフォーマットにメッセージ データをマップするように、メッセージ フローの定義をコンフィグレーションします。
プロキシ サービスの構造の詳細については、「メッセージ フローの定義」を参照してください。
メッセージとは、アプリケーション間で情報を共有するために WebLogic Server で使用する方法です。メッセージには、アプリケーション プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。AquaLogic Service Bus では、コンテンツに基づいてメッセージをルーティングし、コンテンツに対してトランスフォーメーションを実行できます。
エンドポイント (ビジネス サービスまたは別のプロキシ サービス) にメッセージが送信されると、AquaLogic Service Bus では上記のイベント シーケンスと同様のモデルで応答メッセージが処理されます。
次の図は、着信エンドポイント (プロキシ サービス) から発信エンドポイント (サービスの転送 URL (通常はビジネス サービス)) までの AquaLogic Service Bus のメッセージ フローの詳細を示します。
図 1-3 AquaLogic Service Bus のメッセージ処理
以降の節では、このメッセージ処理に関連する各レイヤについて説明します。
メッセージが最初に送られるのが着信転送レイヤです。このレイヤは、サービス クライアント エンドポイントとの通信を処理し、AquaLogic Service Bus へのメッセージのエントリ ポイントとして機能します。HTTP や JMS などのさまざまな通信プロトコルをサポートします。メッセージ データ自体については、主に生のバイトを入力/出力ストリーム形式で処理します。
着信転送レイヤは、AquaLogic Service Bus システムにメッセージを送り、応答を返すためだけのレイヤです。データ処理は行われません。
パイプライン、ブランチ、およびルート ノードは、AquaLogic Service Bus プロキシ サービスの実装を定義します。AquaLogic Service Bus Console を使用して、プロキシ サービスのメッセージ フローの定義におけるメッセージ処理ロジックをコンフィグレーションします。このロジックには、トランスフォーメーション、パブリッシュ、レポートなど、パイプラインのステージ内で個別のアクションとして実装されるアクティビティが含まれます。
パイプライン ロジックは、「要求パイプライン」定義と「応答パイプライン」定義で構成される 1 組の定義です。要求パイプライン定義は、ビジネス サービスまたは別のプロキシ サービスを呼び出す前に、プロキシ サービスへの要求メッセージに対して AquaLogic Service Bus が実行するアクションを指定します。応答パイプライン定義は、プロキシ サービスが応答を返す前に、プロキシ サービスによって呼び出されたサービスからの応答に対して AquaLogic Service Bus が実行する処理を指定します。ルーティングは、メッセージ フローの最後にルート ノードによって実行されます。
注意 : WS-Security の処理および認可は、パイプライン実行前に透過的に実行されます。
各パイプラインは一連のステージで構成されます。1 つのステージは、トランスフォーメーションやパブリッシュなどの、ユーザがコンフィグレーションする処理手順です。パイプラインに送られるメッセージには、メッセージのコンテンツを含む一連の「メッセージ コンテキスト変数」が付けられ、パイプライン ステージのアクションによってアクセスしたり変更することができます。
次の表は、AquaLogic Service Bus のパイプライン ステージで可能なアクションをすべて示します。
各パイプラインは、アクションを含む一連のステージで構成されます。ただし、必要に応じて 1 つのサービス レベル要求パイプラインを複数のオペレーション パイプラインに分岐することができます (1 つのオペレーションに対して最大 1 つのオペレーション パイプラインと、必要に応じてデフォルトのオペレーション パイプライン)。オペレーションの内容はユーザが選択する条件によって決定されます。応答処理は関連するオペレーション パイプラインから開始され、1 つのサービス レベル応答パイプラインに結合されます。
次の図は、プロキシ サービスのオペレーション パイプラインの例を示します。
一方向のオペレーションの場合、応答パイプラインは空のメッセージで実行されます。これにより、プロキシ サービスに応答を作成でき、双方向 (要求/応答) と一方向のオペレーションの間のブリッジングが可能になります。ブリッジング メカニズムとは、プロキシ サービスの入力が一方向であっても、出力は双方向 (要求/応答) になること (またはその逆) を意味します。プロキシ サービスは、呼び出したサービスからの応答を取得するか、クライアントへの応答を生成します。
発信転送レイヤは、送り先エンドポイントとの通信を処理します。HTTP や JMS などのさまざまな通信プロトコルをサポートします。メッセージ データ自体については、主に生のバイトを入力/出力ストリーム形式で処理します。
発信転送レイヤは、AquaLogic Service Bus システムからメッセージを取得するためだけのレイヤです。データ処理は行われません。
|
|
|
