メッセージング

アプリケーションアーキテクチャ: 概念的ビュー

Maarten Mullender and Mike Burner
Microsoft Corporation

July 2002
日本語版最終更新日 2002 年 12 月 3 日

「サービス」で解説しているように、サービスはメッセージを交換することによって対話を行います。このドキュメントで示すサービスモデルでは、サービスは純粋にそれが受け取り、生成するメッセージによって定義されます。これには、これらのメッセージの順序付けの要件も含まれます。サービス間でのメッセージのルーティングは複雑なプロセスであり、組織が公開している複数のサービス間で共有されるメッセージングインフラストラクチャに処理させるのが一番です。

このトピックでは、これらの概念をさらに詳しく説明し、サービスベースアーキテクチャにおけるメッセージとメッセージ受け渡しの役割の概念的ビューを提供します。

メッセージ

メッセージとは、1 つのサービスから別のサービスに送信される情報の単位です。メッセージを解析し、理解できるようにするためには、メッセージに高度な構造が備わっている必要があります。この構造をサービスとソリューション開発者の間で伝達する目的には、スキーマ、すなわちメッセージの要素を抽象的に記述するドキュメントが使用されます。

メッセージスキーマに含まれる主な情報には、要素名、データ型 ("integer" など)、値制約 (確率を表現するために使用される整数は 0～100 の範囲でなくてはならない、など)、およびその要素が必須であるかどうかなどがあります。高度なスキーマ定義言語では、単純型から複合型を作成することができます。

「サービス」で述べたように、サービスは相互運用性を実現するために、プラットフォームに依存しない型システムを必要とします。このようなシステムは、"integer" や "float" などの型のビット長を明確に定義し、ターゲットプラットフォーム上でインプリメントするのが難しいコンストラクトを使うのを避け、一般にワイヤ形式のデータ要素からシステム固有のデータ要素への変換を支援しなくてはなりません。

型システムの選択は、ソフトウェアアーキテクトがサービスメッセージを設計する際に相互運用性を考慮に入れるべき分野の 1 つに過ぎません。メッセージはサービスの設計プロセスの中心に位置します。メッセージは、外の世界から見たサービスの顔なのです。不適切に設計されたメッセージは、いつかは修正しなくてはならず、すべてのサービスコンシューマが新しいインターフェイスへと移行しなくてはならないため高いリエンジニアリングコストがかかります。

メッセージの設計には、サービスの機能要件と運用要件をサポートする機能要素と運用要素の両方の定義が含まれます。運用要素は、機能要素を理解していないメッセージングインフラストラクチャによって操作されることがあるので、設計者はトランスポートプロトコルの機能を使って、機能要素の「本体」の外にある運用要素を探すようにするべきです。

相互運用性のあるメッセージの設計のもう 1 つの原理は、「ヘッダー」と「本体」の両方のスキーマに含まれている既存の要素定義を有効に活用するということです。サービスに格納される電話番号を有効に活用できるようにするためには、広く普及した要素定義を使ってモデル化する必要があります。これにより設計の手間が軽減され、このような広く理解されている要素を、それらを使用する他のサービスに情報を失うことなくコピーできるようになります。

概念上、メッセージは自己完結的でなくてはならず、そのメッセージを理解するために必要なすべての情報を含むか、参照していなくてはなりません。現実には、このメッセージ状態の一部は暗黙のうちに諒解されます。たとえば、Hypertext Transfer Protocol (HTTP) を使用している場合、サービスからの応答は、同じ接続上で送信された要求に対する応答として解釈されます。

メッセージルーティング

メッセージ配信の最も広く使われている形式は、要求/応答です。送信者は受信側ポートへの接続をオープンし、メッセージをポストし、受信確認を (ときには要求メッセージの処理の結果として生成された応答の本体とともに) 受け取ります。

