Service Broker キューの作成
サービスに着信するメッセージはキューに保存されます。処理を簡素化するため、一般的にはアプリケーションで複数のサービスに同一のキューを使用するのではなく、サービスごとに 1 つのキューが作成されます。
キューの保有オプションを設定すると、メッセージは処理後も保有されます。保有オプションを設定するとアプリケーションのパフォーマンスが低下するので、送受信した実際のメッセージに永続的にアクセスする必要がある場合に限り、このオプションを指定してください。メッセージの保有の詳細については、「メッセージの保有」を参照してください。
内部アクティブ化を使用しないアプリケーションは、キューの定義でアクティブ化句を指定しないでください。
内部アクティブ化を使用するアプリケーションは、ストアド プロシージャ名、起動される SQL Server のキュー リーダーの最大数、およびストアド プロシージャ起動前に権限を借用するデータベース プリンシパルの名前をキューの定義に指定します。
キューの名前はメッセージのネットワーク形式では指定しません。キューは、スキーマが所有するオブジェクトです。したがって、キュー名は SQL Server の名前付け規則に従います。名前付けの詳細については、「Service Broker オブジェクトの名前付け」を参照してください。
ストアド プロシージャのアクティブ化
キューはストアド プロシージャと関連付けることができます。キューに処理するメッセージがある場合、SQL Server によってストアド プロシージャがアクティブ化されます。この自動アクティブ化処理により、Service Broker アプリケーションが、現在の処理負荷に応じて動的にスケールを変更できます。Service Broker によりアクティブ化されたストアド プロシージャは、それぞれが個別のスレッドで実行されます。キューでストアド プロシージャを指定している場合、キューで指定されているインスタンスの最大数になるまで、Service Broker により必要に応じてストアド プロシージャの新しいインスタンスが起動されます。
一般的に、アクティブなストアド プロシージャはメッセージを 1 つ以上処理し、メッセージ送信元のサービスに応答を返します。ストアド プロシージャでメッセージを処理するよりも早くメッセージが着信した場合、キューで定義されている最大数に達するまで、Service Broker によりストアド プロシージャの新しいインスタンスが起動されます。一般的に、アクティブなストアド プロシージャは、利用できるメッセージがしばらくキューに存在しないと判断した時点で終了します。
Service Broker アプリケーションを設計する場合は、アクティブなストアド プロシージャを使用するのが一般的です。ただし、アプリケーションによっては、他の設計方針を採用した方が要件に適していることがあります。SQL Server で Transact-SQL バッチを実行できるアプリケーションはメッセージを送受信できます。メッセージの処理は、ストアド プロシージャが SQL Server によりアクティブ化されたか、SQL Server エージェントにより起動されたか、外部アプリケーションから実行しているか、SQL Server Management Studio や SQL Server ExpressManagement Studio などのツールから対話的に実行しているかを問わず、どのストアド プロシージャでも可能です。