Планирование при разработке с компонентом Service Broker
При разработке приложений компонента Service Broker ознакомьтесь со следующими моментами.
Показатели, характеризующие тип и объем предполагаемых входных и выходных данных приложения.
Требования, предъявляемые к приложению.
Только при учете таких факторов можно разработать систему, отвечающую бизнес-задачам.
Контрольный список планирования
При планировании приложения обратите внимание на следующие вопросы.
Какую роль компонент Service Broker играет в приложении?
Ответ на этот вопрос позволит спланировать типы сообщений, которые приложение будет использовать, структуру приложения, а также хранение и обработку его данных.
Например, приложение использует компонент Service Broker для разрешения пиков активности доставки сообщений путем сохранения сообщений в очереди до тех пор, пока не освободятся ресурсы для их обработки. В этом случае типы сообщений, которые приложение будет использовать, должны наиболее точно соответствовать входным и выходным данным существующего приложения. Оценить потребности приложения в ресурсах хранения и обработки можно, опираясь на существующую рабочую нагрузку.
Напротив, при разработке нового приложения, внимательно рассчитайте, какие операции будут максимально использовать преимущества компонента Service Broker. Использование компонента Service Broker часто освобождает прогнозируемое количество времени обработки, обеспечивая при этом дополнительную надежность — в стандартном приложении произошел бы сбой.
Например, приложение приема заказов через Интернет может не справится с полной обработкой заказа и предоставлением конечного подтверждения, когда заказ уже оформлен. Вместо этого приложение может передать заказ службе, обрабатывающей заказы и обеспечивающей конечное подтверждение по электронной почте. Используя подобную схему, приложение заказов может продолжить принимать заказы даже тогда, когда сетевые проблемы мешают приложению подтверждать их. При разрешении сетевых проблем приложение возобновит обработку заказов. В этом случае хранение и обработка потребностей приложения зависит от числа предполагаемых заказов, размера каждого сообщения заказа и времени его обработки.
Какие сведения требуются в диалоге заказа для выполнения поставленной задачи? Какими схемами сообщений конечные точки будут обмениваться, чтобы предоставить эти сведения друг другу?
Большинство служб обмениваются полуструктурированным сведениями. Таким образом, XML-кодировка является отличным выбором. Двоичная кодировка используется для обмена двоичными файлами, например, изображениями. Когда сообщение осуществляет соединение только по факту доставки, используйте пустое сообщение.
Чтобы не пришлось обновлять приложение позже, установите правильный тип сообщения. В зависимости от кодировки типа сообщений, обновление может включать что угодно — от обновления файла XML-схемы до значительных изменений в коде приложения. Если существуют элементы данных, необходимость в которых отсутствует, но ожидается в будущем, возможно, стоит включить их. Если задать такие элементы в схеме с самого начала, потом не придется дорабатывать схему для их поддержки.
Где будет запускаться логика обработки сообщений?
Приложение можно разработать как хранимую процедуру, активируемую компонентом Service Broker, как фоновую службу, запланированное событие или как внешнее приложение. Конечное решение зависит от роли, которой компонент Service Broker играет в приложении. Например, если приложение обрабатывает непрерывный поток сообщений, доставляемых с прогнозируемой частотой, стоит использовать фоновое приложение. Если приложение должно динамично масштабироваться в зависимости от числа получаемых сообщений, лучшем выбором будет хранимая процедура, активируемая очередью. Если приложение задерживает сообщения в очереди и обрабатывает все сообщения за установленное время, то его стоит разрабатывать как запланированное событие.
Можно использовать внешнее приложение, если программа требует доступа к ресурсам вне базы данных, таким как веб-страницы или файлы. Использование внешнего приложения может улучшить масштабируемость приложения, так как обработка будет происходить на серверах промежуточного уровня, а не на сервере базы данных. Приложение, использующее компонент Service Broker, легко масштабируется, так как компонент Service Broker предоставляет удаленный транзакционный доступ к очередям. Использовать компонент Service Broker может любое приложение, способное отправлять базе данных команды Transact-SQL и обрабатывать результаты.
Каждая внешняя программа изолирована от остальных программ, использующих очередь. Таким образом, для управления доступом внешних программ к очереди не нужны специальные меры предосторожности. Кроме того, если соединение завершается с ошибкой в то время, как приложение обрабатывает сообщение, то для транзакции выполняется откат, а компонент Service Broker возвращает сообщение в очередь. Сетевые проблемы не приводят к тому, что приложение теряет сообщение.
Какую технологию планируется использовать для реализации приложения?
Можно реализовать внешнее приложение, используя любую технологию, способную подключатся к базе данных и запускать инструкции Transact-SQL в SQL Server. Тем не менее, обычно приложения разрабатываются с помощью совместимого с .NET Framework языка и ADO.NET. Можно реализовать хранимую процедуру в Transact-SQL или любом языке, совместимом с .NET Framework. Transact-SQL обеспечивает лучшую производительность по отношению к компоненту Database Engine. Языки программирования, совместимые со средой CLR, обеспечивают большую гибкость, более жесткий контроль за программным потоком, лучшую производительность в приложениях, активно использующих процессор, и прямой доступ к .NET Framework.
Какие серверные компоненты приложение будет использовать наиболее активно?
Сотрудничайте с системным администратором, чтобы убедиться в наличии ресурсов, необходимых для оптимальной производительности приложения. Стоит выяснить, какие компоненты используются наиболее часто. Например, если приложение использует очереди для ослабления рабочей нагрузки или возвращает длительно хранимые сообщения, необходимо убедится, что для роста очереди достаточно места на диске. И наоборот, приложение с большим объемом сообщений, но недостаточным временем ожиданием очереди может использовать большую пропускную способность сети, но потреблять меньше места на диске.
Различаются ли приоритеты сообщений?
В сильно загруженных системах приоритеты диалогов компонента Service Broker помогают убедиться, что важные процессы не блокируются большим числом менее важных. Приоритеты диалогов также включают проектирование, поддерживающее разные уровни служб.