Service Broker の動作内容

メッセージ交換

Service Broker は、メッセージの送受信を基本機能として設計されています。各メッセージは、メッセージ交換の一部を形成しています。それぞれのメッセージ交換は、信頼性の高い、永続的な通信チャネルです。各メッセージおよび各メッセージ交換には、Service Broker によって特定の型が適用され、開発者が信頼性の高いアプリケーションを記述するのに役立ちます。

新しい Transact-SQL ステートメントを使用すると、アプリケーションでは確実にメッセージの送受信を行うことができます。アプリケーションはメッセージをサービスに送信します。サービスは、互いに関連した一連のタスクの名前です。アプリケーションはメッセージをキューから受信します。キューは、内部テーブルのビューです。

同一タスク用のメッセージは、同一のメッセージ交換に属します。各メッセージ交換内では、Service Broker によって、アプリケーションは必ず送信された順序で一度だけ各メッセージを受信します。プログラムでサービスを実装する場合、同一サービス用の関連するメッセージ交換を関連付け、メッセージ交換グループにすることもできます。詳細については、「Service Broker の利点」を参照してください。

証明書に基づくセキュリティは、機密性の高いメッセージを保護し、サービスへのアクセスを制御するのに役立ちます。Service Broker と同じようなものに、郵便サービスを挙げることができます。離れた場所の同僚と意見交換する場合、郵便サービスを利用して手紙を送ることによって情報を伝達できます。郵便サービスでは、手紙を分類して配達します。双方とも、郵便受けから手紙を取り出して読み、返事を書き、新しい手紙を発送します。これが、意見交換が終わるまで続けられます。手紙は、双方が他の作業を行っている間、非同期的に配達されます。

Service Broker を使用するプログラムは、郵便の配達に似た方法で、他のプログラムとの非同期的なメッセージ交換を実現します。Service Broker メッセージは手紙のような働きをします。各 Service Broker サービスは、郵便局が手紙を配達する宛先の住所です。キューは、配達された手紙が入っている郵便受けです。アプリケーションはメッセージを受け取り、メッセージに対して反応し、返事を送ります。

アプリケーションが Service Broker サービスにメッセージを送信すると、メッセージ交換の相手側では、メッセージがアプリケーションの実装の詳細から切り離されます。受信側のアプリケーションは、送信側のアプリケーションに影響を与えることなく、動的に再構成したり新しいコードと置き換えたりできます。受信側のアプリケーションは一時的にシャットダウンすることもできます。これにより、受信側のアプリケーションが再起動するまで、Service Broker は新しいメッセージをキューに追加し続けます。

メッセージの順序付けと調整

Service Broker によるキューの処理は、一般的なデータベース プログラミング手法ですが、主に 2 つの点で従来の製品と異なります。

• Service Broker のキューは、データベースに統合されています。

• キューによって、関連したメッセージの調整と順序付けが行われます。

キューの統合により、通常のデータベース メンテナンスと管理に Service Broker も含まれることを意味します。通常、管理者は、Service Broker に関する日常的なメンテナンス作業は行いません。

Service Broker フレームワークは、メッセージ送受信用の単純な Transact-SQL インターフェイスを提供することに加え、メッセージの配信と処理を確実に行えるようにします。Service Broker によって、プログラムはメッセージ交換の各メッセージを、キューに入った順序ではなく送信された順序で一度だけ確実に受け取ることができます。従来のキューイング製品は、キューに入った順序でメッセージを渡します。そのため、メッセージの順序とグループ化についての判断は、アプリケーションで行う必要がありました。Service Broker では、2 つのキュー リーダーが、同一のメッセージ交換からのメッセージ、または関連したメッセージ交換の同一グループからのメッセージを同時に処理できないようになっています。

Service Broker の各メッセージ交換では 2 つの地点が関係します。メッセージ交換を開始する側は発信側と呼ばれ、メッセージを受信する側は発信先と呼ばれます。両者には、それぞれ発信側サービスと発信先サービスというサービスがあります。各サービスには、関連付けられたメッセージ キューがあります。

一般的なダイアログ メッセージ交換でのメッセージのやり取りを次に示します。

• 発信側で、次の処理が行われます。

  • プログラムがメッセージ交換を開始します。

  • プログラムが、タスクの実行に必要なデータを含むメッセージを作成します。

  • プログラムがメッセージを発信先サービスに送信します。

• 発信先で、次の処理が行われます。

  • メッセージが、発信先サービスに関連付けられたキューに配置されます。

  • プログラムがキューからメッセージを受信し、作業を実行します。

  • プログラムがメッセージを発信側サービスに送信して応答します。

• 発信側で、次の処理が行われます。

  • 応答メッセージが、発信側サービスに関連付けられたキューに配置されます。

  • プログラムが応答メッセージを受信して処理します。

発信先に送信する要求がなくなり、発信側がメッセージ交換を終了するまで、このサイクルが繰り返されます。

