На самом деле это не вопрос разработки, но у меня есть некоторые данные.
Это зависит от того, насколько продвинуты ваши требования к очередям, а также от опыта работы и навыков ваших сотрудников.
если вы развернетесь в магазине, где они знают и любят SQL Server, но не имеют опыта управления MSMQ, то использование SQL для очереди (по сути, добавление дополнительной таблицы в SQL) будет для них простым делом - по сути, нет дополнительные расходы на операции. С другой стороны, использование MSMQ повлечет за собой обучение персонала, разработку и проверку новых процедур, новых планов резервного копирования, новых инструментов мониторинга и администрирования и так далее. И наоборот - в редких случаях магазин имеет хороший опыт работы с MSMQ, но небольшой опыт работы с SQL Server. В этом случае все наоборот: иди с MSMQ.
Возможно, ваше использование очереди структурировано таким образом, что вы не заботитесь о резервном копировании или предотвращении потери данных. В этом случае вы не планируете проводить мониторинг или обслуживание. В этом случае использование MSMQ подразумевает почти нулевые дополнительные эксплуатационные расходы, независимо от имеющихся у персонала навыков, поскольку настройка будет разовой, а текущее обслуживание минимальным.
Вторым критерием является использование вами очереди. Если очередь будет использоваться интенсивно, скажем, миллионы транзакций в час для каждого сервера, то вам, вероятно, понадобится выделенная служба очереди для этого, а не копирование в существующую базу данных. Если вы хотите воспользоваться преимуществами различных функций MSMQ, таких как очереди недоставленных сообщений, приоритетные сообщения, триггеры, списки рассылки и идентификаторы корреляции, тогда рекомендуется MSMQ. С другой стороны, если ваш объем мал (скажем, сотни транзакций в час), и вы не используете более продвинутые функции очереди, то вы можете просто использовать фасад очереди поверх таблицы SQL. Очень просто.
Как сбалансировать эти два основных критерия, решать вам.
Не критерии включают в себя: программируемость (оба варианта легко разрабатывать на разных языках), объем транзакции (оба могут обрабатывать малые и большие объемы), формат данных (оба являются гибкими с точки зрения содержания и формата данных).
В любом случае я бы не рекомендовал использовать альтернативную очередь, если вы уже используете Windows Server. У IBM есть хороший пример в Websphere MQ (урожденный MQSeries), но он не бесплатный, как MSMQ. Кроме того, если вы не используете многоплатформенные сети очередей, вам, вероятно, не нужен MQSeries. Я не считаю какие-либо другие системы массового обслуживания достаточно распространенными для рассмотрения.
Если вы не хотите немного изменить свою модель - вас, возможно, заинтересует брак WCF и WF, который Microsoft недавно заключила. Это позволяет службе WCF запускать рабочий процесс (WF). Сам механизм WF поддерживает организацию очередей, планирование и пассивацию - по сути, есть очередь, поддерживающая его, но как программист вы не имеете дело непосредственно с метафорой очереди. Вместо этого это новая метафора «рабочего процесса». WCF и WF, как и MSMQ, бесплатны (то есть без дополнительных затрат, помимо стоимости лицензирования Windows Server); и включен в Windows Server. Этот подход WCF + WF может быть более привлекательной моделью для новых разработок или если вы предпочитаете воспользоваться преимуществами дизайнеров и инструментов WF. Как и в случае с остальной платформой приложений MS, WF поддерживает транзакционный доступ, поэтому вы можете предоставить семантику «забей и забудь».
Удачи в вашем решении.