Введение в службы Notification Services
Создание приложения
К этому моменту мы только собрали информацию о требованиях и начали думать о том, как следует их реализовать. Мы только приступили к работе.
Мы выбрали для разработки этого приложения службы Notification Services. Службы Notification Services помогут ускорить разработку приложения; кроме того, они предлагают платформу для вызова приложения, когда это, в конце концов, потребуется. Следовательно, нужно иметь представление о том, как наши требования преобразуются в объекты службы Notification Services, а также о процессах компоновки, развертывания и тестирования приложений Notification Services.
В следующем разделе данной лекции приводится информация по следующим вопросам::
- Компоненты приложений служб Notification Services
- Преобразование требований нашего примера Птицеводство в элементы служб Notification Services.
- Создание инфраструктуры разработки, состоящей из базы данных приложения и проекта разработки.
- Создание основы приложения служб Notification Services
- Выполнение первоначального развертывания
- Дальнейшее добавление функций к приложению для удовлетворения требований
Компоненты приложений уведомлений
Теперь, когда вы получили базовые знания о данных, которыми будет управлять приложение, необходимо подумать о том, как должна происходить обработка этих данных. Кроме схемы каждому приложению нужен механизм, чтобы поддерживать работу приложения и работать с данными. В составе механизма решения для уведомлений должны быть реализованы следующие компоненты.
- Сервер SQL Server 2005.Служит для размещения базы данных (как схемы, так и данных) и компонентов служб Notification Services.
- Подписывающее приложение.Предоставляет конечным пользователям интерфейс для ввода и редактирования информации о подписке и устройстве. В нашем примере мы не будем создавать такое приложение. Вместо этого будут использоваться особые приложения для ввода в приложение информации о подписчиках, устройствах подписчиков и данных о подписке. Иногда этот интерфейс не является собственно интерфейсом, а представляет собой триггер другого приложения, например, приложения управления клиентами или кадрами.
- Механизм получения событий, генерируемых во внешнем мире.Службы Notification Services реагируют на события, но как они узнают о них? Службы Notification Services имеют несколько поставщиков событий, которые позволяют передавать события этим службам. Среди поставщиков событий - API объекта событий (модель объекта), Загрузчик XML и API SQL Server, предназначенный для загрузки событий при помощи хранимых процедур. Дополнительную информацию об этих поставщиках можно найти в документации служб Notification Services. В примере с Птицландией для ввода событий непосредственно в соответствующие места мы воспользуемся другим сценарием. Такие события запускают генерирование уведомления и процесс доставки.
- Механизм сопоставления событий подпискам.Сам механизм предоставляется службами Notification Services. Однако вам придется информировать службы Notification Services о том, какие отношения имеются между событиями и подпиской, через так называемое правило сопоставления. Правило сопоставления - это обычная инструкция SQL, которая выбирает такие подписки, которые должны получать определенное событие. В нашем примере правило сопоставления сопоставляет события в определенном регионе с подписчиками, обладающими подписками на этот регион. Таким образом, если для отдельного региона наступает событие, все подписчики, имеющие подписки на этот регион, должны получить уведомления. Нужная нам инструкция SQL должна возвратить список подписок, которые соответствуют определенному региону.
- Механизм физического формирования уведомления.После того, как приложению стало известно, какие уведомления и на какие устройства подписчиков следует отправить, необходимо скомпоновать содержимое, включающее всю необходимую текстовую информацию и форматирование. Службы Notification Services для формирования окончательного уведомления используют шаблоны XSLT. Функции Notification Services включают возможность отправки уведомлений на разных языках (в терминологии служб Notification Services они называются культурами). Если вы решили не использовать многоязычные функции, службы Notification Services все равно требуют указания культуры, которая будет использоваться в процессе работы. Этому механизму потребуются шаблоны XSLT для электронных сообщений в формате HTML и для текстовых SMS-сообщений. Необходимо указать службам Notification Services, когда и какой шаблон следует использовать.
-
Механизм доставки для реальной отправки уведомлений на индивидуальные целевые устройства.Когда информация для уведомления собрана, и шаблон XSLT подготовлен, службы Notification Services отправляют уведомление на сервер доставки или сервер, который будет выполнять окончательную доставку на устройство подписчика. Службы Notification Services предоставляют и этот механизм. Он оптимизирован в отношении производительности и масштабируемости. Информация о конфигурации, необходимая службам Notification Services для подключения к серверам доставки, а именно: имена серверов, IP-адреса и информация для аутентификации - должны быть предоставлены вами.
Примечание. В нашем примере, чтобы упростить процесс настройки, мы воспользуемся каналом доставки File, а не сервером SMTP или SMS. В документации по службам Notification Services есть информация о том, как настроить канал доставки SMTP. Для SMS необходимо написать код самостоятельно или воспользоваться решением сторонних разработчиков. Хотя сначала это может показаться слишком трудным, вспомните о возможности использования веб-служб на базе служб сторонних разработчиков, а также о том, как легко можно написать клиент веб-службы в инфраструктуре .NET.
Как службы Notification Services ожидают наших указаний
Как передать службам Notification Services информацию, о которой говорилось в предыдущем разделе?
Службы Notification Services используют два конфигурационных XML-файла: конфигурационный файл экземпляра (ICF) и файл определения приложения (ADF). Файл ADF содержит большую часть параметров приложения, связанных с конфигурацией, но что представляет собой файл ICF?
Экземпляр служб Notification Services.Службы Notification Services -это компонент, предназначенный для обслуживания нескольких приложений уведомлений на одном и том же программном и аппаратном обеспечении сервера. Это означает, что можно развернуть на одном сервере несколько приложений уведомлений. Службам Notification Services известно, что в таком случае вы с большой вероятностью будете повторно использовать информацию о подписчике и устройстве подписчика более чем в одном решении или приложении, поэтому они хранят эту информацию независимо от данных решения для уведомлений. Данные о подписчике хранятся в базе данных экземпляра, тогда как данные об устройстве подписчика размещаются в базе данных приложения. Обе базы данных получают имена в соответствии с некоторыми внутренними правилами, как вы вскоре убедитесь.
Кроме того, службы Notification Services создают службу Windows для отслеживания всех событий, имеющих отношение к приложению, которое обслуживает экземпляр. Каждый экземпляр поддерживается уникальной веб-службой. Таким образом, экземпляр можно рассматривать как экземпляр веб-службы, управляющей несколькими приложениями служб Notification Services.
Приложение служб Notification Services.База данных для приложения, которое мы пытаемся построить, будет хранить некоторую специфическую информацию и, хотя мы предполагаем повторное использование, понятно, что приложение уведомлений о курсе акций, приложение уведомлений о результатах футбольных матчей и приложение уведомлений о наблюдениях за птицами будут хранить различные виды данных. Следовательно, схемы, ассоциированные с каждым из этих приложений, будут отличаться в большей или меньшей степени. Задача служб Notification Services – управление данными приложения по вашему поручению; при этом для выполнения своей работы они добавляют таблицы, представления, хранимые процедуры, триггеры и любые инструменты служб Notification Services. В результате службы Notification Services запрашивают получение информации от схемы тем способом, который они могут понять и которым могут управлять самостоятельно. Это "понятный способ" в действительности представляет собой XML-файл, который привязан к оп ределенной XML-схеме (XSD). Этот файл похож на сценарий базы данных для создания таблиц, хотя он написан на XML.
Внутренние базы данных служб Notification Services.При отсутствии других указаний, в процессе развертывания конфигурационных файлов на сервере, процесс развертывания создает как минимум две базы данных: одну для данных экземпляра, и еще по одной для каждого приложения, обслуживающего экземпляр. Имена этих баз данных должны соответствовать следующему шаблону:
- База данных экземпляра получает имя <имя_экземпляра>NSMain. В нашем примере это имя SQL2005StepByStepNSMain.
- База данных приложения получает имя <имя_экземпляра><имя_п-риложения>. В нашем примере это имя SQL2005StepByStepBirding.Примечание. В SQL Server 2005 можно использовать любые базы данных по вашему выбору для хранения объектов элементов служб Notification Services, относящихся как к приложению, так и к экземпляру. Notification Services генерирует и управляет многими объектами SQL Server, следовательно, необходимо указать имя схемы, где будут группироваться эти объекты.
Поскольку количество генерируемых объектов значительно, следует использовать общие базы данных только в определенных обстоятельствах. В нашем примере общие базы данных вполне подойдут, поскольку дополнительная информация, которую мы будем использовать, не может оправдать создание отдельной базы данных. Следовательно, можно создать базу данных приложения и дать указание службам Notification Services дополнить ее своими объектами вместо того, чтобы создавать новую базу данных.
Требования, преобразованные в объекты служб Notification Services
Наш контрольный список требований состоит из следующих пунктов:
- Схема базы данных, в том числе:
- Специфическая информация приложения, список доступных регионов.
- События: список актуальных наблюдений за птицами по категориям.
- Подписчики: список заинтересованных людей
- Подписки: список регионов, интересующих определенного подписчика, желательная периодичность получения уведомлений и устройство назначения
- Устройства подписчиков: адреса электронной почты и номера мобильных телефонов
- Хроники: архивные данные об уведомлениях
- Детализированные данные, готовые для уведомления
- Сценарии для:
- Ввода информации о подписчиках, устройствах подписчиков, сведений о подписке в приложении
- Ввода событий
- Инструкция SQL для правила сопоставления
- Элементы, имеющие отношение к доставке:
- Шаблоны XSLT для сообщений электронной почты в формате HTML и текстовых сообщений SMS
- конфигурационная информация, необходимая для подключения к серверам доставки
Элементы, преобразованные в элементы служб Notification Services
К этому моменту мы уже знаем, что приложение служб Notification Services должно включать следующие элементы:
- Особая база данных приложения, содержащая все данные, не относящиеся к службам Notification Services:
- Схема регионов
- Схема типов подписок
- Схема информации о подписчиках
- Файл ICF, или конфигурационный файл экземпляра
- Информация о конфигурации системы
- Информация о конфигурации экземпляра
- Файл ADF, или файл определения приложений, включающий:
- Схему событий
- Схему подписки
- Схему уведомлений
- Схему хроник
- Правило сопоставления
- Для удобства, проект разработки (SQL Server Management Studio), включающий:
Обратите внимание, что мы ничего не сказали о схемах подписчиков и устройствах подписчиков. Службы Notification Services будут управлять ими и диктовать свою схему. Эта предоставляемая службами схема отвечает нашим требованиям. Однако, если бы она нам не подходила, нам пришлось бы добавить в особую базу данных приложения дополнительные данные и использовать поле SubscriberID в схеме служб Notification Services в качестве логического соединения обоих источников.