Я закодировал именно этот вид службы Windows, и я думаю, что вы на правильном пути. Я использую таблицу базы данных для своей очереди, которая дает мне постоянную очередь в случае сбоя системы, легко позволяет нескольким авторам по всей локальной сети и позволяет мне управлять конфликтами посредством транзакций.
Я создаю отдельные потоки для каждого процесса и отслеживаю количество активных потоков, что позволяет мне настраивать на лету. Поскольку каждый поток выполняет вызов веб-службы, использование пула потоков имело незначительную выгоду, и это также позволило мне запустить множество потоков, поскольку они блокировали ожидание на внешнем сервере.
Легко управлять, если вы разрешите только одного считывателя, что позволит вам отслеживать записи очереди, которые вы прочитали, просто используя столбец идентификации и выбирая следующий, более высокий, чем последний. По завершении потока он может удалить запись, с которой работал.
Если ваш сервис выходит из строя, он просто получит первую непрочитанную запись. Вы можете стать более привлекательным, включив столбец, в котором указано, когда была произведена запись, и если обработка не удалась (возможно, из-за тайм-аута сети), вы можете отменить ее и позволить ей быть пойманным при следующем чтении. Если вам нужно иметь несколько считывателей, используйте поле отметки времени, которое указывает, когда оно было затронуто; один считыватель может восстановить другой сбойный читатель, проверив, когда запись была затронута.
Вам также следует перехватывать событие закрытия службы, чтобы вы могли аккуратно завершить обработку, и включить собственную регистрацию, чтобы можно было отслеживать, что происходит, когда вы получаете несколько одновременных писателей.
Также рассмотрите тестовую версию, которая позволяет вам забить устройство чтения очереди и измерить, как он работает под нагрузкой. Это поможет вам отсеять неочевидные ошибки, которые скрываются в многопоточных приложениях.
Но у меня был взрыв, создающий это, и я надеюсь, что вы тоже.