Все, объекты готовы. Теперь можно приступать
собственно к передаче сообщения. В данном примере рассматривается самый простой
вариант: из отправляющего сервиса сообщение попадает в очередь получателя и
забирается оттуда.
Сначала займемся получателем. Для получения сообщения
служит команда RECEIVE, которая сильно напоминает обычный SELECT, только вместо
имени таблицы указывается имя очереди. К слову, и команда SELECT для очереди
работает (поскольку с точки зрения базы данных очередь – это обычная таблица), показывая ее содержимое, но ничего из нее не удаляя. Команда же RECEIVE
выбирает данные из очереди, удаляя выбранные сообщения. Однако если очередь
пуста, RECEIVE отработает вхолостую и вернет пустой набор данных, а хотелось
бы, чтобы кто-то караулил очередь, и RECEIVE бы срабатывала, как только в
очереди что-то появится. К счастью, в этом нет ничего сложного, достаточно
обернуть RECEIVE в WAITFOR. Итак, в отдельном окне выполняем следующую команду
для своевременного получения сообщения:
WAITFOR(RECEIVE
cast(message_body as nvarchar(MAX)) FROM [TargetQueue])
|
После выполнения этой команды подключение замрет в
ожидании сообщения из очереди. Теперь самое время заняться отправителем. У него
задачка посложнее, надо начать диалог и передать сообщение с идентификатором
открытого диалога.
DECLARE @convHandler uniqueidentifier
-- начало диалога
--
BEGIN DIALOG @convHandler
FROM SERVICE [SourceService]
TO SERVICE 'TargetService'
ON CONTRACT [TestContract];
-- посылка сообщения
--
SEND ON CONVERSATION @convHandler
MESSAGE TYPE [TestType]
(N'Message!!!')
-- завершение диалога
--
END CONVERSATION @convHandler
|
Если после отправки сообщения вернуться в окошко, где
ожидали его получения, можно увидеть, что сообщение успешно получено.
Стоит заметить, что TargetService при создании диалога
взят в кавычки, а SourceService – нет. Дело в том, что TargetService может быть
создан на совершенно другом сервере, и просто отсутствовать на сервере, где
начинается диалог такого сервиса.
Как можно видеть из примера, в каком именно диалоге
отправлять сообщение, определяется некой меткой (handler), которая возвращается
при создании диалога, и представляет собой GUID. Если ее в какой-то момент
потерять, то завершить диалог можно будет только административными методами, узнав этот GUID из служебных представлений (catalog view). Эта же метка
приезжает к получателю вместе с сообщением, и выбрав эту метку из очереди, можно отправить сообщение обратно в том же диалоге.
Асинхронные триггеры
Теперь рассмотрим, как можно использовать
коммуникативные возможности Service Broker на сервере. Например, можно
использовать его для реализации асинхронных триггеров, причем не только для
DML- и DDL-операций, но и для событий, отслеживаемых профайлером (trace
events), и если DML-триггеры придется реализовывать отчасти с применением
обычных, то для DDL-триггеров и событий профайлера предусмотрен специальный
механизм.
Асинхронные DML-триггеры
Рекомендуем скачать другие рефераты по теме: рефераты на казахском языке, реферат на тему время.
Предыдущая страница реферата |
1
2
3
4
5
6
7
8
9
10
11 |
Следующая страница реферата