В предыдущей лекции вы научились использовать службы Reporting Services, предоставляемые SQL Server. В данной лекции речь пойдет о службах Notification Services, еще одном компоненте SQL Server. Службы Notification Services - мощный компонент SQL Server, который позволяет разработчикам быстро спроектировать, реализовать и развернуть масштабируемое приложение уведомлений. Эти задачи решаются посредством значительной автоматизации двух основных элементов: автоматизации всех процессов, вовлеченных в выполнение решения, и автоматизации создания и управления объектами базы данных и приложения.
Такая автоматизация обеспечивает выигрыш в производительности, но требует, чтобы процесс проектирования отвечал принципу, который службы Notification Services используют для работы с уведомлениями. Это означает, что нужно понимать терминологию, архитектуру и механику платформы. Начальная кривая обучения может показаться непреодолимой, поэтому в данной лекции будет продемонстрировано, как применить принципы служб Notification Services к развитию событий в реальном мире.
Птицландия - воображаемая страна, которая имеет давние традиции в области птицеведения. Птицеведение занимается наблюдением за жизнью птиц в реальных условиях, сбором информации о том, когда птицы прилетают и улетают, выводят птенцов, сколько птиц насчитывается в данной местности и т. д. Птицеведы обычно любят делиться информацией о том, каких птиц, когда и где они наблюдали.
Вы получили запрос на создание приложения уведомлений на заказ. Ваш клиент – Национальное орнитологическое общество Птицландии; ему необходимо уведомлять своих членов о наблюдениях за птицами по всей стране. Заинтересованные люди должны иметь возможность выбрать уведомление о наблюдениях в определенном регионе или в нескольких регионах страны.
Имея под рукой данный сценарий, вы начинаете разрабатывать черновую схему базы данных. Конечно, в реальном мире до того, как перейти к разработке базы данных, вы займетесь списком требований, разработкой схем UML (Unified Modeling Language, универсального языка моделирования) и другими элементами, но для облегчения восприятия материала в данной лекции мы немного сократим этот процесс.
Вероятнее всего, схема включает объекты, показанные в табл. 9.1. Имеет смысл попытаться разработать такое приложение, которое можно было бы использовать повторно в других ситуациях, не имеющих отношения к птицеведению. Следовательно, мы назовем общие объекты родовыми именами, что позволит использовать их повторно, не переписывая общие элементы.
| Объект | Имя |
|---|---|
| Список регионов | Region |
| Список наблюдений | Events |
| Список заинтересованных людей | Subscribers |
| Список регионов, сведения о которых интересуют данное лицо | Subscriptions |
Получается, что три последних имени совпадают с терминами служб Notification Services. Но первый объект, Regions, содержит специфическую для приложения информацию и не совпадает ни с одним из терминов служб Notifications Services.
Наблюдения за птицами делятся на три категории:
Таким образом, наше приложение должно отвечать следующим требованиям:
Эти два требования вызывают необходимость некоторых изменений в схеме приложения. Нам придется отслеживать следующие моменты:
Как обеспечить соответствие этим требованиям?
Управлять архивной информацией несколько сложнее. Необходимо сравнивать дату и время наступления вводимого события с датой и временем последней операции отправки уведомления. Наша схема базы данных не содержит никакой информацией о том, когда отправляются уведомления. Следовательно, нам нужно отслеживать обработку уведомлений.
Для этого можно выбрать одну из двух моделей:
Какую из двух моделей выбрать? Вести запись дат по типам подписки проще, чем по каждой подписке. Первый вариант требует хранения только одной записи для каждого типа подписки. Второй подход требует хранения по одной записи для каждой подписки и некоторой логики для поддержания синхронности обеих таблиц (подписок и процессов). Однако в случае, если уведомление не доставляется, подход по типам не позволит пострадавшему подписчику когда-либо получить уведомление. Этот недостаток может быть допустимым в некоторых не имеющих критической важности приложениях уведомлений, но он будет неприемлемым в другой группе приложений, например, в тех, которые связаны с ожиданием действий со стороны подписчика (необходимость обратного звонка, изменения контракта, жалобы клиента и т. д.). Действительно, даже подписчики, которые подписаны на получение уведомлений, не являющихся критически важными, предпочли бы не пропустить ни одного события. Следовательно, из соображений повторного использования и обеспечения полноты предоста вляемой информации, следует предпочесть второй вариант.
Из-за того, что наше приложение должно отправлять уведомления на различные устройства и носители, возникают некоторые дополнительные требования. Сообщения электронной почты должны доставляться при помощи сервера SMTP, а SMS-сообщения с помощью сервера текстовых сообщений. Кроме того, формат сообщений электронной почты, обычно HTML, не подходит для отправки текстовых сообщений SMS, и наоборот. Следовательно, решение должно уметь отсылать разные байты на различные типы серверов. Это проблема конфигурации, но она имеет некоторое отношение и к архитектуре приложения.
Для реализации этих функций также существует несколько возможностей, от жесткого программирования процесса построения сообщения в приложении до использования программ сторонних разработчиков для обработки процесса преобразования. Службы Notification Services решают эту проблему с учетом открытости системы: для каждого типа устройств необходимо предоставить файл XSLT (eXtensible Stylesheet Language Transformation, преобразования расширяемого языка стилей) (для полноты нужно иметь комбинацию файла XSLT для каждого устройства и языкового стандарта). Механизм XSLT может использовать XSLT-шаблон для преобразования ввода XML в вывод других типов (HTML, XML или текст). Следовательно, это весьма подходящий способ для удовлетворения некоторых требований.
Внутренние процессы приложения будут управлять информацией в модуле подготовки, который не является дружественным к пользователю.
Например, приложение ссылается на все объекты не по имени, а по числу-идентификатору. Однако, при подготовке данных для реальной доставки конечному пользователю, преобразование идентификаторов в текстовую информацию обязательно.
Чтобы ускорить формирование окончательного уведомления для доставки, следует подготовить информацию, которая нужна этому процессу. Например, вместо хранения идентификатора региона следует хранить название региона. Кроме того, вместо идентификатора события следует хранить описание события. Таким образом, когда механизм примет решение отравить уведомление, для получения нужной информации ему не придется выполнять соединения и поиск по нескольким таблицам..Он просто прочитает запись в таблице, в которой все данные подготовлены в соответствии с его требованиями и готовы для отправки подписчику.
Хотя наш клиент мог ничего не сказать о проблемах производительности, нам следует иметь их в виду. Сообщения электронной почты и текстовые сообщения должны доставляться подписчикам в индивидуальном порядке. Известно, что записать строку в таблицу гораздо быстрее, чем отправить сообщение по электронной почте, главным образом, вследствие сетевых задержек. В случае отсылки уведомлений большому количеству подписчиков через короткие промежутки времени может возникнуть узкое место, вследствие чего полезность приложения снизится. Необходимо предусмотреть возможные способы минимизации рабочей нагрузки процесса доставки. У нас есть две возможности ускорить время доставки:
Уменьшить время, необходимое для отправки отдельного сообщения, можно несколькими способами:
Какой бы способ вы не выбрали, время, которое требуется на отправку одного сообщения электронной почты или текстового сообщения, будет зависеть от характеристик сети, которые вы не можете контролировать. Следовательно, следует предпочесть уменьшение количества отправляемых сообщений. Проанализировав характер уведомлений, можно заметить, что многие подписчики разделяют интерес к данному региону, и лишь некоторые подписчики подписались на
К этому моменту мы только собрали информацию о требованиях и начали думать о том, как следует их реализовать. Мы только приступили к работе.
Мы выбрали для разработки этого приложения службы Notification Services. Службы Notification Services помогут ускорить разработку приложения; кроме того, они предлагают платформу для вызова приложения, когда это, в конце концов, потребуется. Следовательно, нужно иметь представление о том, как наши требования преобразуются в объекты службы Notification Services, а также о процессах компоновки, развертывания и тестирования приложений Notification Services.
В следующем разделе данной лекции приводится информация по следующим вопросам::
Теперь, когда вы получили базовые знания о данных, которыми будет управлять приложение, необходимо подумать о том, как должна происходить обработка этих данных. Кроме схемы каждому приложению нужен механизм, чтобы поддерживать работу приложения и работать с данными. В составе механизма решения для уведомлений должны быть реализованы следующие компоненты.
Как передать службам Notification Services информацию, о которой говорилось в предыдущем разделе?
Службы Notification Services используют два конфигурационных XML-файла: конфигурационный файл экземпляра (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.Поскольку количество генерируемых объектов значительно, следует использовать общие базы данных только в определенных обстоятельствах. В нашем примере общие базы данных вполне подойдут, поскольку дополнительная информация, которую мы будем использовать, не может оправдать создание отдельной базы данных. Следовательно, можно создать базу данных приложения и дать указание службам Notification Services дополнить ее своими объектами вместо того, чтобы создавать новую базу данных.
Наш контрольный список требований состоит из следующих пунктов:
К этому моменту мы уже знаем, что приложение служб Notification Services должно включать следующие элементы:
Обратите внимание, что мы ничего не сказали о схемах подписчиков и устройствах подписчиков. Службы Notification Services будут управлять ими и диктовать свою схему. Эта предоставляемая службами схема отвечает нашим требованиям. Однако, если бы она нам не подходила, нам пришлось бы добавить в особую базу данных приложения дополнительные данные и использовать поле SubscriberID в схеме служб Notification Services в качестве
Теперь давайте приступим к созданию нашего приложения. SQL Server Management Studio не включает шаблон для проектов служб Notification Services, хотя можно создать проект для размещения файлов, имеющих отношение к службам Notification Services.
Вместо того, чтобы начинать с нуля, воспользуемся для создания приложения уведомления по птицеводству проектом
Установка примеров (образцов) SQL Server.Далее в материале этой лекции используется пример
Кроме того, можно установить примеры и изучить темы Учебника по службам Notification Services в дополнение к материалам этой лекции.
Хотя службы Notification Services работают со всеми элементами, имеющими отношение к уведомлениям, они не работают со специфическими данными приложения. В сценарии Птицеводство это означает, что службы Notification Services не будут обслуживать информацию о доступных регионах или категориях наблюдений.
Аналогично, службы Notification Services будут содержать минимум данных о самих подписчиках, сохраняя для каждого из них только идентификатор. Если нужно отслеживать информацию о подписчиках, следует подумать о разработке стандартного приложения или использовать решение, основанное на членстве. Идентификатор, хранимый службами Notification Services, представляет собой связь между службами и решением для отслеживания информации о подписчиках.
В нашем примере вы создадите базу данных для хранения всей информации, не специфичной для служб Notification Services. Эта база данных очень простая, но она полезна в качестве примера.
EmptyADF.xml и выберите из контекстного меню команду Rename (Переименовать). Измените имя файла на BirdingADF.xml.Прежде, чем можно будет продолжить работу, требуется сделать несколько базовых определений приложения.
Файл
В терминах служб Notification Services, каждый отличающийся создаваемый тип элемента называется классом, например, класс событий или класс подписки. Каждый класс может содержать более одной таблицы. Классы можно даже разбивать на несколько таблиц и вновь соединять при помощи одного или более представлений, в зависимости от типа класса.
Команды SQL, которые выполняют операции сопоставления или обновления, называются правилами, например, правило событий, правило хроники событий или запланированные правила.
В следующих разделах мы создадим файл
BirdingADF.xml, выполнив двойной щелчок на нем в окне Solution Explorer (Обозреватель решений).Вместо комментария <!-- Replace with EventClasses XML --> введите или вставьте следующий фрагмент XML:
<!- Event Classes ->
<EventClasses>
<EventClass>
<EventClassName>SightData</EventClassName>
<Schema>
<Field>
<FieldName>RegionID</FieldName>
<FieldType>varchar(5)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>Date</FieldName>
<FieldType>datetime</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>Observation</FieldName>
<FieldType>nvarchar(500)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>Category</FieldName>
<FieldType>char(1)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
</Schema>
<IndexSqlSchema>
<SqlStatement>
CREATE INDEX myIndex
ON SightData ( Date );
</SqlStatement>
</IndexSqlSchema>
</EventClass>
</EventClasses>
Обратите внимание на структуру содержимого. Она выглядит как обычное определение схемы базы данных, но выражено при помощи синтаксиса XML. Мы объявляем имя класса событий вместо имени таблицы, затем поля, типы данных, модификаторы для приема нулевых значений и т. д.
Кроме того, при объявлении полей, которые будут формировать SightData, можно включить информацию об индексах, которые, по вашему мнению, полезно будет применить при обращении к таблице правила сопоставления. Таким образом, если известно, что правило сопоставления будет использовать данные столбца RegionID в качестве фильтра либо самостоятельно, либо в предложении JOIN, можно дать указание службам Notification Services создать соответствующие индексы. Это будет полезно в тех случаях, если данные поступают в больших пакетах; это не характерно для примера с Птицландией, поэтому в индексах нет необходимости. Элемент IndexSqlSchema показан просто как напоминание. Дополнительную информацию об использовании индексов для повышения производительности запросов можно найти в лекции 2 "Повышение производительности запроса".
Определение класса подписки.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Subscription Classes —>:
<!— Subscription Classes —>
<SubscriptionClasses>
<SubscriptionClass>
<SubscriptionClassName>SightRegionSubs</SubscriptionClassName>
<Schema>
<Field>
<FieldName>DeviceName</FieldName>
<FieldType>nvarchar(255)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>SubscriberLocale</FieldName>
<FieldType>nvarchar(10)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>RegionID</FieldName>
<FieldType>varchar(5)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
</Schema>
<EventRules>
<EventRule>
<RuleName>SightRegionEventRule</RuleName>
<EventClassName>SightData</EventClassName>
<Action>
INSERT INTO SightAlerts(SubscriberId, DeviceName, SubscriberLocale,
Region, Date, Observation, Category)
SELECT s.SubscriberId, s.DeviceName, s.SubscriberLocale,
e.RegionID, e.Date, e.Observation, e.Category
FROM SightData e, SightRegionSubs s
WHERE e.RegionID = s.RegionID;
</Action>
</EventRule>
</EventRules>
</SubscriptionClass>
</SubscriptionClasses>
Объявление схем подписки аналогично объявлению классов событий в предыдущем разделе. Как и в предыдущем случае, мы указываем вместо имени таблицы имя класса подписки, затем имена полей и т. д.
Определение подписки включает один важный объект: правило сопоставления событий. В правиле после класса событий указывается имя, к которому оно относится, а затем инструкция T-SQL, которая задает действующее правило.
Для понимания этого правила нам придется немного забежать вперед. Задача инструкции RULE – вставка записей в таблицу, или класс, уведомлений, который мы еще не определили. Следовательно, ни имя таблицы назначения, ни поля, которые она содержит, нам не известны. Они будут определены ниже при определении класса уведомлений.
Инструкция RULE собирает необходимые столбцы из двух исходных классов: класса событий и класса подписки, а также, что еще более важно, включает ключ для понимания отношения между этими двумя классами. В приведенном выше коде правило сопоставления сопоставляет идентификатор RegionID из класса событий идентификатору RegionID из класса подписки. Таким образом, подписчики получат уведомления, когда будет выполнено наблюдение в регионе, хранящемся в записи о подписке каждого подписчика.
Определение класса уведомлений.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Notification Classes —>:
<!— Notification Classes —>
<NotificationClasses>
<NotificationClass>
<NotificationClassName> SightAlerts </NotificationClassName>
<Schema>
<Fields>
<Field>
<FieldName>Region</FieldName>
<FieldType>nvarchar(35)</FieldType>
</Field>
<Field>
<FieldName>Date</FieldName>
<FieldType>datetime</FieldType>
</Field>
<Field>
<FieldName>Observation</FieldName>
<FieldType>nvarchar(500)</FieldType>
</Field>
<Field>
<FieldName>Category</FieldName>
<FieldType>char(1)</FieldType>
</Field>
</Fields>
</Schema>
<ContentFormatter>
<ClassName>XsltFormatter</ClassName>
<Arguments>
<Argument>
<Name>XsltBaseDirectoryPath</Name>
<Value>%_AppPath_%</Value>
</Argument>
<Argument>
<Name>XsltFileName</Name>
<Value>BirdingTransform.xslt</Value>
</Argument>
</Arguments>
</ContentFormatter>
<Protocols>
<Protocol>
<ProtocolName>File</ProtocolName>
</Protocol>
</Protocols>
</NotificationClass>
</NotificationClasses>
Здесь содержимое схемы класса уведомлений также достаточно понятно, но содержит кое-что неожиданное. В данном случае схеме сопутствует элемент ContentFormatter. Элемент ContentFormatter указывает, какой компонент будет отвечать за формирование уведомления в окончательном виде. Подробнее об этом элементе будет рассказано ниже в разделе "Как скомпоновать сообщение уведомления?"
Определение поставщиков.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Replace with Providers —>:
<!- Providers XML ->
<Providers>
<NonHostedProvider>
<ProviderName>BirdingSPEventProvider</ProviderName>
</NonHostedProvider>
</Providers>
Этот XML-фрагмент показывает, что поступит по маршруту, который находится не под управлением служб Notification Services. Нажмите кнопку Save (Сохранить) на панели инструментов, чтобы сохранить файл BirdingADF.xml, не потеряв изменений.
На следующем этапе необходимо отредактировать ICF-файл. Этот файл представляет собой исходную точку, через которую службы Notification Services будут выполнять синтаксический анализ конфигурационных файлов и осуществлять все необходимые действия. Следовательно, он содержит некоторую основную информацию и данные, специфичные для экземпляра.
Откройте для редактирования файл SQL2005StepByStepICF.xml, выполнив двойной щелчок на файле в окне Solution Explorer (Обозреватель решений). Нужно будет изменить его содержимое так, чтобы оно соответствовало действующей конфигурации компьютера.
DBEngineInstance_ и _ServerName_ будут использоваться многократно при определении ядра базы данных и сервера, поддерживающего экземпляр служб Notification Services. Если ваша конфигурация не отличается от указанной, оставьте значения без изменения._InstancePath_ показывает, в какой папке службы Notification Services будут искать файлы ICF. Измените его значение так, чтобы он указывал на папку, в которой мы сохранили проект служб Notification Services.InstanceName, которое в данном примере равно SQL2005StepByStep.SqlServerSystem - это используемый сервер. Обратите внимание на то, что он просто уточняет параметр, определенный выше.Applications содержит список и детали всех приложений, которые зависят от определяемого экземпляра.Application содержит имя приложения, каталог, в котором размещен соответствующий файл DeliveryChannels объявляет доступные каналы и их свойства. В данном сценарии для облегчения восприятия указан только один канал file. Этот канал file требует аргумента в виде физического пути к файлу. Измените путь так, чтобы он соответствовал размещению папки Notifications, которая была создана в действии 6 ранее описанной процедуры "Создаем проект и решение SQL Server 2005 Management Studio".._InstancePath_ и аргумент FileName канала доставки, чтобы они соответствовали путям к файлам в вашей системе. Если вы этого не сделаете, экземпляр служб Notification Services не будет функционировать должным образом.Нажмите кнопку Save (Сохранить), чтобы сохранить файл ICF и не потерять изменения.
Чтобы развернуть и активизировать приложение уведомлений, требуется выполнить определенные действия. Этим действиям следует уделить особое внимание, потому что прежде чем экземпляр служб Notification Services начнет работать, он должен пройти несколько состояний. Если вы хотите, чтобы решение работало, нужно понимать суть выполняемых действий. Вот краткое описание процесса:
Чтобы создать новый экземпляр служб Notification Services (решение), выполните следующие действия:
При помощи следующих действий мы сгенерируем службу Windows, которая будет ожидать входящих событий или запросов для экземпляра служб Notification Services.
Хотя экземпляр служб Notification Services уже создан, он все еще не может обслуживать запросы. Чтобы он начал выполнять свои функции, необходимо включить и запустить экземпляр.
К этому моменту все готово к бесперебойной работе. Можно просмотреть свойства экземпляра, чтобы убедиться в том, что все компоненты включены и/или запущены. Чтобы открыть диалоговое окно Instance Properties (Свойства экземпляра), показанное на следующем рисунке, щелкните правой кнопкой имя экземпляра и выберите из контекстного меню команду Properties (Свойства) (Чтобы убедиться в том, что запустились службы, перейдите на страницу Windows Services (Службы Windows)).
Чтобы протестировать приложение, необходимо запустить событие и проверить, будет ли доставлено соответствующее уведомление.
При каждом изменении содержимого файла
Так же, как при настройке работы экземпляра, при обновлении следует всегда следовать одной и той же процедуре. Обновление - это процесс, обратный установке.
Для обновления экземпляра выполните следующие действия.
К этому моменту мы создали приложение и должны проверить, как оно работает. Для этого мы воспользуемся несколькими простыми сценариями (системными и SQL Server) и выполним действия, описанные в следующих разделах.
В реальном мире мы использовали бы приложение для сбора необходимой информации о подписчиках, выбранных ими устройствах и подписках, которые им интересны. Характер приложения для управления подпиской может быть различным. Можно написать интерфейс, предназначенный специально для процесса управления подписками. В других случаях подписки создаются в результате действий какого-либо другого приложения. Например, если вы создаете решение для обработки информации о клиентах и заказов на книги через интернет, то при установке флажка "Я интересуюсь другими книгами этого автора" в фоновом режиме должна быть сформирована подписка.
Чтобы добавить подписчиков, в нашем примере мы используем несколько файлов VBScript. В реальной системе при использовании API Служб Notification Services выполняется точно такая же операция, как при использовании следующего сценария.
My Documents\MicrosoftPress\SQLAppliedTechSBS\Chapter13 в папку, в которой вы сохраняете проект, следующие файлы:AddSubscribers.vbsAddSubscriptions.vbsViewSubscribersAndDevices.sqlViewSubscriptions.sql.vbs будут помещены в папку Miscellaneous, а файлы .sql - в папку Queries.AddSubscribers.vbs для просмотра, выполнив на нем двойной щелчок в окне Solution Explorer (Обозревателя решений).
AddSubscriptions.vbs.ViewSubscribersAndDevices.sql и запустите его. Если в окне результатов отображаются сведения о подписчиках, то сценарий работает правильно. Обратите внимание, что запрос обращен к представлению, а не к таблице.ViewSubscriptions.sql и выполните его. Если в окне результатов отображаются сведения о подписке, то сценарий работает правильно.Передача событий приложению
Обычно для передачи событий приложению используется один из стандартных поставщиков событий. Вы можете передавать события через модель объекта Event (API объекта событий), упакованными в XML-файлы (XML API), или через предоставляемые хранимые процедуры (API SQL Server).
В нашем примере мы воспользуемся двумя простыми сценариями SQL, которые используют хранимые процедуры API SQL Server.
My Documents\MicrosoftPress\SQLAppliedTechSBS\Chapter13 в папку, в которой вы сохраняете проект, следующие файлы:AddSightEvents.sqlQueries.AddSightEvents.sql для просмотра, выполнив на нем двойной щелчок в окне Solution Explorer (Обозревателя решений). Обратите внимание на то, что события были добавлены при помощи двух хранимых процедур с именами NSEventBeginBatchSightData и NSEventWriteSightData. Первая хранимая процедура запускает пакет событий, а вторая добавляет определенные события. Когда пакет событий завершается, сценарий выполняет хранимую процедуру NSEventFlushBatchSightData, чтобы сообщить службам Notification Services о том, что пакет готов для обработки. Службы Notification Services обрабатывают события пакетом для повышения производительности. Если вы не можете передать пакет, то службы Notification Services могут запуститься, когда события все еще передаются приложению, тем самым снижается эффективность широковещательной рассылки уведомлений и набора функций.EventBatchID и количество событий, полученных приложением. Запишите идентификатор EventBatchID, он понадобится в следующем действии. Если вы в первый раз выполняете этот сценарий, идентификатор EventBatchID будет иметь значение 1. При каждом последующем выполнении значение идентификатора EventBatchID будет увеличиваться.ViewSightEvents. Просмотрите его и измените значение параметра @EventBatchId так, чтобы оно соответствовало идентификатору EventBatchId, который был возвращен в предыдущем действии.EventBatch и информацию о событии.Пока мы наблюдали за событиями, система проверила, существует ли событие, и запустила генерацию уведомления. Службы Notification Services периодически проверяют наличие новых событий и выполняют правило события, которое содержится в SightAlerts. Мы видим, что имя таблицы уведомлений совпадает с именем класса уведомлений, определенного в
Можно проверить, какие уведомления предположительно будут переданы, выполнив следующие действия.
Проверяем уведомления
My Documents\MicrosoftPress\SQLAppliedTechSBS\Chapter13 в папку, в которой вы сохраняете проект, следующий файл:ViewNotifications.sqlQueries.ViewNotifications.sql. В панели Results (Результаты) отобразится состояние уведомлений.После того, как правило события сгенерирует соответствующие записи в таблице уведомлений, в действие вступает еще один процесс, который называется распространителем. Распространитель выполняет две задачи: формирование окончательного форматированного готового к доставке уведомления и передача этого форматированного содержимого действующим модулям доставки. Распространитель использует компонент форматирования содержимого для первой из этих двух задач, а для второй задачи вызывает внешние для решения серверы.
Окончательная форма уведомления формулируется в
Стандартный модуль форматирования XsltFormatter использует три аргумента:
XsltBaseDirectoryPath.XsltFileName.DisableEscaping. Значение по умолчанию для этого аргумента равно false.В нашем примере аргументы, перечисленные выше, соответствуют переменной _AppPath_ для пути к основному каталогу и файлу BirdingTransform.xslt для имени файла XSLT.
Обратите внимание на то, что под записью модуля форматирования содержимого находится запись протокола. Эта запись указывает на определение протокола в ICF.
Просмотрев файл ICF, найдите элемент DeliveryChannel в конце файла. Этот элемент включает элемент ProtocolName, аргумент которого указывает на файл HTML в папке Notifications, которую мы создали в начале этой лекции.
Итак, Распространитель проверяет представления таблицы уведомлений. Здесь он находит информацию об идентификаторе подписчика ( SubscriberID ), канале доставки ( DeliveryChannel ), языковому стандарту подписчика ( SubscriberLocale ), имени устройства ( DeviceName ) и адресе устройства ( DeviceAddress ). С помощью этой информации он может вызвать модуль форматирования, чтобы сформировать "сообщения" уведомлений и скомпоновать вывод для доставки.
Если в качестве канала доставки используется файл, то процесс завершается после того, как файл будет сгенерирован, дальнейшее распространение не требуется.
Вы можете проверить результаты нашего примера, просмотрев их в папке Notification, которую мы создали в папке проекта при настройке инфраструктуры. Здесь вы найдете файл с именем SightNotifications.htm, который должен содержать форматированное уведомление в виде строки.
SightNotifications.htm окажется пустым, убедитесь, что файл BirdingTransform.xslt находится в каталоге проекта в соответствии с инструкциями, которые были даны ранее в этой лекции.Доставка в реальном мире, вероятнее всего, будет гораздо более сложной. Подробное рассмотрение настройки конфигурации сервера в данной книге не предполагается. Однако пример, который мы использовали, обеспечивает хорошую исходную точку для понимания принципов работы служб Notification Services.
В этой лекции рассказывалось об основах настройки и использования приложений уведомлений при помощи компонента SQL Server 2005 Службы Notification Services.
Вы можете продолжить разработку примера, представленного в этой лекции, и добавить режим обработки архивных данных, дополнительные каналы доставки и функции многоязыковой поддержки.
SQL Server – мощная платформа для установки базы данных, которая не только предоставляет базовые функции хранения и извлечения данных. Мы наблюдали, как SQL Server 2005 обеспечивает безопасность, защиту, передачу и сводные данные. Мы также видели, как SQL Server организует и хранит данные, при этом у читателя сложилось определенное понимание принципов оптимизации извлечения данных путем изменения внутренней
| Чтобы | Выполните следующие действия |
|---|---|
| Создать новый проект для служб Notification Services | Создайте специальную базу данных приложения, затем в SQL Server Management Studio выберите из меню File (Файл) команды New, Project (Создать, Проект) и далее выберите в качестве шаблона проекта SQL Server Scripts (Сценарии SQL Server). Добавьте файлы |
| Создать основу приложения служб Notification Services | Определите классы событий, подписок, уведомлений и поставщиков. |
| Развернуть приложение служб Notification Services | Создайте, зарегистрируйте, включите и запустите экземпляр служб Notification Services. |
| Создать экземпляр служб Notification Services | В Object Explorer (Обозревателе объектов) в SQL Server Management Studio щелкните правой кнопкой мыши узел Службы Notification Services и выберите из контекстного меню New Notification Services Instance (Новый экземпляр служб Notification Services). |
| Зарегистрировать экземпляр служб Notification Services | В Object Explorer (Обозревателе объектов) в SQL Server Management Studio разверните узел Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команды Task, Register (Задачи, Зарегистрировать). |
| Включить экземпляр служб Notification Services | В Object Explorer (Обозревателе объектов) в SQL Server Management Studio разверните узел Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команду Enable (Включить). Запустить экземпляр В Object Explorer (Обозревателе объектов) в SQL служб Notification Server Management Studio разверните узел Services Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команду Start (Запустить). |
| Обновить экземпляр служб Notification Services | Остановите и отключите экземпляр; затем в Object Explorer (Обозревателе объектов) в SQL Server Management Studio разверните узел Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команду Update (Обновить). |
В предыдущей лекции вы научились использовать службы Reporting Services, предоставляемые SQL Server. В данной лекции речь пойдет о службах Notification Services, еще одном компоненте SQL Server. Службы Notification Services - мощный компонент SQL Server, который позволяет разработчикам быстро спроектировать, реализовать и развернуть масштабируемое приложение уведомлений. Эти задачи решаются посредством значительной автоматизации двух основных элементов: автоматизации всех процессов, вовлеченных в выполнение решения, и автоматизации создания и управления объектами базы данных и приложения.
Такая автоматизация обеспечивает выигрыш в производительности, но требует, чтобы процесс проектирования отвечал принципу, который службы Notification Services используют для работы с уведомлениями. Это означает, что нужно понимать терминологию, архитектуру и механику платформы. Начальная кривая обучения может показаться непреодолимой, поэтому в данной лекции будет продемонстрировано, как применить принципы служб Notification Services к развитию событий в реальном мире.
Птицландия - воображаемая страна, которая имеет давние традиции в области птицеведения. Птицеведение занимается наблюдением за жизнью птиц в реальных условиях, сбором информации о том, когда птицы прилетают и улетают, выводят птенцов, сколько птиц насчитывается в данной местности и т. д. Птицеведы обычно любят делиться информацией о том, каких птиц, когда и где они наблюдали.
Вы получили запрос на создание приложения уведомлений на заказ. Ваш клиент – Национальное орнитологическое общество Птицландии; ему необходимо уведомлять своих членов о наблюдениях за птицами по всей стране. Заинтересованные люди должны иметь возможность выбрать уведомление о наблюдениях в определенном регионе или в нескольких регионах страны.
Имея под рукой данный сценарий, вы начинаете разрабатывать черновую схему базы данных. Конечно, в реальном мире до того, как перейти к разработке базы данных, вы займетесь списком требований, разработкой схем UML (Unified Modeling Language, универсального языка моделирования) и другими элементами, но для облегчения восприятия материала в данной лекции мы немного сократим этот процесс.
Вероятнее всего, схема включает объекты, показанные в табл. 9.1. Имеет смысл попытаться разработать такое приложение, которое можно было бы использовать повторно в других ситуациях, не имеющих отношения к птицеведению. Следовательно, мы назовем общие объекты родовыми именами, что позволит использовать их повторно, не переписывая общие элементы.
| Объект | Имя |
|---|---|
| Список регионов | Region |
| Список наблюдений | Events |
| Список заинтересованных людей | Subscribers |
| Список регионов, сведения о которых интересуют данное лицо | Subscriptions |
Получается, что три последних имени совпадают с терминами служб Notification Services. Но первый объект, Regions, содержит специфическую для приложения информацию и не совпадает ни с одним из терминов служб Notifications Services.
Наблюдения за птицами делятся на три категории:
Таким образом, наше приложение должно отвечать следующим требованиям:
Эти два требования вызывают необходимость некоторых изменений в схеме приложения. Нам придется отслеживать следующие моменты:
Как обеспечить соответствие этим требованиям?
Управлять архивной информацией несколько сложнее. Необходимо сравнивать дату и время наступления вводимого события с датой и временем последней операции отправки уведомления. Наша схема базы данных не содержит никакой информацией о том, когда отправляются уведомления. Следовательно, нам нужно отслеживать обработку уведомлений.
Для этого можно выбрать одну из двух моделей:
Какую из двух моделей выбрать? Вести запись дат по типам подписки проще, чем по каждой подписке. Первый вариант требует хранения только одной записи для каждого типа подписки. Второй подход требует хранения по одной записи для каждой подписки и некоторой логики для поддержания синхронности обеих таблиц (подписок и процессов). Однако в случае, если уведомление не доставляется, подход по типам не позволит пострадавшему подписчику когда-либо получить уведомление. Этот недостаток может быть допустимым в некоторых не имеющих критической важности приложениях уведомлений, но он будет неприемлемым в другой группе приложений, например, в тех, которые связаны с ожиданием действий со стороны подписчика (необходимость обратного звонка, изменения контракта, жалобы клиента и т. д.). Действительно, даже подписчики, которые подписаны на получение уведомлений, не являющихся критически важными, предпочли бы не пропустить ни одного события. Следовательно, из соображений повторного использования и обеспечения полноты предоста вляемой информации, следует предпочесть второй вариант.
Из-за того, что наше приложение должно отправлять уведомления на различные устройства и носители, возникают некоторые дополнительные требования. Сообщения электронной почты должны доставляться при помощи сервера SMTP, а SMS-сообщения с помощью сервера текстовых сообщений. Кроме того, формат сообщений электронной почты, обычно HTML, не подходит для отправки текстовых сообщений SMS, и наоборот. Следовательно, решение должно уметь отсылать разные байты на различные типы серверов. Это проблема конфигурации, но она имеет некоторое отношение и к архитектуре приложения.
Для реализации этих функций также существует несколько возможностей, от жесткого программирования процесса построения сообщения в приложении до использования программ сторонних разработчиков для обработки процесса преобразования. Службы Notification Services решают эту проблему с учетом открытости системы: для каждого типа устройств необходимо предоставить файл XSLT (eXtensible Stylesheet Language Transformation, преобразования расширяемого языка стилей) (для полноты нужно иметь комбинацию файла XSLT для каждого устройства и языкового стандарта). Механизм XSLT может использовать XSLT-шаблон для преобразования ввода XML в вывод других типов (HTML, XML или текст). Следовательно, это весьма подходящий способ для удовлетворения некоторых требований.
Внутренние процессы приложения будут управлять информацией в модуле подготовки, который не является дружественным к пользователю.
Например, приложение ссылается на все объекты не по имени, а по числу-идентификатору. Однако, при подготовке данных для реальной доставки конечному пользователю, преобразование идентификаторов в текстовую информацию обязательно.
Чтобы ускорить формирование окончательного уведомления для доставки, следует подготовить информацию, которая нужна этому процессу. Например, вместо хранения идентификатора региона следует хранить название региона. Кроме того, вместо идентификатора события следует хранить описание события. Таким образом, когда механизм примет решение отравить уведомление, для получения нужной информации ему не придется выполнять соединения и поиск по нескольким таблицам..Он просто прочитает запись в таблице, в которой все данные подготовлены в соответствии с его требованиями и готовы для отправки подписчику.
Хотя наш клиент мог ничего не сказать о проблемах производительности, нам следует иметь их в виду. Сообщения электронной почты и текстовые сообщения должны доставляться подписчикам в индивидуальном порядке. Известно, что записать строку в таблицу гораздо быстрее, чем отправить сообщение по электронной почте, главным образом, вследствие сетевых задержек. В случае отсылки уведомлений большому количеству подписчиков через короткие промежутки времени может возникнуть узкое место, вследствие чего полезность приложения снизится. Необходимо предусмотреть возможные способы минимизации рабочей нагрузки процесса доставки. У нас есть две возможности ускорить время доставки:
Уменьшить время, необходимое для отправки отдельного сообщения, можно несколькими способами:
Какой бы способ вы не выбрали, время, которое требуется на отправку одного сообщения электронной почты или текстового сообщения, будет зависеть от характеристик сети, которые вы не можете контролировать. Следовательно, следует предпочесть уменьшение количества отправляемых сообщений. Проанализировав характер уведомлений, можно заметить, что многие подписчики разделяют интерес к данному региону, и лишь некоторые подписчики подписались на
К этому моменту мы только собрали информацию о требованиях и начали думать о том, как следует их реализовать. Мы только приступили к работе.
Мы выбрали для разработки этого приложения службы Notification Services. Службы Notification Services помогут ускорить разработку приложения; кроме того, они предлагают платформу для вызова приложения, когда это, в конце концов, потребуется. Следовательно, нужно иметь представление о том, как наши требования преобразуются в объекты службы Notification Services, а также о процессах компоновки, развертывания и тестирования приложений Notification Services.
В следующем разделе данной лекции приводится информация по следующим вопросам::
Теперь, когда вы получили базовые знания о данных, которыми будет управлять приложение, необходимо подумать о том, как должна происходить обработка этих данных. Кроме схемы каждому приложению нужен механизм, чтобы поддерживать работу приложения и работать с данными. В составе механизма решения для уведомлений должны быть реализованы следующие компоненты.
Как передать службам Notification Services информацию, о которой говорилось в предыдущем разделе?
Службы Notification Services используют два конфигурационных XML-файла: конфигурационный файл экземпляра (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.Поскольку количество генерируемых объектов значительно, следует использовать общие базы данных только в определенных обстоятельствах. В нашем примере общие базы данных вполне подойдут, поскольку дополнительная информация, которую мы будем использовать, не может оправдать создание отдельной базы данных. Следовательно, можно создать базу данных приложения и дать указание службам Notification Services дополнить ее своими объектами вместо того, чтобы создавать новую базу данных.
Наш контрольный список требований состоит из следующих пунктов:
К этому моменту мы уже знаем, что приложение служб Notification Services должно включать следующие элементы:
Обратите внимание, что мы ничего не сказали о схемах подписчиков и устройствах подписчиков. Службы Notification Services будут управлять ими и диктовать свою схему. Эта предоставляемая службами схема отвечает нашим требованиям. Однако, если бы она нам не подходила, нам пришлось бы добавить в особую базу данных приложения дополнительные данные и использовать поле SubscriberID в схеме служб Notification Services в качестве
Теперь давайте приступим к созданию нашего приложения. SQL Server Management Studio не включает шаблон для проектов служб Notification Services, хотя можно создать проект для размещения файлов, имеющих отношение к службам Notification Services.
Вместо того, чтобы начинать с нуля, воспользуемся для создания приложения уведомления по птицеводству проектом
Установка примеров (образцов) SQL Server.Далее в материале этой лекции используется пример
Кроме того, можно установить примеры и изучить темы Учебника по службам Notification Services в дополнение к материалам этой лекции.
Хотя службы Notification Services работают со всеми элементами, имеющими отношение к уведомлениям, они не работают со специфическими данными приложения. В сценарии Птицеводство это означает, что службы Notification Services не будут обслуживать информацию о доступных регионах или категориях наблюдений.
Аналогично, службы Notification Services будут содержать минимум данных о самих подписчиках, сохраняя для каждого из них только идентификатор. Если нужно отслеживать информацию о подписчиках, следует подумать о разработке стандартного приложения или использовать решение, основанное на членстве. Идентификатор, хранимый службами Notification Services, представляет собой связь между службами и решением для отслеживания информации о подписчиках.
В нашем примере вы создадите базу данных для хранения всей информации, не специфичной для служб Notification Services. Эта база данных очень простая, но она полезна в качестве примера.
EmptyADF.xml и выберите из контекстного меню команду Rename (Переименовать). Измените имя файла на BirdingADF.xml.Прежде, чем можно будет продолжить работу, требуется сделать несколько базовых определений приложения.
Файл
В терминах служб Notification Services, каждый отличающийся создаваемый тип элемента называется классом, например, класс событий или класс подписки. Каждый класс может содержать более одной таблицы. Классы можно даже разбивать на несколько таблиц и вновь соединять при помощи одного или более представлений, в зависимости от типа класса.
Команды SQL, которые выполняют операции сопоставления или обновления, называются правилами, например, правило событий, правило хроники событий или запланированные правила.
В следующих разделах мы создадим файл
BirdingADF.xml, выполнив двойной щелчок на нем в окне Solution Explorer (Обозреватель решений).Вместо комментария <!-- Replace with EventClasses XML --> введите или вставьте следующий фрагмент XML:
<!- Event Classes ->
<EventClasses>
<EventClass>
<EventClassName>SightData</EventClassName>
<Schema>
<Field>
<FieldName>RegionID</FieldName>
<FieldType>varchar(5)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>Date</FieldName>
<FieldType>datetime</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>Observation</FieldName>
<FieldType>nvarchar(500)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>Category</FieldName>
<FieldType>char(1)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
</Schema>
<IndexSqlSchema>
<SqlStatement>
CREATE INDEX myIndex
ON SightData ( Date );
</SqlStatement>
</IndexSqlSchema>
</EventClass>
</EventClasses>
Обратите внимание на структуру содержимого. Она выглядит как обычное определение схемы базы данных, но выражено при помощи синтаксиса XML. Мы объявляем имя класса событий вместо имени таблицы, затем поля, типы данных, модификаторы для приема нулевых значений и т. д.
Кроме того, при объявлении полей, которые будут формировать SightData, можно включить информацию об индексах, которые, по вашему мнению, полезно будет применить при обращении к таблице правила сопоставления. Таким образом, если известно, что правило сопоставления будет использовать данные столбца RegionID в качестве фильтра либо самостоятельно, либо в предложении JOIN, можно дать указание службам Notification Services создать соответствующие индексы. Это будет полезно в тех случаях, если данные поступают в больших пакетах; это не характерно для примера с Птицландией, поэтому в индексах нет необходимости. Элемент IndexSqlSchema показан просто как напоминание. Дополнительную информацию об использовании индексов для повышения производительности запросов можно найти в лекции 2 "Повышение производительности запроса".
Определение класса подписки.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Subscription Classes —>:
<!— Subscription Classes —>
<SubscriptionClasses>
<SubscriptionClass>
<SubscriptionClassName>SightRegionSubs</SubscriptionClassName>
<Schema>
<Field>
<FieldName>DeviceName</FieldName>
<FieldType>nvarchar(255)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>SubscriberLocale</FieldName>
<FieldType>nvarchar(10)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
<Field>
<FieldName>RegionID</FieldName>
<FieldType>varchar(5)</FieldType>
<FieldTypeMods>not null</FieldTypeMods>
</Field>
</Schema>
<EventRules>
<EventRule>
<RuleName>SightRegionEventRule</RuleName>
<EventClassName>SightData</EventClassName>
<Action>
INSERT INTO SightAlerts(SubscriberId, DeviceName, SubscriberLocale,
Region, Date, Observation, Category)
SELECT s.SubscriberId, s.DeviceName, s.SubscriberLocale,
e.RegionID, e.Date, e.Observation, e.Category
FROM SightData e, SightRegionSubs s
WHERE e.RegionID = s.RegionID;
</Action>
</EventRule>
</EventRules>
</SubscriptionClass>
</SubscriptionClasses>
Объявление схем подписки аналогично объявлению классов событий в предыдущем разделе. Как и в предыдущем случае, мы указываем вместо имени таблицы имя класса подписки, затем имена полей и т. д.
Определение подписки включает один важный объект: правило сопоставления событий. В правиле после класса событий указывается имя, к которому оно относится, а затем инструкция T-SQL, которая задает действующее правило.
Для понимания этого правила нам придется немного забежать вперед. Задача инструкции RULE – вставка записей в таблицу, или класс, уведомлений, который мы еще не определили. Следовательно, ни имя таблицы назначения, ни поля, которые она содержит, нам не известны. Они будут определены ниже при определении класса уведомлений.
Инструкция RULE собирает необходимые столбцы из двух исходных классов: класса событий и класса подписки, а также, что еще более важно, включает ключ для понимания отношения между этими двумя классами. В приведенном выше коде правило сопоставления сопоставляет идентификатор RegionID из класса событий идентификатору RegionID из класса подписки. Таким образом, подписчики получат уведомления, когда будет выполнено наблюдение в регионе, хранящемся в записи о подписке каждого подписчика.
Определение класса уведомлений.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Notification Classes —>:
<!— Notification Classes —>
<NotificationClasses>
<NotificationClass>
<NotificationClassName> SightAlerts </NotificationClassName>
<Schema>
<Fields>
<Field>
<FieldName>Region</FieldName>
<FieldType>nvarchar(35)</FieldType>
</Field>
<Field>
<FieldName>Date</FieldName>
<FieldType>datetime</FieldType>
</Field>
<Field>
<FieldName>Observation</FieldName>
<FieldType>nvarchar(500)</FieldType>
</Field>
<Field>
<FieldName>Category</FieldName>
<FieldType>char(1)</FieldType>
</Field>
</Fields>
</Schema>
<ContentFormatter>
<ClassName>XsltFormatter</ClassName>
<Arguments>
<Argument>
<Name>XsltBaseDirectoryPath</Name>
<Value>%_AppPath_%</Value>
</Argument>
<Argument>
<Name>XsltFileName</Name>
<Value>BirdingTransform.xslt</Value>
</Argument>
</Arguments>
</ContentFormatter>
<Protocols>
<Protocol>
<ProtocolName>File</ProtocolName>
</Protocol>
</Protocols>
</NotificationClass>
</NotificationClasses>
Здесь содержимое схемы класса уведомлений также достаточно понятно, но содержит кое-что неожиданное. В данном случае схеме сопутствует элемент ContentFormatter. Элемент ContentFormatter указывает, какой компонент будет отвечать за формирование уведомления в окончательном виде. Подробнее об этом элементе будет рассказано ниже в разделе "Как скомпоновать сообщение уведомления?"
Определение поставщиков.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Replace with Providers —>:
<!- Providers XML ->
<Providers>
<NonHostedProvider>
<ProviderName>BirdingSPEventProvider</ProviderName>
</NonHostedProvider>
</Providers>
Этот XML-фрагмент показывает, что поступит по маршруту, который находится не под управлением служб Notification Services. Нажмите кнопку Save (Сохранить) на панели инструментов, чтобы сохранить файл BirdingADF.xml, не потеряв изменений.
На следующем этапе необходимо отредактировать ICF-файл. Этот файл представляет собой исходную точку, через которую службы Notification Services будут выполнять синтаксический анализ конфигурационных файлов и осуществлять все необходимые действия. Следовательно, он содержит некоторую основную информацию и данные, специфичные для экземпляра.
Откройте для редактирования файл SQL2005StepByStepICF.xml, выполнив двойной щелчок на файле в окне Solution Explorer (Обозреватель решений). Нужно будет изменить его содержимое так, чтобы оно соответствовало действующей конфигурации компьютера.
DBEngineInstance_ и _ServerName_ будут использоваться многократно при определении ядра базы данных и сервера, поддерживающего экземпляр служб Notification Services. Если ваша конфигурация не отличается от указанной, оставьте значения без изменения._InstancePath_ показывает, в какой папке службы Notification Services будут искать файлы ICF. Измените его значение так, чтобы он указывал на папку, в которой мы сохранили проект служб Notification Services.InstanceName, которое в данном примере равно SQL2005StepByStep.SqlServerSystem - это используемый сервер. Обратите внимание на то, что он просто уточняет параметр, определенный выше.Applications содержит список и детали всех приложений, которые зависят от определяемого экземпляра.Application содержит имя приложения, каталог, в котором размещен соответствующий файл DeliveryChannels объявляет доступные каналы и их свойства. В данном сценарии для облегчения восприятия указан только один канал file. Этот канал file требует аргумента в виде физического пути к файлу. Измените путь так, чтобы он соответствовал размещению папки Notifications, которая была создана в действии 6 ранее описанной процедуры "Создаем проект и решение SQL Server 2005 Management Studio".._InstancePath_ и аргумент FileName канала доставки, чтобы они соответствовали путям к файлам в вашей системе. Если вы этого не сделаете, экземпляр служб Notification Services не будет функционировать должным образом.Нажмите кнопку Save (Сохранить), чтобы сохранить файл ICF и не потерять изменения.
Чтобы развернуть и активизировать приложение уведомлений, требуется выполнить определенные действия. Этим действиям следует уделить особое внимание, потому что прежде чем экземпляр служб Notification Services начнет работать, он должен пройти несколько состояний. Если вы хотите, чтобы решение работало, нужно понимать суть выполняемых действий. Вот краткое описание процесса:
Чтобы создать новый экземпляр служб Notification Services (решение), выполните следующие действия:
При помощи следующих действий мы сгенерируем службу Windows, которая будет ожидать входящих событий или запросов для экземпляра служб Notification Services.
Хотя экземпляр служб Notification Services уже создан, он все еще не может обслуживать запросы. Чтобы он начал выполнять свои функции, необходимо включить и запустить экземпляр.
К этому моменту все готово к бесперебойной работе. Можно просмотреть свойства экземпляра, чтобы убедиться в том, что все компоненты включены и/или запущены. Чтобы открыть диалоговое окно Instance Properties (Свойства экземпляра), показанное на следующем рисунке, щелкните правой кнопкой имя экземпляра и выберите из контекстного меню команду Properties (Свойства) (Чтобы убедиться в том, что запустились службы, перейдите на страницу Windows Services (Службы Windows)).
Чтобы протестировать приложение, необходимо запустить событие и проверить, будет ли доставлено соответствующее уведомление.
При каждом изменении содержимого файла
Так же, как при настройке работы экземпляра, при обновлении следует всегда следовать одной и той же процедуре. Обновление - это процесс, обратный установке.
Для обновления экземпляра выполните следующие действия.
К этому моменту мы создали приложение и должны проверить, как оно работает. Для этого мы воспользуемся несколькими простыми сценариями (системными и SQL Server) и выполним действия, описанные в следующих разделах.
В реальном мире мы использовали бы приложение для сбора необходимой информации о подписчиках, выбранных ими устройствах и подписках, которые им интересны. Характер приложения для управления подпиской может быть различным. Можно написать интерфейс, предназначенный специально для процесса управления подписками. В других случаях подписки создаются в результате действий какого-либо другого приложения. Например, если вы создаете решение для обработки информации о клиентах и заказов на книги через интернет, то при установке флажка "Я интересуюсь другими книгами этого автора" в фоновом режиме должна быть сформирована подписка.
Чтобы добавить подписчиков, в нашем примере мы используем несколько файлов VBScript. В реальной системе при использовании API Служб Notification Services выполняется точно такая же операция, как при использовании следующего сценария.
My Documents\MicrosoftPress\SQLAppliedTechSBS\Chapter13 в папку, в которой вы сохраняете проект, следующие файлы:AddSubscribers.vbsAddSubscriptions.vbsViewSubscribersAndDevices.sqlViewSubscriptions.sql.vbs будут помещены в папку Miscellaneous, а файлы .sql - в папку Queries.AddSubscribers.vbs для просмотра, выполнив на нем двойной щелчок в окне Solution Explorer (Обозревателя решений).AddSubscriptions.vbs.ViewSubscribersAndDevices.sql и запустите его. Если в окне результатов отображаются сведения о подписчиках, то сценарий работает правильно. Обратите внимание, что запрос обращен к представлению, а не к таблице.ViewSubscriptions.sql и выполните его. Если в окне результатов отображаются сведения о подписке, то сценарий работает правильно.Передача событий приложению
Обычно для передачи событий приложению используется один из стандартных поставщиков событий. Вы можете передавать события через модель объекта Event (API объекта событий), упакованными в XML-файлы (XML API), или через предоставляемые хранимые процедуры (API SQL Server).
В нашем примере мы воспользуемся двумя простыми сценариями SQL, которые используют хранимые процедуры API SQL Server.
My Documents\MicrosoftPress\SQLAppliedTechSBS\Chapter13 в папку, в которой вы сохраняете проект, следующие файлы:AddSightEvents.sqlQueries.AddSightEvents.sql для просмотра, выполнив на нем двойной щелчок в окне Solution Explorer (Обозревателя решений). Обратите внимание на то, что события были добавлены при помощи двух хранимых процедур с именами NSEventBeginBatchSightData и NSEventWriteSightData. Первая хранимая процедура запускает пакет событий, а вторая добавляет определенные события. Когда пакет событий завершается, сценарий выполняет хранимую процедуру NSEventFlushBatchSightData, чтобы сообщить службам Notification Services о том, что пакет готов для обработки. Службы Notification Services обрабатывают события пакетом для повышения производительности. Если вы не можете передать пакет, то службы Notification Services могут запуститься, когда события все еще передаются приложению, тем самым снижается эффективность широковещательной рассылки уведомлений и набора функций.EventBatchID и количество событий, полученных приложением. Запишите идентификатор EventBatchID, он понадобится в следующем действии. Если вы в первый раз выполняете этот сценарий, идентификатор EventBatchID будет иметь значение 1. При каждом последующем выполнении значение идентификатора EventBatchID будет увеличиваться.ViewSightEvents. Просмотрите его и измените значение параметра @EventBatchId так, чтобы оно соответствовало идентификатору EventBatchId, который был возвращен в предыдущем действии.EventBatch и информацию о событии.Пока мы наблюдали за событиями, система проверила, существует ли событие, и запустила генерацию уведомления. Службы Notification Services периодически проверяют наличие новых событий и выполняют правило события, которое содержится в SightAlerts. Мы видим, что имя таблицы уведомлений совпадает с именем класса уведомлений, определенного в
Можно проверить, какие уведомления предположительно будут переданы, выполнив следующие действия.
Проверяем уведомления
My Documents\MicrosoftPress\SQLAppliedTechSBS\Chapter13 в папку, в которой вы сохраняете проект, следующий файл:ViewNotifications.sqlQueries.ViewNotifications.sql. В панели Results (Результаты) отобразится состояние уведомлений.После того, как правило события сгенерирует соответствующие записи в таблице уведомлений, в действие вступает еще один процесс, который называется распространителем. Распространитель выполняет две задачи: формирование окончательного форматированного готового к доставке уведомления и передача этого форматированного содержимого действующим модулям доставки. Распространитель использует компонент форматирования содержимого для первой из этих двух задач, а для второй задачи вызывает внешние для решения серверы.
Окончательная форма уведомления формулируется в
Стандартный модуль форматирования XsltFormatter использует три аргумента:
XsltBaseDirectoryPath.XsltFileName.DisableEscaping. Значение по умолчанию для этого аргумента равно false.В нашем примере аргументы, перечисленные выше, соответствуют переменной _AppPath_ для пути к основному каталогу и файлу BirdingTransform.xslt для имени файла XSLT.
Обратите внимание на то, что под записью модуля форматирования содержимого находится запись протокола. Эта запись указывает на определение протокола в ICF.
Просмотрев файл ICF, найдите элемент DeliveryChannel в конце файла. Этот элемент включает элемент ProtocolName, аргумент которого указывает на файл HTML в папке Notifications, которую мы создали в начале этой лекции.
Итак, Распространитель проверяет представления таблицы уведомлений. Здесь он находит информацию об идентификаторе подписчика ( SubscriberID ), канале доставки ( DeliveryChannel ), языковому стандарту подписчика ( SubscriberLocale ), имени устройства ( DeviceName ) и адресе устройства ( DeviceAddress ). С помощью этой информации он может вызвать модуль форматирования, чтобы сформировать "сообщения" уведомлений и скомпоновать вывод для доставки.
Если в качестве канала доставки используется файл, то процесс завершается после того, как файл будет сгенерирован, дальнейшее распространение не требуется.
Вы можете проверить результаты нашего примера, просмотрев их в папке Notification, которую мы создали в папке проекта при настройке инфраструктуры. Здесь вы найдете файл с именем SightNotifications.htm, который должен содержать форматированное уведомление в виде строки.
SightNotifications.htm окажется пустым, убедитесь, что файл BirdingTransform.xslt находится в каталоге проекта в соответствии с инструкциями, которые были даны ранее в этой лекции.Доставка в реальном мире, вероятнее всего, будет гораздо более сложной. Подробное рассмотрение настройки конфигурации сервера в данной книге не предполагается. Однако пример, который мы использовали, обеспечивает хорошую исходную точку для понимания принципов работы служб Notification Services.
В этой лекции рассказывалось об основах настройки и использования приложений уведомлений при помощи компонента SQL Server 2005 Службы Notification Services.
Вы можете продолжить разработку примера, представленного в этой лекции, и добавить режим обработки архивных данных, дополнительные каналы доставки и функции многоязыковой поддержки.
SQL Server – мощная платформа для установки базы данных, которая не только предоставляет базовые функции хранения и извлечения данных. Мы наблюдали, как SQL Server 2005 обеспечивает безопасность, защиту, передачу и сводные данные. Мы также видели, как SQL Server организует и хранит данные, при этом у читателя сложилось определенное понимание принципов оптимизации извлечения данных путем изменения внутренней
| Чтобы | Выполните следующие действия |
|---|---|
| Создать новый проект для служб Notification Services | Создайте специальную базу данных приложения, затем в SQL Server Management Studio выберите из меню File (Файл) команды New, Project (Создать, Проект) и далее выберите в качестве шаблона проекта SQL Server Scripts (Сценарии SQL Server). Добавьте файлы |
| Создать основу приложения служб Notification Services | Определите классы событий, подписок, уведомлений и поставщиков. |
| Развернуть приложение служб Notification Services | Создайте, зарегистрируйте, включите и запустите экземпляр служб Notification Services. |
| Создать экземпляр служб Notification Services | В Object Explorer (Обозревателе объектов) в SQL Server Management Studio щелкните правой кнопкой мыши узел Службы Notification Services и выберите из контекстного меню New Notification Services Instance (Новый экземпляр служб Notification Services). |
| Зарегистрировать экземпляр служб Notification Services | В Object Explorer (Обозревателе объектов) в SQL Server Management Studio разверните узел Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команды Task, Register (Задачи, Зарегистрировать). |
| Включить экземпляр служб Notification Services | В Object Explorer (Обозревателе объектов) в SQL Server Management Studio разверните узел Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команду Enable (Включить). Запустить экземпляр В Object Explorer (Обозревателе объектов) в SQL служб Notification Server Management Studio разверните узел Services Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команду Start (Запустить). |
| Обновить экземпляр служб Notification Services | Остановите и отключите экземпляр; затем в Object Explorer (Обозревателе объектов) в SQL Server Management Studio разверните узел Службы Notification Services, щелкните правой кнопкой мыши экземпляр и выберите из контекстного меню команду Update (Обновить). |
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.