外からはこう見えるとしても、現実のプロセスは一般にもっと複雑です。メッセージは一般にキャッシュ、フィルタリングファイヤウォール、およびクレデンシャル管理システムなどの仲介者を通してルーティングされます。これらの仲介者は、部分的な、または全体の処理のためにメッセージをインターセプトしていると考えることができます。仲介者は、認可仲介者がアクセス要求を拒否した場合などのように、例外を生成することができます。その場合には、送信者にエラーが返されます。

インターセプションは、メッセージ処理インフラストラクチャの概念上の基盤となります。これにより、複雑なパス上でメッセージをルーティングし、特殊化した共有サービスをメッセージ処理に関与させることができます。

インターセプションの一般的な用途の 1 つは、図 1 に示すように、異なるメッセージ形式を使用しているサービス間での要求の変換です。このパターンは、独自プロトコルを使用しているシステムの前面に標準準拠のインターフェイスを提供する目的や、サービスコントラクトの古いバージョンに準拠しているメッセージを変換する目的に使用することができます。

図 1. 他のサービスに対するアダプタとしてのサービス

要求は、メッセージの何らかの要素や属性に基づいて、他のサービスポートにリダイレクトすることもできます。このようなコンテンツベースのルーティングには、状態の分割 (日付別に分類されるニュースアーカイブなど) やネットワークトポロジの最適化 (要求を数ホップ先のポートではなくローカルサービスポートにルーティングする) などがあります。

非同期メッセージングを考慮に入れて設計を行うことの意味については、「サービス」で簡単に説明しました。要求への応答を短時間で受け取ることがどうしても必要な場合 (忍耐力のないユーザーからの Web ページ要求など) を除き、サービスはペアとなったポートを使って非同期的に対話を行うべきです。要求側のサービスは、メッセージヘッダーの中で、応答のポスト先のポート識別子を提供します。これにより、要求側は自らをメッセージ処理チェーンの末端に置き、仲介者と、要求に関わる基本的なビジネスロジックをインプリメントしているサービスによって作成された応答のコンシューマとなることになります。

メッセージ交換のスタイル

上のセクションでは、メッセージ交換のいくつかのモデルについて簡単に触れました。どのような交換のスタイルが適しているかは、サービスの種類によって異なります。以下に、いくつかのスタイルとその使用方法の例を示します。

ファイヤアンドフォゲット。このスタイルでは、応答を期待することなく (または受信する意志なく) 1 つのメッセージが送信されます。これは一般に、気温などのステータス更新をポストするために使用されます。
モノローグ。このスタイルでは、メッセージのストリームがサービスポートにプッシュされ、応答は返されません。モノローグは一般にオーディオ/ビジュアルコンテンツに使用され、コンテンツを複数の受信者にプッシュするためにマルチキャスティングやブロードキャスティングが使われることが少なくありません。
要求/応答。クライアントが情報に対する要求への即時の応答を期待するおなじみのスタイルです。Web 上の HTTP が採用しており、広く使われています。
ダイアログ。合意されたプロトコルに基づく、複数の互いに依存した交換による 2 点間接続です。Simple Mail Transfer Protocol (SMTP) はこのスタイルを採用しています。
カンバセーション。上記のどのスタイルも「カンバセーション」の一種と考えることができますが、ここでの「カンバセーション」は、複数のサービスが関与する柔軟性のある交換を指しています。カンバセーションのスタイルでは、実世界のビジネス機能をサポートするために必要な複雑な交換を行うことができます。

このリストは、用語を確立することを目的としているのではなく、サービスアーキテクトがアプリケーション要件に適した交換スタイルを選択する必要があるという事実を示すことを目的としています。

これらのスタイルは、1 つのサービスオファリングの中で混在させることができます。例としては、ニュースフィードを要求するニュース「ティッカー」アプリケーションのような、モノローグを開始する要求/応答交換が考えられます。ティッカーは、ストリームを受け付けるポートの識別子を含んだ要求をポストします。ニュースフィードは要求を検証し、要求に現在のサブスクライバのクレデンシャルが含まれていれば、肯定的な応答を返します。ニュースフィードはティッカーのポートをマルチキャストリストに追加し、ティッカーはメッセージの受信を開始します。

