|
|
この章では、AquaLogic Service Bus の概念およびアーキテクチャの概要について説明します。メッセージングおよびサービス指向アーキテクチャ (SOA) を担当するエンタープライズ設計者、運用スペシャリスト、およびセキュリティ設計者を対象としています。内容は以下のとおりです。
敏捷な行動が求められるビジネスでは、ビジネスの速度に合わせて新しいサービスの提供や既存のサービスの再利用を行うために IT に依存しています。サービス駆動型へのこのようなニーズにより、IT にサービス指向アーキテクチャ (SOA) を採用させる大きな牽引力が生み出されています。SOA を実現するためには、IT にインテリジェント サービス インフラストラクチャが必要です。このようなインフラストラクチャは、サービスの再利用を促進および単純化し、本質的に異機種が混在するマルチベンダ環境に信頼性の高い統合をもたらします。BEA のサービス インフラストラクチャ製品の AquaLogic ファミリの一部である BEA AquaLogic Service Bus では、インテリジェントなメッセージ ブローカリングとサービスのモニタおよび管理を統合しているため、1 つのソフトウェア製品でサービス指向アーキテクチャ (SOA) の実装とデプロイを行うことができます。この統合により、企業のインフラストラクチャにスケーラブルで動的なルーティングとトランスフォーメーションのレイヤを組み込み、さらにサービス登録、サービス使用状況、およびサービス レベル アグリーメント (SLA) 適用を管理するサービス ライフサイクル管理機能を追加できます。AquaLogic Service Bus は、BEA の広範なビジネス統合ソリューションの中核となります。
今日の企業において SOA のデプロイが経済的な利点が実現されたことには 2 つの要因があります。それは、新しいサービスおよびレガシー サービスを迅速にエクスポーズして有効化する方法として Web サービスが業界に導入されたことと、疎結合型サービスの対話をサポートするツールキットとインフラストラクチャが開発されたことです。企業は、既存のビジネス アプリケーションをサービスとして展開することで、既存のインフラストラクチャを置き換えるコストと複雑さを負担することなく、それらをその他のビジネス プロセスやアプリケーションでも使用することができます。
したがって、SOA を成功させるには、異なる環境にあるサービス間での動的な対話をサポートする統合レイヤが重要になります。この統合レイヤは、ビジネスの拡大に合わせて、既存のサービスを継続的に進化させ、新しいサービスを迅速に追加し、新しい顧客、パートナ、およびビジネスの要請に対応すると同時に、サービス コンシューマがサービス エンド ポイントの変更に影響されないようにする必要があります。
今日の企業では、メッセージングや SOA 導入を担当するエンタープライズ設計者は次に示すような課題に直面しています。
図 1-2 は、多くの企業が直面しているサービスの無秩序化の課題と SOA 導入に関する課題を示しています。この課題には、アプリケーションとサービスの強固な結び付きも含まれます。結び付きが強いために、複雑で硬直した密接な統合が形成されます。さらには、サービスを再利用しにくくなり、デプロイされたサービスの管理にも問題が発生します。これらすべての結果として、企業の TCO (所有総費用) が増大します。
AquaLogic Service Bus を使用すると、企業および企業の IT 部門の課題であるサービスの無秩序化が解消されます。
つまり、エンタープライズ設計者やその他のスペシャリストの目標は、所有する IT インフラストラクチャを再利用して合理化し、常に制御できる状態にしておくことです。AquaLogic Service Bus は、これらの目標達成を支援するように設計されています。AquaLogic Service Bus は、サービス コンシューマとサービス プロバイダの間の仲介として機能することで、以前はそれぞれ個別に管理する必要があった不安定なポイントツーポイント接続をなくします。
AquaLogic Service Bus は、コンフィグレーションベースでポリシー駆動の Enterprise Service Bus (ESB) です。サービスやポリシーの動的なコンフィグレーション、システム モニタ、およびオペレーション タスクのための多機能コンソールが用意されています。AquaLogic Service Bus は、疎結合アーキテクチャを促進し、企業全体でのサービスの再利用を進め、管理を一元化します。このすべてが TCO (所有総費用) の削減につながります。AquaLogic Service Bus Console を使用すると、企業のサービス指向環境への変更に対して迅速かつ効率的に対応できます。
図 1-2 に示されているアーキテクチャに AquaLogic Service Bus を追加することで、これらの機能を有効化し、AquaLogic Service Bus を分散サービスの仲介として機能させることができます。AquaLogic Service Bus は、サービス エンドポイントから抽象化され、AquaLogic Service Bus 内で管理されている、ルーティング ルール、トランスフォーメーション、セキュリティ、およびアクセスに関連付けられたポリシーを適用し、図 1-3 に示すように、アーキテクチャを合理化します。
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 は、会社のメッセージング構成の一部として、多くのアプリケーションおよびシステムで共用でき、異なるチームによって構築されたサービス実装を異なる部署にまたがって適用することも可能です。
BEA AquaLogic Service Bus は、サービス コンシューマとサービス プロバイダの間の要求および応答メッセージ フローのコンフィグレーションに使用されるサービスの仲介です。BEA AquaLogic Service Bus は、コンシューマが使用するサービスをエクスポーズしたり、コンシューマとプロバイダ間のメッセージのフローを管理およびモニタしたりすることで、サービスのライフサイクルにおいて重要な役割を果たします。
サービスのライフサイクルは、サービスがモデル化されて設計される設計段階から始まります。開発段階において、開発者は、アプリケーションとそれらのサービス インタフェースを作成し、エクスポーズします。
AquaLogic Service Bus は、それらのサービス インタフェースが作成された後に機能します。サービスが作成されると、後でその他のサービスまたはプロセスが使用できるように、登録およびエクスポーズされます。サービスは、ローカル レジストリで AquaLogic Service Bus に直接登録することも、または BEA AquaLogic Service Registry™ などのエンタープライズ サービス レジストリからインポートすることもできます。サービスが登録されると、AquaLogic Service Bus は、それらのサービスと通信するためのメッセージ フローを定義するプロキシ インタフェースをコンフィグレーションします。
このフローには、適用すべきトランスフォーメーションとセキュリティに関する要件、およびメッセージのサービスへのルーティングについての仕様が含まれます。サービスが AquaLogic Service Bus に登録されると、BEA WebLogic Integration™ を使用して作成されたビジネス プロセスなどが、それらのサービスを使用したり、それらを連携させてさまざまなビジネス コンテキストをサポートできるようになります。これらの連携されたプロセスは、サービスが使用される方法やビジネス要件に適用される方法、およびより詳細なビジネス プロセスを定義します。その後、これらのビジネス プロセスは、ユーザ インタフェース (GUI) を介してエンド ユーザが使用できるようにエクスポーズされます。ユーザ インタフェース (GUI) には、BEA WebLogic Portal® などのトランザクション ポータル、または BEA AquaLogic Interaction などのコラボレーティブ ポータルがあります。
AquaLogic Service Bus は、メッセージを取得し、それを処理してルーティング先を決定し、指定どおりに変換する仲介役として機能します。HTTP(S)、JMS、ファイル、FTP などの転送プロトコルを介してメッセージを受信し、同じ転送プロトコルまたは別の転送プロトコルを使用してメッセージを送信します。メッセージへの応答はこの逆の処理になります。AquaLogic Service Bus によるメッセージ処理は、AquaLogic Service Bus Console でプロキシ サービスの「メッセージ フロー定義」で指定されたメタデータを基準に行われます。
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 を使用することで、自律的な ESB インスタンスを企業全体にコンフィグレーションすることができます。これらのインスタンスは、サービスやトランスフォーメーションなどの、コンフィグレーション アーティファクトの独自のセットを持っています。通常、このようなデプロイメントでは、組織内のさまざまな IT 部門にマップします。異なる部門間の通信は、多くの場合ファイアウォールを介して互いにやり取りする、ESB の連携ネットワークを介して行われます。
AquaLogic Service Bus は、中央での調整も可能にします。この場合、AquaLogic Service Bus の中央のデプロイメントがガバナンスと調整を処理し、ネットワーク内のすべての ESB は、中央の ESB を介して通信します。
AquaLogic Service Bus は、JMS ストア アンド フォワードを使用して、連携ネットワーク間の信頼性の高い、保証されたメッセージングを可能にします。また、動的ルーティング機能も、このネットワークのコンフィグレーションを簡略化します。
AquaLogic Service Bus では、制御された環境でのリソースおよびサービスのコンフィグレーションを可能にすることにより、企業の変更管理のベスト プラクティスをサポートします。コンフィグレーションをエクスポートし、別のテスト用ステージング ドメインにインポートしてプロモーションの最終準備を行ってから、プロダクション ドメインにインポートできます。AquaLogic Service Bus では、インポート先ドメインの要件に合わせて環境固有の要素を再コンフィグレーションできます。AquaLogic Service Bus での変更管理およびリソース編成の詳細については、「変更管理とリソース編成」および『Best Practices for Deploying AquaLogic Service Bus Resources』を参照してください。
ESB、メッセージ ブローカリング、および Web サービス管理 (WSM) の概念を 1 つの製品に融合することにより、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 サービスなどです。異なる転送の組み合わせが可能です (たとえば、同期と非同期のブリッジングがサポートされます)。
以降の節では、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 の転送レイヤおよびバインディング レイヤを介して実行されます。
エンドポイント (ビジネス サービスまたは別のプロキシ サービス) にメッセージが送信されると、AquaLogic Service Bus では上記のイベント シーケンスと同様のモデルで応答メッセージが処理されます。
図 1-9 は、着信エンドポイント (プロキシ サービス) から発信エンドポイント (サービスの転送 URL (ビジネス サービスや他のプロキシ サービス)) までの AquaLogic Service Bus のメッセージ フローの概要を示します。
以降の節では、このメッセージ処理に関連する各レイヤについて説明します。
メッセージ フローは、AquaLogic Service Bus のプロキシ サービスの定義です。AquaLogic Service Bus のプロキシ サービスの実装は、パイプライン、ブランチ ノード、およびルート ノードによって定義されます。
AquaLogic Service Bus Console を使用して、プロキシ サービスのメッセージ フローの定義におけるメッセージ処理ロジックをコンフィグレーションできます。このロジックには、トランスフォーメーション、パブリッシュ、レポートなどのアクティビティが含まれます。ロジックはメッセージ フロー内の個々のアクションでコンフィグレーションされます。
図 1-10 は、メッセージ フロー定義のコンポーネントの概要を示します。
パイプライン ロジックは、「要求パイプライン」定義と「応答パイプライン」定義で構成される 1 組の定義です。要求パイプライン定義は、ビジネス サービスまたは別のプロキシ サービスを呼び出す前に、プロキシ サービスへの要求メッセージに対して AquaLogic Service Bus が実行するアクションを指定します。応答パイプライン定義は、プロキシ サービスが応答を返す前に、プロキシ サービスによって呼び出されたサービスからの応答に対して AquaLogic Service Bus が実行する処理を指定します。ルーティングは、メッセージ フローの最後にルート ノードによって実行されます。
| 注意 : | WS-Security の処理および認可は、パイプライン実行の前後に透過的に実行されます。 |
各パイプラインは、アクションを含む一連のステージで構成されます。1 つのステージは、トランスフォーメーションやパブリッシュなどの、ユーザがコンフィグレーションする処理手順です。メッセージ フローに送られるメッセージには、メッセージのコンテンツを含む一連の「メッセージ コンテキスト変数」が付けられ、パイプライン ステージのアクションによってアクセスしたり変更することができます。
次の表は、AquaLogic Service Bus のパイプライン ステージ、ブランチ、およびルート ノードでサポートされるアクションを示します。
|
ステージでは、必要に応じて 1 つのサービス レベル要求パイプラインを複数のオペレーション パイプラインに分岐することができます (1 つのオペレーションに対して最大 1 つのオペレーション パイプラインと、必要に応じてデフォルトのオペレーション パイプライン)。オペレーションはユーザが選択する条件によって決定されます。応答処理は関連するオペレーション パイプラインから開始され、1 つのサービス レベル応答パイプラインに結合されます。
図 1-11 は、プロキシ サービスのオペレーション パイプラインの例を示しています。
一方向のオペレーションの場合、応答パイプラインは空のメッセージで実行されます。これにより、プロキシ サービスに応答を作成でき、双方向 (要求/応答) と一方向のオペレーションの間のブリッジングが可能になります。ブリッジング メカニズムとは、プロキシ サービスの入力が一方向であっても、出力は双方向 (要求/応答) になること (またはその逆) を意味します。プロキシ サービスは、呼び出したサービスからの応答を取得するか、クライアントへの応答を生成します。メッセージがビジネス サービスまたはプロキシ サービスにルーティングされてから、応答フローのアクションを使用してメッセージの後処理を実行することもできます。
ブランチ ノードを使用すると、可能ないくつかのパスのうちの 1 つに限定して処理を進ませることができます。ブランチ処理は、単純でありながらユニークなストリング値のタグが付いたブランチをまとめた簡単なルックアップ表を基準に行われます。メッセージ コンテキストの変数をそのノードのルックアップ変数として指定し、この値を使用してどのブランチに進むかが判断されます。ルックアップ変数に一致するブランチがない場合は、デフォルトのブランチに進みます。ルックアップ変数の値は、ブランチ ノードに到達する前に設定する必要があります。このアプローチにより、そのブランチ ノード自体の中での例外の発生を防ぐことができます。ブランチ ノードでは、メッセージ フロー ツリー内にいくつかの子孫を持つことができます (デフォルトのブランチを含め各ブランチに 1 つずつ)。
ルート ノードは他のサービスとの要求通信と応答通信に使用されます。ルート ノードはプロキシ サービスに関する要求処理と応答処理の境界を表します。ルート ノードが要求メッセージをディスパッチすると、要求処理が終了したと見なされます。ルート ノードが応答メッセージを受信したときに、応答処理が始まります。ルート ノードは、発信トランスフォーメーション、応答トランスフォーメーション、および条件付きルーティングに対応します。
| 注意 : | ルート ノードまたはブランチ ノードでも条件をコンフィグレーションできます。 |
ルート ノードは要求処理と応答処理の境界を表すので、メッセージ フロー ツリー内に子孫を持つことはできません。
  
|
