レベル: 中級 Helen M Wylie, Integration Architect, IBM
Peter Lambros, IBM Senior Technical Staff Member, Mediation and Transformation Technologies, IBM
2009年 03月 10日 この記事では、アプリケーションの接続性という分野で共通するいくつかのソリューションをカプセル化した一連の接続性パターンを取り上げ、その内容を定義します。これらのパターンの多くは、エンタープライズ・サービス・バス (ESB) として知られる一般的なアーキテクチャー・パターンをベースに改良を加えたものです。パターンの分類方式を定義し、パターンの選択と実装を左右するさまざまな要因について検討する際には、この記事、そして「参考文献」で紹介している developerWorks Wikis が、特定の接続性要件に最適なソリューションを選択する上で役立つはずです。
はじめに
エンタープライズ・サービス・バス (ESB) の価値はエンタープライズ統合の実践において十分に理解されているものの、ESB が提供する優れた柔軟性自体が、統合アーキテクチャーを計画したり、構築したりする際の選択肢の多さの原因となって困惑を招くことになります (「参考文献」を参照)。さらに事態を悪化させるのは、ESB アーキテクチャー・パターンをサポートするミドルウェア製品が提供する機能の範囲です。その上、これらの製品が一般にサポートするのは、サービス・バスの極めて具体的な概念、つまり、広範なサービス指向アーキテクチャーのコンテキストでサービスを接続し、仮想化するためのインフラストラクチャーという概念だけではありません。それよりも広義の概念で、非常に包括的な意味でのサービスの接続性インフラストラクチャーとしてのサービス・バスもサポートします。この記事では、サービス・バス (またはエンタープライズ・サービス・バス) という用語を、この広義な意味で使用します。
現実の多くの実装で得た経験を踏まえ、その経験から一連の中核的パターンを概念化することで、適切なアーキテクチャーおよび実装を決定するためのフレームワークがもたらされます。また、このようなフレームワークでは、製品の選択とその製品を使用するのが容易になり、エンタープライズ・アプリケーションとサービスの統合に推奨された実証済みの一連の手法が有効に生かされることになります。接続性パターンを選択して記述する際には、以下のようにさまざまな観点からの考慮が必要です (図 1 を参照)。
- 統合ソリューション全体のアーキテクチャー・パターン (Integration Architecture)
- エンドポイント間に規定された対話スタイル (Interaction Style)
- 必要な動作上のアスペクト (Operational Aspects)
- 適用するセキュリティー・モデル (Security Model)
上記の点をすべて踏まえた上で、特定の接続性メディエーション・パターンを定義します。
図 1. 接続性パターンの観点
この記事では、IBM WebSphere Enterprise Service Bus 製品ライン、具体的には WebSphere Message Broker、WebSphere ESB、および WebSphere DataPower Integration Appliance XI50 を使用して実装するソリューションで一般的となっている一連の接続性パターンを紹介します。これらのパターンの詳細な仕様、および対応する実装情報とサンプルは、現在進行中の作業です。その現状については、developerWorks Wikis の「Enterprise Connectivity Patterns」でそれぞれのパターンを参照してください。
接続性ソリューションのアーキテクチャー・パターン
統合アーキテクチャーを全体的に見ると、接続性ソリューションのパターンは以下の 6 つの共通カテゴリーに分けることができます。
- サービス仮想化
- サービス・イネーブルメント
- ゲートウェイ
- メッセージ・ベースの統合
- ファイル処理
- イベント駆動型統合
上記のそれぞれについて、以降のセクションで詳しく説明していきます。
サービス仮想化
サービス仮想化パターンは、Enterprise Service Bus によってサービスとサービスとの間に間接的なレベルを設けることにより、真のサービス間の疎結合を実現します。別の見方をすれば、サービス指向アーキテクチャーで接続性のニーズに対処する際にも、サービス仮想化パターンがサービス間のメディエーション要件 (ルーティング、プロトコル変換、データ・フォーマット変換、ロギングなど) に対処します。
サービス仮想化パターンはサービス・バスの定義を絞り込んでカプセル化するため、通常は以下のような明確な要件に対処するために使用されます。
- 疎結合 – ESB で既存のサービスを仮想サービスとして表現する
- フォーマット変換、機能強化などを含めるためのプロバイダー・ファサードを提供する
- 標準以外のサービスに標準インターフェースを提供するためのプロバイダー・ファサードを提供する
- 標準サービス管理ユーティリティー (セキュリティー、ロギング、監視、課金など) を提供する
図 2. サービス仮想化パターン
このパターンの例には、以下のものがあります。
- 単純なサービス・プロキシー
サービス・プロキシーの使用は ESB の基本パターンの 1 つで、大抵のサービス指向アーキテクチャーの要件である疎結合を実現します。このパターンは既存のサービスを新しい仮想サービスとして ESB にデプロイすることによって、既存のサービスへのアクセスが、管理されたアクセス・ポイントを介して行われるようにします。また、アクセスには元のプロバイダーとは異なるプロトコルを使用することもできます。メディエーション・ポイントを導入するという点で最も単純なこの ESB パターンでは、メディエーションが各種のロギングやセキュリティー構成に限定されることがよくありますが、ESB をメディエーション・ポイントとして導入すると、エラー処理やアラート、そしてトラフィック管理、サービス課金、パフォーマンス測定などのサービス管理機能を導入することも可能になります。他の多くのパターンは、この基本パターンを装飾した形となっています。
SOA でのサービス・ガバナンスをサポートするこのパターンは、多くの場合、ビジネス・レベルあるいはエンタープライズ・レベルのすべてのサービスへのアクセスはバスを介してのみ行うという要件、そしてこのようなサービスすべてに対して標準管理機能を義務付けるという要件に関連して使用されます。
このパターンは、アクセスをセキュアにし、組織の IT インフラストラクチャーの内部構造を隠す手段にもなります。したがって、エンタープライズ独自のセキュリティー・ゾーンの外からサービスにアクセスできるようにする際には、このパターンが出発点となります。
- サービス・セレクター (ルーター)
このサービス・セレクター・パターンは単純なサービス・プロキシー・パターンを拡張し、サービス・リクエストのルーティングという概念を導入します。このパターンでは、疎結合を維持するための単純なエンドポイントの探索を行いますが、メッセージ内に含まれるデータやリクエストのタイミング、あるいは代替プロバイダー・サービスのステータスに応じてルーティングするために使用することもできます。
このパターンを使用する状況として考えられるのは、各地に散らばるセンターでサービス・プロバイダーの複数のインスタンスがホストされているときに、アカウントの詳細に応じて適切なサービスを選択する場合です。また、ある程度のサービス停止時間が必要なグローバル企業で 24 時間週 7 日のサービスを維持するためや、カスタマーの優先順位や価値の高いサービス・リクエストのインスタンスを基準とした優先順位によるルーティングを行うためにも使用することができます。
- サービス変換機能
サービス変換機能パターンも同じく、単純なサービス・プロキシー・パターンの拡張です。バス上でエンド・プロバイダーのインターフェースをエンタープライズ・サービスのインターフェースとして公開することが常に適切であるとは限りません。そこで、このサービス変換機能パターンでは、ESB によって表されるインターフェースをエンド・プロバイダーのインターフェースとは別のものに変換できるようにします。
大抵は、企業全体でのデータ標準化が目標とされますが、これはほとんどの場合、実現可能な理念ではありません。その一方、標準フォーマットを定義すれば、新しい開発を簡易化することができます。そして標準データ・モデルが定義されていれば、企業の標準をプロバイダー固有の標準に変換するプロバイダー・サービスにサービス・ファサードを提供するという方法によって、このパターンを実装することができます。
- サービス・ノーマライザー
変換機能パターンとルーター・パターンの両方を拡張したこのパターンは、代替サービス・プロバイダーによって意味的に同じサービスを異なるインターフェースで提供するという概念をサポートします。ルーティングはサービス・セレクター・パターンの場合と同じ方法で決定され、ルーティングによってターゲット・サービスとインターフェースが決定された後、サービス・リクエストに変換が適用されます。
このパターンでは、ESB が各リクエストに最適なプロバイダーを判断して、必要な変換を適用してからプロバイダー・サービスを呼び出すため、ESB 上の仮想サービスに対して提供するインターフェースを 1 つにすることができます。
- バージョン・セレクター
サービス変換機能パターンを特殊化したこのパターンは、他のさまざまなパターンにも適用できる極めて独特な原理があるため、他のパターンには依存しません。変換機能パターンはリクエストのルーティングを目的としていますが、バージョン・セレクターは、クライアントのリクエストが適切なサービス・バージョンにルーティングされることを確実にするために使用されます。
 |