長期的に実行される非同期カンバセーションでは、メッセージ処理にいくつかの複雑な側面が生じます。第 1 に、処理に関わるサービスの一部、特にプロセスの開始者は、カンバセーションに関する何らかの状態を保持する必要があります。たとえば、サプライマネジメントサービスが、技術者のために購買要求をトリガするケースを考えてみましょう。その技術者に進捗状況を (さらには処理が進行していることを) 通知するためには、カンバセーションを一意に識別するために、交換されるすべてのメッセージに何らかのトークンが含まれていなくてはなりません。第 2 に、カンバセーションの中では、メッセージごとにセキュリティコンテキストが確立される必要があります。クレデンシャルをキャッシングするためのセッションコンテキストは利用できないためです。

メッセージングの要件

Web ページに対する要求とは異なり、ハイバリューのビジネスプロセスをインプリメントするサービスは、一般に応答の速度よりも配信メカニズムの堅牢さを重視します。このセクションでは、サービスベースアプリケーションアーキテクチャを、ビジネスアプリケーションのための信頼できるプラットフォームにするために必要ないくつかの運用要件を簡単に紹介します。

信頼できるメッセージング

同期的なメッセージ配信は、完全な信頼性を持たせることはできません。ネットワーキング上の問題やシステム障害のために、相手側のポートが利用不可能になることがあります。ネットワークの遅延が、要求に予期しないレイテンシをもたらすことがあります。ストリーミングされたメッセージは、ルーティングの性質のために、違った順序で到着することがあります。

トランスポートの信頼性の欠如に対する一般的な解決方法は、要求をキューに入れ、最初の配信の試みが失敗した場合には再送信を行うというものです。しかし、この方法ではさらに別の問題が生じます。同じメッセージが何度も受信されて、望ましくない結果が生じる可能性があるのです (オーダーの重複など)。メッセージの受け渡しにおける基本原理は、メッセージの等羃性を保つこと、つまり同じメッセージを複数受信した場合でも、1 つ受信したときと同じ効果が生じるように保証することです。

信頼できるメッセージングインフラストラクチャの目標は、メッセージがちょうど 1 回だけ、正しい順序で配信されることを保証し、これをポリシーによって決定された時間内に達成できない場合にはフォールバックとして例外を生成することです。

すべてのアプリケーションが信頼できるメッセージングを必要とするわけではありません。たとえば、ストリーミングオーディオは、「遅れて」(つまり後の方のメッセージよりも後に) 到着したメッセージを削除することも含めて、メッセージがある程度失われても許容範囲内で動作することができます。しかし、このようなケースであっても、アプリケーションは間違った順序で届いたメッセージのコンテンツを「再生」してしまわないように、メッセージの順序を意識している必要があります。

信頼できるメッセージングのサポートの大部分は、アプリケーションごとに新規に作成するのではなく、インフラストラクチャサービスに含まれています。しかし、副作用が特に重大な場合には、メッセージの等羃性を保つためにサービスが特殊な対処を行わなくてはならないことがあります。

ルーティング

実世界のシナリオをインプリメントするためには、複雑なメッセージルーティングが必要となります。メッセージは、信頼できるメッセージングの提供、セキュリティクレデンシャルのチェック、メッセージトラフィックの独立した監査証跡の保持といった処理を行うサービスを通してルーティングしなくてはならないことがあります。

多様なサービスが、個々のメッセージのルーティング上のニーズを理解できるようにするためには、標準化が必要です。メッセージのヘッダーは、サービス A に対し、A が処理に成功したら、そのメッセージをサービス B に送信するよう指示できなくてはなりません。チェーンの中のすべてのサービスが、何か問題が生じたときの例外のルーティング方法を理解している必要があります。