Service Broker では、各メッセージ交換において、1 (低) から 10 (高) までの優先度を設定できます。これにより、優先度の低い作業によって優先度の高い作業が妨げられることがなくなります。Service Broker システムは、さまざまなレベルのサービスを提供するように構成できます。詳細については、「メッセージ交換の優先度」を参照してください。

Service Broker は、メッセージング アプリケーションの記述に関連する最も難しいタスクを処理します。こうした難しいタスクには、メッセージ調整、信頼性の高いメッセージの配信、ロック、キュー リーダーの起動などがあります。これにより、データベース開発者はビジネス上の問題を解決する方法に専念できます。

トランザクションとしての非同期プログラミング

Service Broker インフラストラクチャでのアプリケーション間のメッセージ配信は、トランザクションとして行われ、非同期です。Service Broker メッセージングはトランザクションなので、トランザクションがロールバックされると、そのトランザクション内のすべての Service Broker 操作がロールバックされます。このような操作には、送受信操作も含まれます。非同期配信では、アプリケーションの実行が続行中であるときに、データベース エンジンが配信処理をします。スケーラビリティを高めるため、Service Broker には、キューを処理するプログラムを必要に応じて自動的に起動するメカニズムがあります。詳細については、「Service Broker のアクティブ化」を参照してください。

非同期プログラミングは、キューを使用するアプリケーションを記述する開発者に役立ちます。多くのデータベース アプリケーションには、リソースが許可したときに実行される作業のキューとして機能するテーブルが含まれます。キューにより、データベース アプリケーションでは 2 つの利点が得られます。

• アプリケーションは、作業要求をキューに配置するとすぐに、対話中のユーザーに応答できます。アプリケーションは、要求に関連付けられたすべての作業が完了するまで待ってから応答する必要はありません。キューに置かれている要求は、リソースが利用可能な場合に処理されます。これにより、データベースが対話中のユーザーに迅速に応答できるほか、利用可能なリソースを効率的に使用できるようになります。

• 1 つの要求に関連する作業を、個別のトランザクションとして処理される複数の作業単位に分割できる場合もあります。この場合、データベース アプリケーションは、キューに要求を配置することによって、各作業単位を開始できます。Service Broker ではこれをさらに進めて、アプリケーションが、各コンピュータ上の複数の Service Broker インスタンスに作業を分散できるようにします。

ほとんどの場合、キュー内のアイテムに正しく順序を付けて処理するようにアプリケーションをコーディングすることは複雑です。開発者は、データベース エンジンに組み込まれた Service Broker 機能を使用して、データベース キューを正しく実装するのに必要なコーディングを簡略化することができます。

疎結合アプリケーションのサポート

Service Broker では、疎結合アプリケーションがサポートされています。疎結合アプリケーションは、メッセージの送受信を互いに独立して行う、複数のプログラムで構成されます。このようなアプリケーションは、交換されるメッセージに対して同じ定義を共有し、サービス間の対話に関する全体的な構造を共有する必要があります。ただし、アプリケーションを同時に実行したり、同一の SQL Server インスタンス内で実行したり、アプリケーションで実装の詳細を共有したりする必要はありません。アプリケーションは、メッセージ交換の相手方に関して、物理的な場所や実装を認識する必要がありません。

Service Broker のコンポーネント

Service Broker には、次の 3 種類のコンポーネントがあります。

• **メッセージ交換コンポーネント。**メッセージ交換グループ、メッセージ交換、およびメッセージで、Service Broker アプリケーションの実行時構造が形成されます。アプリケーションは、メッセージ交換の一部としてメッセージを交換します。各メッセージ交換は、1 つのメッセージ交換グループに属しています。また、メッセージ交換グループには、複数のメッセージ交換を含めることができます。それぞれの Service Broker メッセージ交換はダイアログです。ダイアログとは、参加する二者間で行われるメッセージ交換のことです。メッセージ交換コンポーネントの詳細については、「メッセージ交換のアーキテクチャ」を参照してください。

• **サービス定義コンポーネント。**これらは、アプリケーションで使用するメッセージ交換の基本構造を指定する、デザイン時コンポーネントです。アプリケーションにおける、メッセージ型、メッセージ交換フロー、およびデータベース ストレージを定義します。サービス定義コンポーネントの詳細については、「サービスのアーキテクチャ」を参照してください。

• **ネットワーク コンポーネントとセキュリティ コンポーネント。**これらのコンポーネントでは、データベース エンジンのインスタンス間でメッセージの交換に使用されるインフラストラクチャを定義します。データベース管理者が、変化する環境を管理できるように、Service Broker では、アプリケーション コードに依存しない形でこれらのコンポーネントの構成を管理者が行うことができます。ネットワーク コンポーネントとセキュリティ コンポーネントの詳細については、「ネットワークとリモート セキュリティ」を参照してください。

サービス定義コンポーネント、ネットワーク コンポーネント、およびセキュリティ コンポーネントは、データベースと SQL Server インスタンスのメタデータの一部です。メッセージ交換グループ、メッセージ交換、およびメッセージは、データベースに含まれるデータの一部です。

関連項目

概念

その他の技術情報