このトピックでは、Windows Communication Foundation (WCF) でのキュー通信の推奨プラクティスについて説明します。 以降のセクションでは、シナリオの観点から推奨されるプラクティスについて説明します。
高速で Best-Effort キューに入ったメッセージング
キューに置かれたメッセージングが提供する分離と、ベスト エフォート保証を備えた高速で高パフォーマンスのメッセージングを必要とするシナリオでは、非トランザクション キューを使用し、 ExactlyOnce プロパティを falseに設定します。
さらに、 Durable プロパティを false に設定することで、ディスク書き込みのコストを発生さないことを選択できます。
セキュリティはパフォーマンスに影響します。 詳細については、「パフォーマンスに 関する考慮事項」を参照してください。
信頼性の高いエンド ツー エンドキュー メッセージング
以降のセクションでは、エンドツーエンドの信頼性の高いメッセージングを必要とするシナリオに推奨されるプラクティスについて説明します。
基本的な信頼性の高い転送
エンドツーエンドの信頼性を確保するには、 ExactlyOnce プロパティを true に設定して転送を保証します。
Durableプロパティは、要件に応じてtrueまたはfalseに設定できます (既定値はtrue)。 一般に、 Durable プロパティはエンド ツー エンドの信頼性の一部として true に設定されます。 この侵害はパフォーマンス コストですが、キュー マネージャーがクラッシュしてもメッセージが失われないように、メッセージは永続的になります。
トランザクションの使用
エンドツーエンドの信頼性を確保するには、トランザクションを使用する必要があります。
ExactlyOnce は、メッセージがターゲット キューに配信されることを保証するだけです。 メッセージを確実に受信するには、トランザクションを使用します。 トランザクションがない場合、サービスがクラッシュすると、配信中のメッセージは失われますが、実際にはアプリケーションに配信されます。
配信不能キューの使用
配信不能キューを使用すると、メッセージがターゲット キューに配信されない場合に通知されます。 システム提供の配信不能キューまたはカスタム配信不能キューを使用できます。 一般に、カスタム配信不能キューを使用すると、1 つのアプリケーションから 1 つの配信不能キューに配信不能メッセージを送信できるため、最適です。 それ以外の場合、システム上で実行されているすべてのアプリケーションに対して発生するすべての配信不能メッセージは、1 つのキューに配信されます。 その後、各アプリケーションは配信不能キューを検索して、そのアプリケーションに関連する配信不能メッセージを見つける必要があります。 MSMQ 3.0 を使用する場合など、カスタム配信不能キューを使用できない場合があります。
エンドツーエンドの信頼性の高い通信のために配信不能キューをオフにすることはお勧めしません。
詳細については、「 Dead-Letter キューを使用したメッセージ転送エラーの処理」を参照してください。
Poison-Message 処理の使用
有害メッセージ処理では、メッセージの処理失敗から回復する機能が提供されます。
有害メッセージ処理機能を使用する場合は、 ReceiveErrorHandling プロパティが適切な値に設定されていることを確認します。 Dropに設定すると、データが失われることを意味します。 一方、 Fault に設定すると、有害メッセージが検出されたときにサービス ホストにエラーが発生します。 MSMQ 3.0 を使用すると、 Fault はデータ損失を回避し、有害メッセージを移動する最適なオプションです。 MSMQ 4.0 を使用する場合は、 Move を使用することをお勧めします。 Move は、サービスが新しいメッセージの処理を続行できるように、有害なメッセージをキューから移動します。 その後、有害メッセージ サービスは有害メッセージを個別に処理できます。
詳細については、「 有害メッセージ処理」を参照してください。
高スループットの実現
単一のエンドポイントで高スループットを実現するには、次のコマンドを使用します。
トランザクション バッチ処理。 トランザクション バッチ処理により、1 つのトランザクションで多数のメッセージを読み取ることができます。 これにより、トランザクションのコミットが最適化され、全体的なパフォーマンスが向上します。 バッチ処理のコストは、バッチ内の 1 つのメッセージでエラーが発生した場合、バッチ全体がロールバックされ、再びバッチ処理できるまでメッセージを一度に 1 つずつ処理する必要があるということです。 ほとんどの場合、有害メッセージはまれであるため、バッチ処理は、特にトランザクションに参加する他のリソース マネージャーがいる場合に、システムのパフォーマンスを向上させる推奨される方法です。 詳細については、「 トランザクションでのメッセージのバッチ処理」を参照してください。
コンカレンシー。 コンカレンシーによってスループットが向上しますが、コンカレンシーは共有リソースの競合にも影響します。 詳細については、「 コンカレンシー」を参照してください。
調整。 最適なパフォーマンスを得られるように、ディスパッチャー パイプライン内のメッセージの数を調整します。 これを行う方法の例については、「 調整」を参照してください。
バッチ処理を使用する場合、コンカレンシーと調整は同時実行バッチに変換されます。
スループットと可用性を高めるには、キューから読み取る WCF サービスのファームを使用します。 この場合、これらのサービスはすべて同じエンドポイントで同じコントラクトを公開する必要があります。 ファームアプローチは、多数のサービスが同じキューからすべての読み取りを可能にするため、メッセージの実稼働率が高いアプリケーションに最適です。
ファームを使用する場合、MSMQ 3.0 ではリモートトランザクション読み取りがサポートされていないことに注意してください。 MSMQ 4.0 では、リモートトランザクション読み取りがサポートされています。
詳細については、「 トランザクションでのメッセージのバッチ処理」を参照してください。
作業単位セマンティクスを使用したキュー
一部のシナリオでは、キュー内のメッセージのグループが関連している可能性があるため、これらのメッセージの順序は重要です。 このようなシナリオでは、関連するメッセージのグループを 1 つの単位として処理します。すべてのメッセージが正常に処理されるか、何も処理されません。 このような動作を実装するには、キューでセッションを使用します。
詳細については、「 セッション内のキューに入ったメッセージのグループ化」を参照してください。
Request-Reply メッセージの関連付け
通常、キューは一方向ですが、一部のシナリオでは、受信した応答を先ほど送信した要求に関連付けることができます。 このような相関関係が必要な場合は、メッセージとの相関関係情報を含む独自の SOAP メッセージ ヘッダーを適用することをお勧めします。 通常、送信者はこのヘッダーをメッセージに添付し、受信者はメッセージを処理し、応答キューに新しいメッセージを返信する際に、関連付け情報を含む送信者のメッセージ ヘッダーを添付して、送信者が要求メッセージで応答メッセージを識別できるようにします。
WCF 以外のアプリケーションとの統合
WCF サービスまたはクライアントを WCF 以外のサービスまたはクライアントと統合する場合は、 MsmqIntegrationBinding を使用します。 WCF 以外のアプリケーションには、System.Messaging、COM+、Visual Basic、または C++ を使用して記述された MSMQ アプリケーションを指定できます。
MsmqIntegrationBindingを使用する場合は、次の点に注意してください。
WCF メッセージ本文は、MSMQ メッセージ本文と同じではありません。 キューに登録されたバインディングを使用して WCF メッセージを送信する場合、WCF メッセージ本文は MSMQ メッセージ内に配置されます。 MSMQ インフラストラクチャは、この追加情報に気がつきます。MSMQ メッセージのみが表示されます。
MsmqIntegrationBindingでは、一般的なシリアル化の種類がサポートされています。 シリアル化の型に基づいて、ジェネリック メッセージの本文の型 ( MsmqMessage<T>) は、さまざまな型パラメーターを受け取ります。 たとえば、 ByteArray にはMsmqMessage\<byte[]>が必要であり、 Stream にはMsmqMessage<Stream>が必要です。XML シリアル化では、<behavior> 要素の
KnownTypes属性を使用して既知の型を指定できます。この属性を使用して、XML メッセージを逆シリアル化する方法を決定できます。