バックエンド処理のためにキューに入れられる「作業項目」を生成するシステムを構築しています。私は最近、同じ要件を持つシステムを完成させ、最適とは思えないアーキテクチャを思いついたので、この新しいシステムについてのアドバイスを期待していました。
作業項目は一元的にキューに入れられ、基本的にFIFOの順序で処理する必要があります。これが唯一の要件である場合、私はおそらくMSMQまたはSQLServerサービスブローカーソリューションを好むでしょう。ただし、実際には、変更されたFIFO順序で作業項目を選択する必要があります。作業項目にはいくつかの属性があり、属性値の特定の組み合わせが存在する場合は、FIFO順に割り当てる必要があります。
例として、作業項目には、Office、Priority、Group Number、およびSequence Number（グループ内）の属性があります。複数のアイテムが同じグループ番号でキューに入れられる場合、それらはシーケンス番号の順序でキューに入れられることが保証され、同じ優先順位を持ちます。
特定のサービスの特定の構成パラメーターを指定して、変更されたFIFO順序で作業時間をプルするいくつかのバックエンドプロセス（現在はWindowsサービスとして実装されています）があります。ワシントンDCを実行しているサービスは、DCの作業項目のみを処理するように構成されていますが、NYのサービスは、NYとDCの両方の項目を処理するように構成されている場合があります（主に全体的なスループットを向上させるため）。このタイプの選択性に加えて、優先度の高いアイテムを最初に処理し、同じ「グループ番号」を含むアイテムをシーケンス番号の順序で処理する必要があります。したがって、NYサービスがシーケンス1のグループ100のDCアイテムを処理している場合、シーケンス1はまだ完了していないため、DCサービスがグループ100のシーケンス2のDCアイテムをプルオフすることは望ましくありません。他のグループのアイテムは、引き続き処理の対象となる必要があります。
最後のシステムでは、SQLテーブルを使用してキューを実装しました。アイテムを送信し、さらに重要なことに、アイテムの処理を担当するWindowsサービスにアイテムを「割り当てる」ためのストアドプロシージャを作成しました。割り当てストアドプロシージャには、上記で説明した選択ロジックが含まれています。各Windowsサービスは、割り当てストアドプロシージャを呼び出し、サービスのそのインスタンス（適格なオフィスなど）に固有のパラメーターを渡します。この割り当てストアドプロシージャは、割り当てられた（処理中の）ワークアイテムにスタンプを付け、作業が完了すると、最後のストアドプロシージャが呼び出され、アイテムが「キュー」（テーブル）から削除されます。
このソリューションには、単純なSQLselectステートメントでこれらの「キュー」の状態をすばやく調べることができるという点でいくつかの利点があります。キューを簡単に操作することもできます（たとえば、単純なSQL更新ステートメントで優先順位を上げることができます）。ただし、欠点として、これらのキューテーブルのデッドロックに対処しなければならず、これらのストアドプロシージャを作成する必要があります（しばらくすると面倒になります）。
どういうわけか、MSMQ（WCSの有無にかかわらず）またはServiceBrokerのいずれかがより洗練されたソリューションを提供できるはずだと思います。自分のキューイング/作業項目処理システムをローリングするのは、気分が悪いだけです。しかし、私が知る限り、これらのテクノロジーは、割り当てプロセスに必要な柔軟性を提供していません。私は自分が間違っていることを望んでいます。どんなアドバイスでも大歓迎です。