概念とアーキテクチャ
|
 |
 |
|
このトピックでは、AquaLogic Service Bus について説明します。メッセージングおよびサービス指向アーキテクチャ (SOA) を担当するエンタープライズ設計者、運用スペシャリスト、およびセキュリティ設計者を対象としています。内容は以下のとおりです。
敏捷な行動が求められるビジネスでは、ビジネスの速度に合わせて新しいサービスの提供や既存のサービスの再利用を行うために IT に依存しています。サービス駆動型へのこのようなニーズにより、IT にサービス指向アーキテクチャ (SOA) を採用させる大きな牽引力が生み出されています。SOA を実現するためには、IT にインテリジェント サービス インフラストラクチャが必要です。このようなインフラストラクチャは、サービスの再利用を促進および単純化し、本質的に異機種が混在するマルチベンダ環境に信頼性の高い統合をもたらします。BEA のサービス インフラストラクチャ製品の AquaLogic ファミリの一部である BEA AquaLogic Service Bus では、インテリジェントなメッセージ ブローカリングとサービスのモニタおよび管理を統合しているため、1 つのソフトウェア製品でサービス指向アーキテクチャ (SOA) の実装とデプロイを行うことができます。この統合により、企業のインフラストラクチャにスケーラブルで動的なルーティングとトランスフォーメーションのレイヤを組み込み、さらにサービス登録、サービス使用状況、およびサービス レベル アグリーメント (SLA) 適用を管理するサービス ライフサイクル管理機能を追加できます。AquaLogic Service Bus は、BEA の広範なビジネス統合ソリューションの中核となります。
AquaLogic Service Bus を使用すると、企業および企業の IT 部門の課題であるサービスの無秩序化が解消されます。この課題には、アプリケーションとサービスの強固な結び付きも含まれます。結び付きが強いために、複雑で硬直した密接な統合が形成されます。さらには、サービスを再利用しにくくなり、デプロイされたサービスの管理にも問題が発生します。これらすべての結果として、企業の TCO (所有総費用) が増大します。
今日の企業では、メッセージングや SOA 導入を担当するエンタープライズ設計者は次に示すような課題に直面しています。
つまり、エンタープライズ設計者やその他のスペシャリストの目標は、所有する IT インフラストラクチャを再利用して合理化し、常に制御できる状態にしておくことです。AquaLogic Service Bus は、これらの目標達成を支援するように設計されています。
AquaLogic Service Bus は、コンフィグレーションベースでポリシー駆動の Enterprise Service Bus (ESB) です。サービスやポリシーの動的なコンフィグレーション、システム モニタ、およびオペレーション タスクのための多機能コンソールが用意されています。AquaLogic Service Bus は、疎結合アーキテクチャを促進し、企業全体でのサービスの再利用を進め、管理を一元化します。このすべてが TCO (所有総費用) の削減につながります。AquaLogic Service Bus Console を使用すると、企業のサービス指向環境への変更に対して迅速かつ効率的に対応できます。
AquaLogic Service Bus は、WebLogic Server ランタイム機能に基づきます。WebLogic Server の機能を利用して、可用性、拡張性、および信頼性に優れた機能を提供します。
AquaLogic Service Bus は、サービス指向の統合、Web サービスを中心とした管理、異機種 IT 環境への従来のメッセージ ブローカリングの提供に特化した ESB 製品です。AquaLogic Service Bus の軽量でステートレスな高性能アーキテクチャは、分散サービス ネットワークを中継する中核要素として機能します。
AquaLogic Service Bus はポリシー駆動です。「サービス クライアント」と「ビジネス サービス」との間に疎結合を確立し、一方でセキュリティ制御やモニタは一元的に管理できます。
AquaLogic Service Bus では、「ポリシー」と「プロキシ サービス」のコンフィグレーションを通じてサービス統合の関係を動的に実装します。この方法により、次のシステム特性に関するサービス アーキテクチャを迅速に進化させることができます。
プロキシ サービスには仲介役としての性質があるため、AquaLogic Service Bus を使用して、次の分野に関するサービス クライアントの要件とビジネス サービスの要件の相違点を解決できます。
AquaLogic Service Bus では、ポリシー、プロキシ サービス、および関連するリソースのコンフィグレーションがメタデータとして永続化されます。このメタデータを開発環境、ステージング環境、プロダクション環境へと伝播させ、必要に応じて変更することができます。AquaLogic Service Bus メッセージ ブローカリング エンジンは、メタデータ リポジトリからこのコンフィグレーション情報にアクセスします。
AquaLogic Service Bus の設計方針のポイントは、管理機能とサービス実装を物理的に分離することにあります。この分離により、ビジネスの要求に応じて実装だけを動的に進化させることができ、コストのかかるインフラストラクチャの開発作業は不要です。AquaLogic Service Bus は、会社のメッセージング構成の一部として、多くのアプリケーションおよびシステムで共用でき、異なるチームによって構築されたサービス実装を異なる部署にまたがって適用することも可能です。
AquaLogic Service Bus は、メッセージを取得し、それを処理してルーティング先を決定し、指定どおりに変換する仲介役として機能します。HTTP(S)、JMS、ファイル、FTP などの転送プロトコルを介してメッセージを受信し、同じ転送プロトコルまたは別の転送プロトコルを使用してメッセージを送信します。メッセージへの応答はこの逆の処理になります。AquaLogic Service Bus によるメッセージ処理は、AquaLogic Service Bus Console でプロキシ サービスの「メッセージ フロー定義」で指定されたメタデータを基準に行われます。
図 1-4 AquaLogic Service Bus でのサービス コンシューマとサービス プロデューサの対話
AquaLogic Service Bus はポリシー駆動です。「サービス クライアント」と「ビジネス サービス」との間に疎結合を確立し、一方でセキュリティ制御やモニタは一元的に管理できます。次の図は、AquaLogic Service Bus のアーキテクチャの概要です。サービス管理、メッセージ ブローカリング、コンフィグレーション フレームワーク、セキュリティ、転送とメッセージングのプロトコルがサブシステムとして構成されています。
図 1-5 AquaLogic Service Bus のアーキテクチャの概要
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 での変更の管理とリソースの編成の詳細については、「変更管理とリソース編成」を参照してください。
ESB、メッセージ ブローカリング、および Web サービス管理 (WSM) の概念を 1 つの製品に融合することにより、AquaLogic Service Bus ではメッセージやサービスの管理および統合の基盤を提供しています。
次の表は、AquaLogic Service Bus の中核となる機能を示します。
表 1-1 AquaLogic Service Bus の中核となる機能
|
|
|
|
|
AquaLogic Service Bus には、SOA 用にインテリジェントなメッセージ ブローカリング機能が用意されています。
AquaLogic Service Bus では、複数のメッセージング プロトコルがサポートされています。HTTP(S)、JMS SAF、JMS プロバイダ インタフェース (MQ Series、Tibco E4JMS) を使用するサードパーティのメッセージング、ファイル、FTP、電子メール (SMTP、POP、IMAP) などです。転送も複数サポートされています。転送でサポートされている場合は、エンド ツー エンド保証配信が可能です。JMS ストア アンド フォワードおよびグローバル キュー名を使用するメッセージング ネットワークを作成することができます。Web サービス (WSDL、SOAP エンベロープ) と非 SOAP エンベロープ メッセージがサポートされています。
AquaLogic Service Bus では、複数の通信パラダイムがサポートされています。要求および応答、非同期および同期、パブリケーションおよびサブスクリプション、添付ファイル付き Web サービスなどです。異なる転送の組み合わせが可能です (たとえば、同期と非同期のブリッジングがサポートされます)。
図 1-7 AquaLogic Service Bus でのメッセージ ブローカリング
以降の節では、AquaLogic Service Bus のメッセージ構造とメッセージ処理に関連する主要な概念について説明します。
AquaLogic Service Bus では、AquaLogic Service Bus Console を使用してコンフィグレーションするプロキシ サービスを通じて、ビジネス サービス (エンタープライズ サービスとデータベースなど) とサービス クライアント (プレゼンテーション アプリケーションやその他のビジネス サービス) との間にインテリジェントなメッセージ ブローカリングを確立します。
ビジネス サービスは、メッセージの交換先となるエンタープライズ サービスの AquaLogic Service Bus での定義です。AquaLogic Service Bus Console を使用して、ビジネス サービスのインタフェース、使用する転送の種類、セキュリティの要件、およびその他の特性を定義することにより、ビジネス サービスをコンフィグレーションします。
AquaLogic Service Bus Console を使用してビジネス サービスをコンフィグレーションする方法については、『AquaLogic Service Bus Console の使い方』の「ビジネス サービス」で「ビジネス サービスの追加」を参照してください。
プロキシ サービスは、AquaLogic Service Bus のローカルにホストされた仲介 Web サービスの AquaLogic Service Bus での定義です。AquaLogic Service Bus Console を使用して、プロキシ サービスのインタフェース、使用する転送の種類、およびメッセージ フローの定義におけるメッセージ処理のロジックを定義し、ポリシーをコンフィグレーションすることにより、プロキシ サービスをコンフィグレーションします。
AquaLogic Service Bus メッセージ ブローカリングを使用すると、サービス クライアントはビジネス サービスと直接メッセージを交換するのではなく、仲介プロキシ サービスを介してメッセージを交換します。プロキシ サービスのインタフェースは、通信するビジネス サービスと同じにすることも、異なるものにすることも可能です。
プロキシ サービスは複数のビジネス サービスにメッセージをルーティングできるため、通信するビジネス サービスに依存しないインタフェースを持つプロキシ サービスをコンフィグレーションできます。その場合、メッセージを適切なビジネス サービスにルーティングして、ビジネス サービスのインタフェースで必要とされるフォーマットにメッセージ データをマップするように、メッセージ フローの定義をコンフィグレーションします。
プロキシ サービスの構造の詳細については、「メッセージ フローの定義」を参照してください。
メッセージには、アプリケーション プロセスについてのデータまたはステータス情報や、受信側に対する指示などが含まれます。AquaLogic Service Bus では、コンテンツに基づいてメッセージをルーティングし、コンテンツに対してトランスフォーメーションを実行できます。
この処理は、AquaLogic Service Bus の転送レイヤとバインディング レイヤで行われます。
図 1-8 AquaLogic Service Bus のバインディング レイヤおよび転送レイヤ
エンドポイント (ビジネス サービスまたは別のプロキシ サービス) にメッセージが送信されると、AquaLogic Service Bus では上記のイベント シーケンスと同様のモデルで応答メッセージが処理されます。
次の図は、着信エンドポイント (プロキシ サービス) から発信エンドポイント (サービスの転送 URL (ビジネス サービスや他のプロキシ サービス)) までの AquaLogic Service Bus のメッセージ フローの概要を示します。
図 1-9 AquaLogic Service Bus のメッセージ処理
以降の節では、このメッセージ処理に関連する各レイヤについて説明します。
メッセージ フローは、AquaLogic Service Bus プロキシ サービスの定義です。パイプライン、ブランチ ノード、およびルート ノードは、AquaLogic Service Bus プロキシ サービスの実装を定義します。
パイプライン、ブランチ、およびルート ノードは、AquaLogic Service Bus プロキシ サービスの実装を定義します。AquaLogic Service Bus Console を使用して、プロキシ サービスのメッセージ フローの定義におけるメッセージ処理ロジックをコンフィグレーションします。このロジックには、トランスフォーメーション、パブリッシュ、レポートなどのアクティビティが含まれます。ロジックはメッセージ フロー内の個々のアクションでコンフィグレーションされます。
次の図は、メッセージ フロー定義のコンポーネントの概要です。
パイプライン ロジックは、「要求パイプライン」定義と「応答パイプライン」定義で構成される 1 組の定義です。要求パイプライン定義は、ビジネス サービスまたは別のプロキシ サービスを呼び出す前に、プロキシ サービスへの要求メッセージに対して AquaLogic Service Bus が実行するアクションを指定します。応答パイプライン定義は、プロキシ サービスが応答を返す前に、プロキシ サービスによって呼び出されたサービスからの応答に対して AquaLogic Service Bus が実行する処理を指定します。ルーティングは、メッセージ フローの最後にルート ノードによって実行されます。
注意 : WS-Security の処理および認可は、パイプライン実行前と後に透過的に実行されます。
各パイプラインは一連のステージで構成されます。1 つのステージは、トランスフォーメーションやパブリッシュなどの、ユーザがコンフィグレーションする処理手順です。メッセージ フローに送られるメッセージには、メッセージのコンテンツを含む一連の「メッセージ コンテキスト変数」が付けられ、パイプライン ステージのアクションによってアクセスしたり変更することができます。
次の表は、AquaLogic Service Bus のパイプライン ステージ、ブランチ、およびルート ノードでサポートされるアクションを示します。
表 1-2 AquaLogic Service Bus のアクション
|
|
|
|
|
|
|
|
|
各パイプラインは、アクションを含む一連のステージで構成されます。ただし、必要に応じて 1 つのサービス レベル要求パイプラインを複数のオペレーション パイプラインに分岐することができます (1 つのオペレーションに対して最大 1 つのオペレーション パイプラインと、必要に応じてデフォルトのオペレーション パイプライン)。オペレーションの内容はユーザが選択する条件によって決定されます。応答処理は関連するオペレーション パイプラインから開始され、1 つのサービス レベル応答パイプラインに結合されます。
次の図は、プロキシ サービスのオペレーション パイプラインの例を示します。
一方向のオペレーションの場合、応答パイプラインは空のメッセージで実行されます。これにより、プロキシ サービスに応答を作成でき、双方向 (要求/応答) と一方向のオペレーションの間のブリッジングが可能になります。ブリッジング メカニズムとは、プロキシ サービスの入力が一方向であっても、出力は双方向 (要求/応答) になること (またはその逆) を意味します。プロキシ サービスは、呼び出したサービスからの応答を取得するか、クライアントへの応答を生成します。メッセージがビジネス サービスまたはプロキシ サービスにルーティングされてから、応答フローのアクションを使用してメッセージの後処理を実行することもできます。
ブランチ ノードを使用すると、可能ないくつかのパスのうちの 1 つに限定して処理を進ませることができます。ブランチ処理は、単純でありながらユニークなストリング値のタグが付いたブランチをまとめた簡単なルックアップ表を基準に行われます。メッセージ コンテキストの変数をそのノードのルックアップ変数として指定し、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ルックアップ変数の値は、ブランチ ノードに到達する前に設定する必要があります。このアプローチにより、そのブランチ ノード自体の中での例外の発生を防ぐことができます。ブランチ ノードでは、メッセージ フロー ツリー内にいくつかの子孫を持つことができます (デフォルトのブランチを含め各ブランチに 1 つずつ)。
ルート ノードは他のサービスとの要求通信と応答通信に使用されます。ルート ノードはプロキシ サービスに関する要求処理と応答処理の境界を表します。ルート ノードが要求メッセージをディスパッチすると、要求処理が終了したと見なされます。ルート ノードが応答メッセージを受信したときに、応答処理が始まります。ルート ノードは、発信トランスフォーメーション、応答トランスフォーメーション、および条件付きルーティングに対応します。
ルート ノードまたはブランチ ノードで条件をコンフィグレーションするように選択することもできます。
ルート ノードは要求処理と応答処理の境界を表すので、メッセージ フロー ツリー内に子孫を持つことはできません。
図 1-13 プロキシ サービスのルート ノードとサービスとの通信
|
|
|