複数の互換性のないルーティングプロトコル仕様が使用されていると、相互運用が不可能なサービスがいくつも孤立することになります。サービスアーキテクトは、最低限のアプリケーション要件を満たす、最も広くインプリメントされている仕様を選択するべきです。

セキュリティ管理

セキュリティは、ビジネスプロセスを組織外の当事者からアクセス可能なネットワークに移動するときの主な問題点となります。メッセージはデータの窃盗と改ざんから守られなくてはなりません。ユーザーとシステムは、信頼の置ける形で認証される必要があります。サービスは侵入やサービス拒否攻撃に対する防御を強化する必要があります。

ネットワークセキュリティは、複数の特化したソリューションの組み合わせを必要とする、さまざまな側面を持った問題です。一部のセキュリティは共有サービスやルーティングおよびフィルタリングインフラストラクチャとしてインプリメントするのに適していますが、サービスそのものの中で対処すべき要素もあります。

ソフトウェアアーキテクトにとっての注意事項には、以下のものが含まれます。

コンパイラと実行時環境の選択。範囲外のメモリアクセスを使って外部コードを実行できるようになっていると、サービスのセキュリティが危うくなります。現代的な開発ツールと実行環境は、この種の攻撃に対する保護を提供しています。
ロギングとログ解析。サービスは、通常のアクセスパターンと異常なアクセスパターンを理解できるようにモデル化されるべきです。システムは運用スタッフに対して、疑わしい活動を警告できるように開発されなくてはなりません。サービスアクセスモデルは、運用上の経験から組織の持つ知識が充実するにつれて進化していきます。
データの暗号化。機密性のあるデータを、不法な当事者 (メッセージの他の部分に関する操作を行う権限を持っている仲介者サービスを含む) によるアクセスから保護するためのメカニズムが必要です。これは、メッセージの特定の部分を、目的の当事者のみが復号できるような方法で暗号化することによって実現できます。
メッセージの整合性。セキュアチェックサムを使って、メッセージが転送中に変更されなかったことを示すことができます。これはメッセージの個々の部分とメッセージ全体に適用できます。仲介者がメッセージにヘッダー要素を追加しなくてはならないことがあるため、メッセージ全体のチェックサムは各ホップで再計算する必要があります。これは、整合性のチェックに標準ベースのアプローチを使用するべき強力な理由となります。
認証と認可。リモートユーザーとサービスの識別は、大きな問題となります。ユーザーは運用者にとっての悪夢です。パートナー組織内での役割が変わると、サービスへのアクセス権も影響を受けます。複数のプロバイダからサービスにアクセスしているユーザーは、プロバイダごとに独自のクレデンシャルを管理したくはないでしょう。この問題に対する解決策は、認証と権利の管理を安全な形で各パートナーに委譲し、パートナー組織内からの不適切なアクセスの責任を各パートナーに負わせることを明示的に記したサービス契約を結ぶことです。これにはかなり高度なイノベーションと開発が必要となり、コーディングにはある程度の時間がかかります。

ロギングと監査

組織の情報管理と、上で述べたセキュリティ上の懸念の両方の点から、組織はサービスがどのように使用されているかを理解しておく必要があります。共有ロギング機能から共有解析エンジンへとデータをフィードし、組織がサービスのモデル化、キャパシティの計画、および発生した問題のトラブルシューティングに利用できるようにするべきです。

一部のサービスは、サービスコンシューマとサービスプロバイダの両方の外部にある独立エージェントによって提供される監査可能なロギングを必要とすることがあります。このようなサービスは、政府規制を満たすため、またはパートナー組織間でどのようなメッセージがいつ処理されたのかということに関する紛争を解決するために必要となります。

キャッシュ管理

いくつかの種類のサービスは、キャッシングが可能な結果を生成します。これには、特定の日付における株価の終値のような静的な情報や、一定の期間は操作が可能であった方がよいが、実際のアクションを実行する前に検証を行うべきデータ (飛行機の空席情報など) が含まれます。

