Поделиться через

Создание типов сообщений Service Broker

Область применения: SQL Server Управляемый экземпляр SQL Azure

Тип сообщения определяет имя определенного типа сообщения и проверку того, что Service Broker выполняет для этого типа сообщения. Чтобы определить типы сообщений, которые будет использовать приложение, сначала вы планируете задачи, которые должны выполнять приложение, и данные, необходимые для выполнения каждой задачи.

Наиболее распространенный подход для приложения — структурировать сообщения таким образом, чтобы каждое сообщение содержит сведения, необходимые для одного шага задачи. Когда каждое сообщение содержит сведения для одного шага задачи, приложение может легко получить сообщение, завершить шаг и отправить ответ в рамках одной транзакции. Поэтому для многих приложений самый простой способ определить типы сообщений и содержимое сообщения — определить границы транзакций для задач, выполняемых приложением. Каждый отдельный шаг — это транзакция, и каждая транзакция соответствует типу сообщения, обменяемого между службами. Сведения о состоянии, результаты или выходные данные также являются типами сообщений.

Протоколы связи Service Broker предназначены для работы с этим стилем обмена сообщениями. Протокол диалога фрагментирует большие сообщения для передачи и гарантирует, что большие сообщения не препятствуют передаче небольших сообщений.

Выбор типа проверки

Проверка, указанная для сообщения, зависит от содержимого сообщения. Распространенная практика заключается в использовании наиболее строгой проверки, доступной во время тестирования, а затем выбирать менее строгие проверки, чтобы повысить производительность при развертывании приложения. Например, можно обменять типизированный XML-документ в виде текста сообщения, указывающего проверку NONE. В этом случае приложение проверяет сообщение при обработке XML.

Сетевой формат сообщения содержит имя типа сообщения. Поэтому имена типов сообщений часто выбираются, чтобы избежать проблем сортировки и конфликтов именования. Дополнительные сведения об именовании см. в разделе Именование объектов Service Broker.

Указание успешности и сбоя

Обычно приложение не определяет новые типы сообщений, указывающие на успех или сбой. Вместо этого используйте инструкцию END CONVERSATION, чтобы указать, что беседа завершена и что задача выполнена успешно. Если задача завершилась ошибкой, включите параметр WITH ERROR, чтобы вернуть сообщение об ошибке в беседе.

Как правило, только один из участников беседы должен завершить беседу после завершения задачи. Другой участник выдает только end CONVERSATION в ответ на сообщение "Конец" или "Ошибка". В документации по службе обычно указывается, какой участник завершает беседу, если беседа завершается успешно. Предоставление этой документации помогает избежать проблем, когда ни один участник не заканчивает беседу, или где один участник завершает беседу, пока другой участник по-прежнему выполняет задачи. Обе конечные точки должны иметь возможность обрабатывать сообщения об ошибках, так как внутренние сообщения Service Broker доставляются обеим конечным точкам. Например, если срок действия диалога истекает до закрытия диалогового окна, обе конечные точки получают сообщение об ошибке Service Broker.

Любой участник может завершить беседу ошибкой в любое время. Обсуждение обработки сообщений об ошибках компонента Service Broker см. в разделе Обработка сообщений об ошибках компонента Service Broker.

См. также