Введение в службы Notification Services

В предыдущей лекции вы научились использовать службы Reporting Services, предоставляемые SQL Server. В данной лекции речь пойдет о службах Notification Services, еще одном компоненте SQL Server. Службы Notification Services - мощный компонент SQL Server, который позволяет разработчикам быстро спроектировать, реализовать и развернуть масштабируемое приложение уведомлений. Эти задачи решаются посредством значительной автоматизации двух основных элементов: автоматизации всех процессов, вовлеченных в выполнение решения, и автоматизации создания и управления объектами базы данных и приложения.

Такая автоматизация обеспечивает выигрыш в производительности, но требует, чтобы процесс проектирования отвечал принципу, который службы Notification Services используют для работы с уведомлениями. Это означает, что нужно понимать терминологию, архитектуру и механику платформы. Начальная кривая обучения может показаться непреодолимой, поэтому в данной лекции будет продемонстрировано, как применить принципы служб Notification Services к развитию событий в реальном мире.

Сценарий для служб Notification Services

Птицландия - воображаемая страна, которая имеет давние традиции в области птицеведения. Птицеведение занимается наблюдением за жизнью птиц в реальных условиях, сбором информации о том, когда птицы прилетают и улетают, выводят птенцов, сколько птиц насчитывается в данной местности и т. д. Птицеведы обычно любят делиться информацией о том, каких птиц, когда и где они наблюдали.

Вы получили запрос на создание приложения уведомлений на заказ. Ваш клиент – Национальное орнитологическое общество Птицландии; ему необходимо уведомлять своих членов о наблюдениях за птицами по всей стране. Заинтересованные люди должны иметь возможность выбрать уведомление о наблюдениях в определенном регионе или в нескольких регионах страны.

Определение требований

Имея под рукой данный сценарий, вы начинаете разрабатывать черновую схему базы данных. Конечно, в реальном мире до того, как перейти к разработке базы данных, вы займетесь списком требований, разработкой схем UML (Unified Modeling Language, универсального языка моделирования) и другими элементами, но для облегчения восприятия материала в данной лекции мы немного сократим этот процесс.

Предварительные требования

Вероятнее всего, схема включает объекты, показанные в табл. 9.1. Имеет смысл попытаться разработать такое приложение, которое можно было бы использовать повторно в других ситуациях, не имеющих отношения к птицеведению. Следовательно, мы назовем общие объекты родовыми именами, что позволит использовать их повторно, не переписывая общие элементы.

Получается, что три последних имени совпадают с терминами служб Notification Services. Но первый объект, Regions, содержит специфическую для приложения информацию и не совпадает ни с одним из терминов служб Notifications Services.

Дополнительные требования

Наблюдения за птицами делятся на три категории:

• Наблюдения за обычным расселением птиц в регионе, которые можно вести в течение всего года
• Наблюдения за прилетом в регион перелетных птиц
• Наблюдения за редкими птицами Редкие птицы могут останавливаться в регионе на непродолжительное время, а затем не появляться в нем несколько лет. Следовательно, некоторые птицеведы были бы очень заинтересованы в информации об их появлении.

Таким образом, наше приложение должно отвечать следующим требованиям:

• Подписчики должны иметь возможность подписаться на немедленные уведомления о наблюдениях редких птиц и/или уведомления по регулярному расписанию о не столь срочных событиях.
• Подписчики должны иметь возможность получить уведомления на выбранное ими устройство. Особенно заинтересованные птицеведы хотели бы получать особые уведомления в виде SMS (коротких текстовых сообщений) на свои мобильные телефоны. Остальные подписчики, возможно, предпочли бы ежедневные или еженедельные уведомления по электронной почте.

Эти два требования вызывают необходимость некоторых изменений в схеме приложения. Нам придется отслеживать следующие моменты:

• Предпочитаемое устройство назначения для каждого подписчика.Информация об устройстве включает адрес электронной почты, номер мобильного телефона и т. п.
• Какая подписка какому устройству соответствует.Например, срочные уведомления должны отсылаться на мобильный телефон, а периодические - по электронной почте.
• Периодичность уведомлений.Периодичность может выражаться значениями немедленно, ежедневно или еженедельно.
• Категория наблюдений.Для данного примера мы выделим три категории: обычные, перелетные, редкие.
• Какие уведомления по какой подписке следует отправлять.Необходимо хранить дату и время наступления события, а также дату и время передачи информации приложению. Получив эту информацию, приложение уведомлений должно определить, например, какие события были отправлены по ежедневной подписке, а какие из них пока не были отправлены по еженедельной подписке.

Как обеспечить соответствие этим требованиям?