サービス・イネーブルメント
このカテゴリーのパターンは、それ自体はサービス・インターフェースを提示しない機能をカプセル化するという問題に対処し、その機能をサービス指向のインターフェースによって提示します。エンタープライズ・アプリケーションの統合に関する従来の概念からサービス指向アーキテクチャーへの移行を表すこのパターンを利用すると、大幅な変更をすることなく既存のアセットを新しいスタイルで再利用できるようになります。サービス・イネーブルメントによって可能になる ESB の実装は、企業全体でさまざまな技術を使って実装された機能から派生した「サービス」にアクセスできるようにし、サービスのコンシューマーがこれらのサービスを一貫性のある 1 つのサービスとして捉えられるようにします。
図 3. サービス・イネーブルメント・パターン
このパターンの主な例は、以下のとおりです。
- 単純なサービス・ファサード
このパターンの最も単純な形は、サービス・プロキシーの形と似ていますが、このパターンの場合、サービス・リクエストを満たすのはサービス・プロバイダーではなく、メッセージ、アダプター、またはその他の API によってアクセスする既存のアプリケーションです。アダプターはアプリケーションと一緒に配置することもできますが、一般的には ESB コンポーネントとして実装されます。
サービス仮想化を拡張したのと同様の方法で、ルーティング、変換、正規化によって、このパターンを拡張することもできます。
- 複合サービス・ファサード
さらに拡張したパターンでは、ESB のより充実した機能から統合ロジックを取り込んで、(場合によっては機能の複数のソースを使用して) サービス機能を作成し、その機能を ESB 上で仮想サービスとして提示する場合もあります。このパターンがよく使われるのは、下位レベルの IT サービス、コンポーネント、あるいは細分化されたアプリケーション機能から、上位レベルのビジネス・サービスやエンタープライズ・サービスを作成する場合です。
統合ロジックはさまざまな方法で作成することができますが、典型的な例は、一連の呼び出し、複数のリクエストによるレスポンスの集約、あるいは情報の配布という方法です。
- クライアント・アクセス
この一連のパターンは、サービス指向クライアント・アクセスには使用できないクライアントにエントリー・ポイントを提供します。大抵はアダプターという手段によって、SOA の手法を採り入れたエンタープライズ・アーキテクチャーの導入に、既存のパッケージ・アプリケーションが参加できるようにします。
ゲートウェイ
ゲートウェイはメッセージ・バスまたはサービス・バスの一部としてすべての着信メッセージに適用され、フォーマットに依存しない境界機能を提供します。
境界機能は通常、実行するアクションを決定するために、標準ヘッダー (トランスポート、SOAP、あるいはデータ・レベルにある) のデータを利用しますが、メッセージ・データ (または本体) の完全なフォーマットを認識する必要はありません。ゲートウェイ・パターンはアクションを決定した後に、サービスを直接呼び出す場合も、他のパターンを起動する場合もあります。これらの境界機能には以下のものがあります。
- リクエストのルーティング
- 認証
- 権限付与
- 監査およびロギング
- プロトコル変換
- レスポンスの相関
図 4. ゲートウェイ・パターン
ゲートウェイ・パターンの例には、以下のものがあります。
- セキュリティー・ゲートウェイ
これは比較的特有なゲートウェイ・パターンの例です。このパターンでは標準以外のすべてのセキュリティー処理の負担をメイン・インフラストラクチャーから取り除き、実際の宛先を呼び出す前に、認証、権限付与、そして場合によっては監査を行います。このモードでは必ずと言ってよいほど、ゲートウェイと ESB のその他の部分を結ぶ信頼できるリンクがあるため、ESB のゲートウェイ以外の部分に必要なセキュリティー・モデルを単純化することができます。セキュリティー・ゲートウェイが ESB の残りの部分とは異なるセキュリティー・ゾーンに常駐し、外部クライアントとの接続性を提供する場合もあります。この場合のパターンは、広範な着信セキュリティー・プロトコルをサポートすると同時に、他の ESB コンポーネントのセキュリティーを単純化します。
- サービス・コネクター
このゲートウェイ・パターンをサービス指向の原則に従ってエンタープライズ・アーキテクチャーの一部として導入した場合、多数の既存のサービスを ESB に接続する最も単純な方法となります。ゲートウェイはエンタープライズ・アーキテクチャーに制御ポイントを導入するため、サービスごとに個別のメディエーション・フローを作成しなくても、サービス・レジストリーとそれに関連するガバナンスの管理下で臨機応変にさまざまなサービスを実現することができます。ゲートウェイに入ったメッセージは、エンド・プロバイダー、プロバイダー・ファサード、あるいはメディエーション・フローにルーティングされます。
- 境界メディエーター
境界メディエーター・パターンはサービス接続パターンを拡張し、標準メディエーションをすべての着信 (あるいは送信) サービス・リクエストまたはメッセージに適用できるようにします。これらの (コンテンツに依存しない) 標準的なメディエーションをいったんゲートウェイで作成すれば、そのメディエーションをあらゆる着信メッセージに適用することができます。作成するメディエーションには、検証、ロギング、監査、認証、権限付与のいずれか、あるいはそのすべてを含めることができます。また、メディエーションは普遍的に適用することも、ゲートウェイ・プロパティーや、リクエスト・データを基準とした検索、あるいは着信リクエストに含まれる (通常はヘッダー内の) データなどに応じて選択的に適用することもできます。
|
メッセージ・ベースの統合
ESB は、「インフラストラクチャー・レベル」のメッセージをベースとした「アプリケーション」を作成してデプロイするための環境を提供することによって、既存のメッセージング・インフラストラクチャーを拡張することができます。このような「アプリケーション」の例には、ルーティングおよび変換サービス、ロギング・サービスなどがあります。ESB はベースになっているメッセージング・インフラストラクチャーを拡張する場合もあれば、異なる製品と技術を結ぶブリッジを提供する場合もあります。組み込みメッセージング機能のないアプリケーションまたはサービスへのアクセスを提供する場合にはアダプターを使用することができます。
図 5. メッセージ・ベースの統合パターン
機能の点から言うと、メッセージ・ベースのパターンはある意味でサービス仮想化パターンに相当します。ただし、この 2 つのパターンに対する捉え方には大きな違いがあります。サービス指向モデルで一般に焦点となるのは、多くの任意の「クライアント」が使用できるサービスを提供することです。つまり、全体をプロバイダーとコンシューマーという観点で捉えます。一方、メッセージ指向モデルではサービスよりも、システム全体でやり取りされるデータ、そしてこの移動中のデータに適用する一連のアクションを中心に考えるのが一般的です。つまり、プロデューサーとコンシューマーという観点で捉えます。この 2 つの考え方は全く異なるというわけではありませんが、それぞれのパターンに適用しようとするコンテキストに影響を与えます。
以下に具体的な例をいくつか挙げます。
- メッセージ・ルーター
メッセージ・ルーター・パターンは、データを交換する必要のあるアプリケーション間、またはサービス間を強固に分離するために使われます。その実現方法は、あるアプリケーションから送信されたデータを、各種の条件に応じて複数の潜在的なターゲット・アプリケーションのなかから選択された 1 つのターゲット・アプリケーションにルーティングできるようにすることによります。
コンテキスト・ベースのルーターは、送信元の ID を基準に、あるいはプロトコル・ヘッダーに含まれるデータの何らかの側面に応じて適切なターゲットを選択します。コンテンツ・ベースのルーターは、メッセージ・ペイロードのコンテンツを基準に選択を行います。そして負荷ベースのルーターは、さまざまなターゲット・システムでのアプリケーションの負荷に関する情報を使用します。
- メッセージ変換機能
メッセージ変換機能パターンを使用すると、あるアプリケーションからのデータを、別のアプリケーションが必要とするデータ・フォーマットにマッピングすることができます。この場合、どちらのアプリケーションも、このようなマッピングが必要であること、またはマッピングが行われていることを認識しません。このパターンは、直接のマッピングから、場合によっては検索や相互参照が関わってくる極めて複雑な変換にまで対応します。
- メッセージング・ブリッジ
メッセージング・ブリッジ・パターンは、メッセージ・ペイロードのフォーマットやコンテンツを変更することなく、トランスポート・メカニズム間でデータをマッピングします。このパターンの実装では、個々のメッセージング・システムがそれぞれに異なるアドレス指定方式を使用している場合には、アドレス指定方式間のマッピングも処理する必要があります。
このパターンが頻繁に用いられている例は、異なるベンダーによる JMS 実装間のブリッジングです。
- メッセージ集約機能
メッセージ集約機能パターンが対処するのは、1 つ以上のアプリケーションから複数のメッセージを取得し、これらのメッセージを 1 つのデータにマージして新規メッセージとして伝播しなければならない場合です。インバウンド・メッセージは、単独のアプリケーションから送信されたメッセージであることも、一連のアプリケーションがメッセージ分割機能パターン (以下で説明) の実装から受信したリクエストに応答して非同期で送信するレスポンス・メッセージであることもあります。
このパターンの実装は、個々のソース・メッセージを単純に連結することも、一連のより高度なデータ・マッピング機能を統合することもあります。さらにこのパターンの実装は、規定された時間内に必要とされるインバウンド・メッセージが到達しないという障害や、その後遅れて到達したメッセージにも対処できるようでなければなりません。
- メッセージ分割機能
メッセージ分割機能パターンは、メッセージのサブセットを抽出し、これらのサブセットを個別のメッセージとして複数のターゲット・アプリケーションに送信します。元のインバウンド・メッセージを構成部分に分割する方法は、一連のマッピング・ルールによって定義されます。
- メッセージ・リクエスト/レスポンス相関機能
典型的なメッセージ・ブローカー・システムは大抵の場合、同じストリームやキューからの複数のリクエストを並行して非同期に処理しています。このようなリクエストを他の 1 つ以上のシステムにルーティングするときには、レスポンス・メッセージを元のリクエストに相関させなければなりません。メッセージ・リクエスト/レスポンス相関機能パターンは、この特定の問題に対するソリューションとなります。
|
ファイル処理
ESB は、ファイルを (ローカルで、または FTP プロトコルを使用して) 処理するための管理された実行環境を提供することができます。
図 6. ファイル処理パターン
一般にこのパターンに必要となるアクティビティーは、ファイルに保持されたデータのフォーマットまたはデータそのものを変換すること、ファイルを複数の個々のトランザクション・レコードに「断片化」すること、レコードをルーティングすること、レコードをターゲット・ファイルに集積すること、指定されたロケーション/プロセッサーにファイル (ファイル全体、または個々のレコード) をルーティングすることなどです。以下に、このパターンの例とその使用法を説明します。
- ファイル・レコード・プロセッサー
このパターンは、入力ファイルに含まれる各レコードを処理し、処理後のレコードを 1 つ以上の「一時的」なターゲット・ファイルに集積します。集積が完了すると、このターゲット・ファイルがターゲット・ディレクトリーに移されます。このパターンがサポートするのは、インターバル最後のトランザクションが含まれるバッチ・ファイルを処理しなければならない場合です。ここで言う処理とは、ソース・システムとターゲット・システムがトランザクション・インターフェースをサポートできない場合に、集積された 1 日分のトランザクションを転送することであったり、あるいは特定の時点に予定されているトランザクションを転送することであったりします。
- レコード集積機能
このパターンは、サービス・リクエストやメッセージに含まれるデータ、またはアダプターからのデータを受け取り、データを処理した結果生成されたレコードを一時ファイルに集積していきます。集積し終わると、このファイルをターゲットに移します。このパターンがサポートする対話動作は、新しいシステムと、バッチ・インターフェースのみをサポートするレガシー・システムとの間の対話動作です。サービス指向アーキテクチャーへの移行、あるいは買収によって得たバッチ・システムをトランザクション環境に統合する過程では、このパターンが最初のステップとなる可能性があります。このパターンはまた、請求、課金、契約上の問題、契約に関する文書、そして契約更新のお知らせといった、夜間バッチの実行によるデータを集積しなければならない場合にも対応します。
- ファイル・レコード・ディストリビューター
このパターンは、ファイルを複数のレコードに分割し、それぞれのレコードを使用してサービス呼び出しを行ったり、トランザクション・インターフェースを備えた 1 つ以上のシステムにメッセージを渡したりします。このパターンの一般的な用途は、個別にルーティングされて処理される各種のトランザクションが含まれる EDI ファイルの処理です。この方法はまた、特に指定の開始日で更新するときのようには更新のタイミングが重要でない場合に、参照データでシステムを更新するために使用することもできます。
イベント駆動型統合
この記事で紹介しているのは、ESB を介した接続性に関連するパターンであって、「イベント駆動型アーキテクチャー」を対象としたすべてのパターンを明らかにしようとしているわけではありません。その一方で、さまざまなアプリケーション・シナリオに適用できる用語や、「イベント駆動型アーキテクチャー」についての明確な定義はまだありませんが、ESB が重要な役割を果たす「EDA」のシナリオがあります。これらのシナリオには、情報やイベント・ストリームのフィルタリング機能、「リアルタイム」(アプリケーションに必要な速度という意味) でのイベント配布、そして物理デバイス (検出器、センターなど) からのイベントの処理などをはじめとする、複合イベント処理エンジンとの統合が含まれています。
図 7. イベント駆動型統合パターン
以下に、このパターンの例とその用途を説明します。
- イベント・ディストリビューター
このパターンは、公開 (パブリッシュ) されているイベントのうち、タグ (「トピック」) に対応するイベントや、各イベントに関連付けられたデータに応じたイベントなどを通知するように登録している複数の関係者に対し、イベントを (「トピック」および関連データ別に適切に分類して) 配布します。データは ESB 上の公開ポイントに公開され、その公開ポイントから、該当する情報に登録したすべての購読者 (サブスクライバー) に配布されます。
公開ポイントに公開されたイベントが、ステータスの変更を表すこともあります。この場合、それが新規であるか更新の要求であるかに関わらず、すべての購読者は最新のステータスを入手することができます。あるいは、イベントがデータのストリームを表し、各「イベント」が配布されてから削除されるという場合もあります。
- イベント・フィルター
このパターンは、ESB に入ってきたイベント (対話) を処理し、イベントをフィルタリングして、イベント・エンジンに渡す重要イベントのストリームに変換します。イベントは、複合イベントを検出するためのイベント処理エンジンに渡されることも、ビジネス・イベントを監視するシステム (例えば、ダッシュボード・アプリケーション) に渡されることもあります。このパターンは片方向の通信をサポートし、イベント・エンジンに対するプリプロセッサーとしてのみ機能します。
このパターンが具体的に専門としているのは、各種のセンサー、アクチュエーター、アダプターからのデータのためのエントリー・ポイントを提供することです。
- イベント・エクストラター
このパターンは ESB での対話を監視して処理し、関連するイベントを抽出してイベント処理エンジンに渡します。このパターンも同じく片方向の通信をサポートし、イベント・エンジンに対するプリプロセッサーとしてのみ機能します。
- イベント・リアクター
このパターンは、イベント・エンジンのプリプロセッサーとして機能するという点では、前述のパターンと同じですが、このパターンはイベント・エンジンとの同期対話をサポートします。そのため、最新のイベントによって複合イベントが発生したことを示すレスポンスを受け取ることができます。このようなレスポンスを受信すると、ESB フローはそのイベントへのレスポンスとして、例えば、該当するイベントの発生時に作動すべきターゲットに対してアラートを発します。
|
動作アスペクト
バスのアスペクト指向の接続性フィーチャーには、以降のセクションで説明する対話スタイルおよびセキュリティー・モデルがあります。これらの対話スタイルおよびセキュリティー・モデルには通常、以下のような標準的なサービス管理機能またはユーティリティーが組み込まれています。
- 検証
- ロギング
- 監査
- エラー処理
- SLA/パフォーマンス測定
メディエーションのこれらのアスペクトは概念上のものであり、ソリューション・アーキテクチャー全体のニーズに応じて具体的な統合パターンに結合されます。
対話スタイル
契約上の動作パターンによって、対話スタイルとサービス品質が定義されます。私たちが現在特定している主要な対話パターンには、以下の 8 つがあります。
- 片方向保証付き配信
- 同期読み取りリクエスト
- トランザクションなしの同期更新
- グローバル・トランザクションを使用した同期更新
- 確認応答およびコールバックを使用した同期更新リクエスト
- 確認応答を使用した同期更新リクエスト (ESB がエラーを処理する場合)
- 非同期コールバックを使用した片方向の対話動作
- 完了ステータスのポーリングを使用した片方向の対話動作
上記のパターンは概念上のものです。これらのパターンが、同期/非同期インターフェース、配信保証レベル、タイムアウトおよび遅延レスポンスの処理、そしてエラー処理という点に関して対話がどのように行われるかを定義します。このような動作の契約は直接実装されるのではなく、特定の統合パターンと結合されて具体的な動作パターンが作成されます。
|
片方向保証付き配信
| |
この対話パターンの目的は、リクエストが確実に配信されて処理されるようにすることです。
- すべての通信が保証されます。
- 呼び出されたコンポーネントのそれぞれが、エラーを確実にレポートします。
- メッセージは障害が発生しても保存されます。
- ESB はメッセージを拒否することなく処理を試みます。
- エラーは完全なメッセージ・コンテンツとともに取り込まれます。
- エラー処理 (ESB のスコープ外) によって問題を修正します。
- SLA はスループット (時間内のメッセージ数/リクエスト数) として測定する必要があります。
|
| |
|
|
| |
同期読み取りリクエスト
| |
このパターンの目的は、障害発生時に副次作用のない単純なリクエスト・メカニズムを提供することです。
- リクエスター (要求側) はレスポンスを待機しますが、タイムアウトが適用されます。
- プロバイダーからのタイムリーなレスポンスは保証されません。
- ESB の待機時間はリクエスターより短く、ESB からリクエスターに対して明示的なタイムアウト・エラーが発行される場合があります。
- メッセージは保存されません。
- SLA はレスポンス時間 (レスポンスが到着するまでの所要時間) として測定する必要があります。
|
| |
|
|
| |
トランザクションなしの同期更新
| |
このパターンの目的は、配信や処理を保証しない更新メカニズムを提供することです。この更新メカニズムでは、リクエスターがエラーやタイムアウトの処理を行うことになります。
- 同期読み取りリクエストは基本動作です。
- タイムアウト時のリクエスターによるエラー処理には、以下の内容が考えられます。
- 操作が冪等 (べきとう) で、エラーがタイムアウトである場合の操作反復
- 期間終了時の調整
- 手動エラー処理または半自動エラー処理の呼び出し
- 呼び出しに対するプロバイダーへのレスポンスでタイムアウトまたはエラーが発生した場合の ESB によるエラー処理には、以下のものがあります。
- 操作がべき等で、エラーがタイムアウトである場合の操作反復
- クライアントへの通知
- エラー・キューへの配置
- 期間終了時の調整
- SLA はレスポンス時間 (レスポンスが到着するまでの所要時間) として測定する必要があります。
|
| |
|
|
| |
グローバル・トランザクションを使用した同期更新
| |
このパターンの目的は、サービス・リクエスター、ESB、およびサービス・プロバイダー全体で更新を同期するメカニズムを提供することです。
- すべての参加コンポーネントが、トランザクション調整について同意したプロトコル (WS-AtomicTransaction など) をサポートする必要があります。
- コミットが失敗すると、どのコンポーネントが更新を行ったかに関わらず、すべての更新がロールバックされます。
- トランザクションが行われている最中は、リソースがロックされます。
- すべての参加コンポーネントは、トランザクションが指定の時間内に完了しなかった場合のロールバックに備える必要があります。
- SLA はレスポンス時間 (トランザクションが完了するまでの所要時間) として測定する必要があります。
|
| |
|
|
| |
確認応答およびコールバックを使用した同期更新リクエスト
| |
このパターンの目的は、同期プロトコルを使用するリクエスターが、リクエストが送信済みで処理されることを認識できるようにするとともに、リクエストの処理が完了した時点でリクエスターに通知できるようにすることです。
- リクエスターは、同期プロトコル/動作のみをサポートします。
- リクエスターが更新リクエストを行い、そのリクエストが受け付けられた (または拒否された) ことを示す確認応答を受け取ります。
- ESB は、メッセージが保護されるまでは確認応答を行いません。
- ESB は保証付き配信を使用して、プロバイダーに対する更新リクエストを行います。
- プロバイダー・サービスは、更新結果を (非同期で) コールバックするという動作に同意している状態です。
- リクエスターが未処理の更新リクエストのリストを保持する場合もあります。
- ブローカーは、リクエスターがコールバックを受信したことを確実にする必要があります (タイムアウトの場合には再試行)。
- エラー処理は任意の参加コンポーネントに割り当てることができます。
- SLA は、確認応答のレスポンス時間、および期間中に満たされたリクエスト数として測定する必要があります。
|
| |
|
|
| |
確認応答を使用した同期更新リクエスト (ESB がエラーを処理する場合)
| |
このパターンの目的は、同期プロトコルを使用するリクエスターが、リクエストが送信済みで処理されることを認識できるようにすることです。このパターンは、エラーが処理され、リクエスターにコールバックが行われないことを保証します。
- リクエスターは、同期プロトコル/動作のみをサポートします。
- リクエスターが更新リクエストを行い、そのリクエストが受け付けられた (または拒否された) ことを示す確認応答を受け取ります (受け付けられたアクションが、ブローカーまたはプロバイダーによって保証されている場合)。
- ESB は保証付き配信を使用して、プロバイダーに対して更新リクエストを行います。あるいは失敗した場合には、エラー処理を呼び出します。
- プロバイダー・サービスは、更新が行われること、またはエラー処理プロセスが呼び出されることを確実にするための動作に同意している状態です。
- SLA は、確認応答のレスポンス時間または時間内に受け付けられたリクエスト数、あるいはその両方で測定する必要があります。
|
| |
|
| |
非同期コールバックを使用した片方向の対話動作
|
- リクエストは片方向で確実に行われる一方、サービス・プロバイダーは元のリクエスターに対して非同期呼び出しを返すことができます。
- SLA はスループット (時間内のメッセージ数/リクエスト数) として測定されます
|
| |
| |
| |
完了ステータスのポーリングを使用した片方向の対話動作
|
- すべての通信が保証されます。
- それぞれの参加コンポーネントは、次の参加コンポーネントが期待される動作に従って確実に実行することに依存します。
- 呼び出されたコンポーネントのそれぞれが、エラー処理プロセスに対して確実にエラーをレポートする必要があります。
- メッセージは、システム障害が発生しても保存される必要があります。
- リクエスターはプロバイダーをポーリングして、更新が完了したかどうかを判断します。
- SLA はスループット (時間内のメッセージ数/リクエスト数) として測定する必要があります。
|
| |
|
|
|
|
セキュリティー・モデル
セキュリティー・モデルおよびパターンを定義する際には、以下の 2 つの側面を検討しなければなりません。
- 参加コンポーネントのセット
- 必要なセキュリティー実施ポリシーのセット
認証、権限付与、監査、機密性、完全性、およびユーザビリティーに関する要件を満たし、パフォーマンスが許容できないレベルにまで劣化しないことを確実にするためには、参加コンポーネントのすべてがセキュリティーを実施する必要があります。
SOA セキュリティー・モデルの参加コンポーネント
あらゆるサービス・ベースの対話に参加する主要なコンポーネントには以下のものがあります。
- リクエストを行っているアプリケーションまたはプロセス
- 仲介サービス: リクエスターとプロバイダーとの間に統合機能を提供するミドルウェア機能。多くの場合、バスまたは ESB クラスがこれに該当します。
- プロバイダー・アプリケーション/サービス・プロバイダー
上記のコンポーネントに基本的なセキュリティー強化が行われてから、パターンのベースとなっている信頼できるモデルによって、実行時の対話に関連するセキュリティー機能が参加コンポーネントのそれぞれに割り当てられることが前提となります。
主要な参加コンポーネントの他、パターンの実装をサポートする参加コンポーネントが追加される場合もあります。これらのサポート・コンポーネントが、使用するメカニズムの強度に影響を及ぼす可能性があります。
- 開始ユーザーおよび関連デバイス/ソフトウェア (リクエストを行っているアプリケーションとは異なる場合)
- 以下を目的とした外部セキュリティー・プロバイダー
- ファイアウォールおよびプロキシー
- ネットワーク・コンポーネント
- サービス・レジストリー (レジストリー内に、サービス定義と併せてセキュリティー・ポリシーまたはプロファイルが保持されている場合)
上記の参加コンポーネントは、必ずしも個別のコンポーネントであるとは限りません。そのため、シナリオの作成には、このような参加コンポーネントの 1 つ以上のロールで動作する製品 (つまりコンポーネント) を使用することもできます。例えば、アプリケーションがエンドツーエンドの対話の種類によってリクエスターのロールとプロバイダーのロールを使い分けたり、外部セキュリティー・サービスが上記の 1 つ以上の機能をサポートしたりする場合もあります。
セキュリティー機能を SOA トランザクションの参加コンポーネント全体に分散する場合には、全体的なセキュリティーのなかでそれぞれの役割を果たす参加コンポーネントが互いに信用していなければなりません。
参加コンポーネント間でセキュリティー機能を分散すると、参加コンポーネントごとに、参加コンポーネント間の信用に関する要件、およびコンポーネントの機能に関する要件が異なることになります。コンポーネントがセキュリティー・ロールを果たす方法については、各コンポーネントに選択肢があるため、それぞれのエンドツーエンドの経路は、機能全体のなかでの該当する機能部分に応じて決定する必要があります。
セキュリティー・パターン
信用モデルによく見られる主要なパターンには、以下のものがあります。
- エンドツーエンドの信用モデル
ESB は、エンド・ユーザーを認証して権限を付与するためにリクエストを行っているアプリケーションを信用し、サービス・プロバイダーは ESB を、認証されて権限を付与されたユーザーとみなします。エンド・ユーザーの ID は、セキュリティーを実施する上では使用されませんが、監査用のデータには組み込まれます。このセキュリティー・モデルの要件は、それぞれのコンポーネントが対話のなかで識別可能であることだけです。コンポーネントの識別はネットワーク・アーキテクチャー・レベルで行うことも、汎用アプリケーション ID を使用して行うこともできます。
このシナリオがよく使用されるのは、すべてのコンポーネントが、同じセキュリティー管理が適用される内部コンポーネントであり、信用されたコンピューター・ベースの一部となっている場合です。多くの場合、(認証および権限付与が明確に定義された) エンタープライズ CRM システムと、エンタープライズ・バックオフィス・システムとの統合はこのモデルに従います。
- ESB がアプリケーション ID にセキュリティーを適用するモデル
このモデルでは、ESB がリクエストを行っているアプリケーションを完全に信用することはなくなるため、リクエスターの ID を検証するためのクレデンシャルが必要になります。ESB は、リクエストを行ったユーザーにその権限が付与されているかどうかを確認してから、処理を行います。リクエストを行っているアプリケーションは信用されていないため、監査要件は ESB によって満たされることになります。
プロバイダー・サービスは引き続き ESB を信用できるユーザーとみなし、すべてのリクエストは ESB の ID または ESB の既知の信用できるサービスの ID で行われます。
エンドツーエンド・セキュリティー・モデルでは、すべてのプロバイダーが、信用できるすべてのリクエストを行っているアプリケーションにアクセス権を与えることを意味する場合があります。例えば、財務上の機密情報が含まれる特定のサービスへのアクセスを、信用できるアプリケーションからのリクエストのみに制限し、これらの信用できるアプリケーションには特権ユーザーのみがアクセスできるように、信用を分割する要件がある場合、このモデルでは ESB がその分割を行うことになります。
- ESB がエンド・ユーザー ID にセキュリティーを適用するモデル
このシナリオは、ESB が認証および権限付与を適用するという点では前述のシナリオと非常によく似ていますが、このシナリオで必要になるのはリクエストを行っているアプリケーションの ID ではなく、エンド・ユーザーの ID です。このモデルでは、プロバイダー・サービスは ESB を信用するものの、エンド・ユーザーの ID を必要とすることから、ESB がエンド・ユーザーの ID をアサートしなければなりません。ESB とプロバイダー・サービス間のリンクは、ネットワーク・アーキテクチャー、ESB クレデンシャル、または PKI による暗号化によってセキュアにすることができます。
このモデルが使用されるのは、プロバイダー・サービスがエンド・ユーザー ID のアサーションをセキュアに行う必要がある場合です。この場合に、プロバイダー内のビジネス・ロジックに基づく細分化された権限付与を行うためか、あるいはプロバイダー内で開始ユーザーに対する監査アクションをセキュアに行うことによって説明責任を確保するために使用します。
- リクエストを行っているアプリケーションによる認証を信用するモデル
このモデルでは、エンドツーエンドの信用と同じように、リクエストを行っているアプリケーションが既知の信用できるソフトウェアであることを前提とします。ただしこのモデルでは、アプリケーションが信用されるのは、認証を実行する場合と ESB に対してユーザー ID をアサートする場合のみに限られます。その後このアプリケーションは、ESB がアクセスを許可し、エンド・ユーザーの ID をプロバイダーに対してアサートします。このモデルでの ESB とプロバイダー・サービスとの相互の信用は、前述の ESB が認証を実行する場合と同じです。
このモデルでは、信用されたアプリケーションに対するユーザーのシングル・サインオンをサポートするため、これらのアプリケーションがユーザーに代わってサービス・リクエストを行うことができます。ID のアサーションは、ユーザー名トークンのみの単純なものにできますが、ユーザーに代わってリクエストを行っているアプリケーションがトークンを取得した後、そのトークンを ESB が検証する必要があります。
- エンドツーエンドの認証、機密性、および完全性が必要となるモデル
このモデルでは、ESB がプロバイダー・サービスによってのみ信用されるという前提なので、プロバイダーがリクエストの開始ユーザーを直接認証できるようにするためには、クレデンシャルが必要になります。このモデルでは、機密性と完全性も必要になる場合があります。
これは、ESB を全く信用しないというモデルではありません。ESB は、予想されるサービス・レベル・アグリーメントに従って適切なプロバイダーにリクエストを配信し、そのような機密サービスへのアクセス試行における最初のフィルターとして機能する上では、ほとんど完全に信用されます。ただし、開始ユーザーを識別する際には、デジタル署名などのエンドツーエンド・セキュリティーがさらに追加され、拒否不可能な形で使用されると同時に、オペレーション・スタッフが極めて機密性の高い情報にアクセスできないようにエンドツーエンドの暗号化が使用される場合もあります。このような暗号化をするのは、通常の処理を行っている場合や ESB で監査/ロギングが実行されている場合に例外が発生すると、こうした情報にアクセスできてしまう可能性があるからです。
- パブリッシュ/サブスクライブ・モデル
パブリッシュ/サブスクライブ・モデルでも主要な参加コンポーネントは同じですが、セキュリティー・モデルに関しては、以下の 2 つのセキュリティー・レベルがあるため異なります。
パブリッシュおよびサブスクライブ機能へのアクセス制御は、ESB に対するあらゆるリクエストへの制御と同じです。理論上、このモデルは一般的な SOA 対話に関して説明したメカニズムをどれでも使用することが可能で、これらの制御によって、ユーザー名をさらに細分化したアクセス制御に使用することができます。
トピックへのアクセス制御は通常、公開エンジンがトピック階層に関するアクセス制御リストを基準に管理します。
|
まとめ
この記事では、IBM Enterprise Service Bus 製品を使用して作成するエンタープライズ接続性ソリューションによくみられる一連のパターンを取り上げて説明しました。これらのパターンとその他の関連パターンについての詳細は、「参考文献」に記載した developerWorks Wikis に、具体的な実装情報と例と併せて記載されています。
謝辞
ここで紹介した概念は、多くの人々との何度にもわたる議論によって発展してきたものですが、特に初期段階でこの記事の草案についてフィードバックおよびアドバイスを提供してくださった Rob Phippen 氏、Kim Clark 氏、そして Greg Flurry 氏に感謝の言葉を贈ります。
参考文献 学ぶために
製品や技術を入手するために
- IBM 製品の評価版をダウンロードして、DB2®、Lotus®、Rational®、Tivoli®、および WebSphere® のアプリケーション開発ツールとミドルウェア製品を使ってみてください。
議論するために
著者について | | | Helen Wylie は、IBM WebSphere Messaging and ESB development チームで働くインテグレーション・アーキテクトです。これまで、顧客と協力して IBM WebSphere のインテグレーション製品をベースとした広範囲にわたるソリューションを手掛けてきました。パターン技術で彼女が現在重点を置いているのは、今までの経験を製品関連の担保および機能拡張に生かせるようにすることです。 |
| | | Peter Lambros は IBM Senior Technical Staff Member として、IBM WebSphere ファミリーの ESB 製品とメッセージング製品に共通するメディエーション技術の技術戦略およびアーキテクチャーを担当しています。彼が特に興味を寄せているのは、変換およびマッピング技術、パターン・ベースのエンジニアリング、そしてツールの全体的アーキテクチャーです。 |
記事の評価
| 
