Автор(ы): Ivan Bodyagin
Дата: 07.10.2005
Как правило, приложение, в ходе своей работы, последовательно выполняет набор команд, и даже если необходимо обратиться к другому приложению, то оно покорно ожидает ответа. Однако множество самых различных приложений могут выполнять несколько кусочков своей работы одновременно или же отдавать на выполнение часть своей работы другим приложениям, забирая результаты обратно по мере готовности, это в том случае, если есть необходимость забирать результат, а то можно и вовсе отдать и забыть. Такой стиль работы, в дальнейшем будем называть его асинхронным, может сделать приложение более масштабируемым, производительным и доступным, словом сплошная польза и почти никакого вреда, и чем больше приложение, тем больше пользы от такого подхода. Причиной же засилия синхронных приложений, при всех очевидных премуществах асинхронных, является очень высокая трудоемкость написания последних.
В процессе разработки следующей версии SQL Server-а, ожидаемую с большим нетерпением, Microsoft решил немного исправить эту ситуацию и реализовать некий набор механизмов, позволяющий не писать каждый раз фреймворк по асинхронной работе, а заниматься непосредственно разработкой асинхронных приложений решающих насущные задачи.
Как наверное уже известно, основная функциональность, обеспечивающая асинхронность и работу с очередями в новой версии SQL Server, реализована с помощью некоего сервиса для работы с сообщениями под названием Service Broker. Но в данной статье речь пойдет не совсем о нем (он сам по себе может являться темой не одной статьи), а скорее о способах его (и не только его) использования для асинхронной обработки данных вообще и обработки очередей в частности. Иными словами, о том, какими способами можно сделать работу с данными чуть более асинхронной, и как в этом может помочь SQL Server 2005 совместно с ADO.Net 2.0.