• Сведения об устройствах подписчиков должны храниться вместе с информацией о подписчиках.
• Информация о том, какое устройство какой подписке соответствует, должна храниться вместе с информацией о подписке.
• Информация о времени должна храниться вместе с информацией о подписке.
• Информация о категории должна храниться вместе с событием, причем это значение должно быть предоставлено лицом, наблюдавшим событие. Таким образом, если кто-либо вводит информацию о наблюдении в решение для уведомления, он обязан указать категорию - обычные птицы, перелетные птицы или редкие птицы.

Архивная информация

Управлять архивной информацией несколько сложнее. Необходимо сравнивать дату и время наступления вводимого события с датой и временем последней операции отправки уведомления. Наша схема базы данных не содержит никакой информацией о том, когда отправляются уведомления. Следовательно, нам нужно отслеживать обработку уведомлений.

Для этого можно выбрать одну из двух моделей:

• Запись даты и времени обработки подписки по типам. Придется записывать тип подписки (ежедневная или еженедельная) вместе с датой и временем, когда был запущен процесс отправки. При запуске процесса отправки система сохраняет текущие значения даты и времени. В результате получается только две записи: одна для еженедельных подписок и одна для ежедневных подписок.
• Запись даты и времени обработки каждой подписки. Записывается идентификатор конкретной подписки вместе со значениями даты и времени начала обработки или идентификатор последнего события, включенного в уведомление.

Какую из двух моделей выбрать? Вести запись дат по типам подписки проще, чем по каждой подписке. Первый вариант требует хранения только одной записи для каждого типа подписки. Второй подход требует хранения по одной записи для каждой подписки и некоторой логики для поддержания синхронности обеих таблиц (подписок и процессов). Однако в случае, если уведомление не доставляется, подход по типам не позволит пострадавшему подписчику когда-либо получить уведомление. Этот недостаток может быть допустимым в некоторых не имеющих критической важности приложениях уведомлений, но он будет неприемлемым в другой группе приложений, например, в тех, которые связаны с ожиданием действий со стороны подписчика (необходимость обратного звонка, изменения контракта, жалобы клиента и т. д.). Действительно, даже подписчики, которые подписаны на получение уведомлений, не являющихся критически важными, предпочли бы не пропустить ни одного события. Следовательно, из соображений повторного использования и обеспечения полноты предоста вляемой информации, следует предпочесть второй вариант.

Совет. В терминах служб Notification Services, архивные данные хранятся в таблицах хроники.

Разнообразие устройств

Из-за того, что наше приложение должно отправлять уведомления на различные устройства и носители, возникают некоторые дополнительные требования. Сообщения электронной почты должны доставляться при помощи сервера SMTP, а SMS-сообщения с помощью сервера текстовых сообщений. Кроме того, формат сообщений электронной почты, обычно HTML, не подходит для отправки текстовых сообщений SMS, и наоборот. Следовательно, решение должно уметь отсылать разные байты на различные типы серверов. Это проблема конфигурации, но она имеет некоторое отношение и к архитектуре приложения.

Для реализации этих функций также существует несколько возможностей, от жесткого программирования процесса построения сообщения в приложении до использования программ сторонних разработчиков для обработки процесса преобразования. Службы Notification Services решают эту проблему с учетом открытости системы: для каждого типа устройств необходимо предоставить файл XSLT (eXtensible Stylesheet Language Transformation, преобразования расширяемого языка стилей) (для полноты нужно иметь комбинацию файла XSLT для каждого устройства и языкового стандарта). Механизм XSLT может использовать XSLT-шаблон для преобразования ввода XML в вывод других типов (HTML, XML или текст). Следовательно, это весьма подходящий способ для удовлетворения некоторых требований.

Информация уведомления

Внутренние процессы приложения будут управлять информацией в модуле подготовки, который не является дружественным к пользователю.

Например, приложение ссылается на все объекты не по имени, а по числу-идентификатору. Однако, при подготовке данных для реальной доставки конечному пользователю, преобразование идентификаторов в текстовую информацию обязательно.

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

Соображения производительности и масштабируемости

Хотя наш клиент мог ничего не сказать о проблемах производительности, нам следует иметь их в виду. Сообщения электронной почты и текстовые сообщения должны доставляться подписчикам в индивидуальном порядке. Известно, что записать строку в таблицу гораздо быстрее, чем отправить сообщение по электронной почте, главным образом, вследствие сетевых задержек. В случае отсылки уведомлений большому количеству подписчиков через короткие промежутки времени может возникнуть узкое место, вследствие чего полезность приложения снизится. Необходимо предусмотреть возможные способы минимизации рабочей нагрузки процесса доставки. У нас есть две возможности ускорить время доставки:

• Уменьшить время, отводимое на отправку каждого сообщения
• Уменьшить количество отправляемых сообщений

Уменьшить время, необходимое для отправки отдельного сообщения, можно несколькими способами:

• Использование более скоростных аппаратных устройств
• Использование более скоростных сетевых устройств
• Уменьшение размера сообщения

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

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