В 1997 г. в
составе NT4 Option Pack был выпущен MSMQ 1.0 - см. http://www.emanual.ru/download/www.eManual.ru_4364.html.
Восемь лет
спустя механизм асинхронной работы на основе очередей под названием
Service Broker появился в составе SQL Server 2005. Мы его уже
затрагивали в
посте про Event
Notification. Здесь придется
коснуться его чуть более подробно, т.к. далее он понадобится в
развитии репликации с помощью Change Tracking на распределенный
сценарий. Подобно MSMQ сервис-брокер предназначен для асинхронного
взаимодействия, что позволяет реализовать отсоединенные сценарии,
когда SQL Serverное приложение
отправляет сообщение другому SQL
Serverному приложению и может заниматься
дальше своими делами, не подвисая в ожидании ответа от удаленного
участника. В MSMQ, он же Queued
Components в СОМ+, размер сообщения ограничен 4 МБ, в
сервис-брокере сообщение представляет собой, вообще говоря,
varbinary(max) - 2 ГБ. Поддерживается (в пределах беседы) порядок и
корреляция сообщений, нет нужды прибегать к дополнительному
программированию для поддержки транзакций, синхронизации и
блокировкам при одновременной обработке очереди с нескольких
потоков, резервного копирования и пр., т.к. все это является
штатной функциональностью SQL Server, а очереди в сервис-брокере
построены на основе таблиц. То есть данные сообщения и
транзакционные бизнес-данные в случае SQL Server имеют одинаковую
природу и хранятся вместе, что разом снимает массу головной боли,
присущей архитектуре MSMQ, вообще всем очередникам общего
назначения. Однако это накладывает свою специфику - сервис-брокер
есть составная часть SQL Server и работает только с ним. Это не
есть излишне строгое ограничение, поскольку SQL Server является
нынче неотъемлемым атрибутом каждого уважающего себя разработчика.
Кстати, все уже поставили себе 2010 СТР2 (http://technet.microsoft.com/en-us/evalcenter/ee315247.aspx)? Сравнение сервис-брокера с MSMQ можно посмотреть,
например, здесь - http://www.devx.com/dbzone/Article/34110.