Web キャッシュはキーとして Uniform Resource Locator (URL) を使用し、複雑なクエリの結果のキャッシングを試みることはめったにありません。サービスはこのような簡単なアプローチは提供していないので、サービス要求のためのキーを導出し、サービスが仲介者とコンシューマに対して、応答に含まれるデータのキャッシング可能性についての情報を伝達できるようにするための標準を開発する必要があります。

第 6 章「状態」は、サービスがキャッシング可能なデータとそうでないデータをどのように使用するかをさらに詳しく解説しています。

メッセージ処理インフラストラクチャ

これまでに説明してきた堅牢なメッセージングのための運用要件の多くは、メッセージ処理インフラストラクチャとしてインプリメントされるべきです。このインフラストラクチャは、概念上は以下のものを含みます。

共通コンポーネント。組織は、サービスをインプリメントしているすべてのシステム上で使用されるリスニングおよびメッセージ処理ソフトウェアのための標準を設定するべきです。
組織のインフラストラクチャ。ルーター、ファイヤウォール、および共有サービスは、セキュリティ、ロギング、およびコンテンツベースルーティングの要件を満たす上で重要な役割を果たします。
パートナーのインフラストラクチャ。同じように、サービスを使用する組織のネットワークおよびサービスインフラストラクチャは、サービス配信のセキュリティと信頼性に大きな影響を与えます。
パブリックインフラストラクチャ。メッセージは、使用側の組織と提供側の組織のネットワークの末端にあるルーターの間で、長い距離を移動することがあります。これには、ビットの単純な転送だけでなく、組織が監査、アイデンティティの確認、アクセラレーション、またはその他の機能のために使用することを選択した仲介者が含まれます。

図 2 は、メッセージ処理インフラストラクチャを示しています。

図 2. メッセージ処理インフラストラクチャ

すべてのメッセージが通るメッセージ処理インフラストラクチャは、運用機能を管理するための理想的な場所となります。これにより、コアのビジネス機能、すなわちサービスが提供するビジネスプロセスを、運用機能、すなわちサービスが他のサービスと通信を行う方法から分離することができます。また、これらの機能を分離することで、組織内の適切な専門家グループに責任を分散することが可能となります。

サービスの設計は、それが使用するトランスポートからは独立に行うことになりますが、ネットワークトランスポートが関与していることを意識する必要はあります。ビジネスロジックは分散および非同期処理の複雑な側面を考慮に入れなくてはなりません。

メッセージングの要約

メッセージはネットワークサービスの設計の中心点です。サービスベースアーキテクチャは、操作の対象となる状態の転送形式に焦点を当てることで、統合性と相互運用性を考慮に入れた設計を促します。メッセージングの水平的な問題に対する標準ソリューションは、相互運用性のあるサービスという目標の達成に大きく貢献します。

メッセージは、コンシューマから仲介者を通してサービスプロバイダに到着するまで、複雑な経路をたどります。その後の応答は、これとは異なる、しかし同じように複雑な経路を通らなくてはなりません。サービスとサービス消費アプリケーションは、このような複雑さを考慮に入れて開発されなくてはなりません。サービス呼び出しを同期的な関数呼び出しとして扱うと、脆弱なアプリケーションが作られてしまいます。

サービスとサービス消費アプリケーションの作成に関わる複雑な問題のほとんどは、アプリケーション要件と組織のポリシーが許容する範囲内で共有されるメッセージ処理インフラストラクチャによって対処されるべきです。このインフラストラクチャは、コンピュータ業界における今後数年の重要なイノベーションと開発の分野となるでしょう。

注

HTTP の Keep-Alive を使用すると、1 つの接続で複数の対話を行うことができますが、そのスタイルは依然として要求/応答型です。

アプリケーション アーキテクチャ: 概念的ビュー

目次