Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Последовательность очень важна, когда приемник получает несколько сообщений, каждое из которых зависит от предыдущего. Для сохранения порядка Service Broker включает в себя порядковый номер каждого отправленного сообщения и заставляет принимающее приложение получать сообщения в том же порядке, как они были отправлены. Другие системы обмена сообщениями (например MSMQ) принимают сообщения в любом порядке, но Service Broker обеспечивает соблюдение строгой последовательности. Начиная с SQL Server 2008, Service Broker включает в себя поддержку приоритетов. Эта функция позволяет расставить приоритеты сообщений и упорядочить сообщения самостоятельно в требующейся последовательности.

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

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

2. Организация и функционирование сервисов обмена сообщениями в Service Broker

2.1 Компоненты Service Broker

Служба Service Broker состоит из следующих четырех объектов:

• типы сообщений;

• контракты;

• очередь;

• сервисная программа.

Типы сообщений, контракты и очередь реализуются как собственные объекты SQL Server, в то время как сервисная программа может быть реализована, как хранимая процедура или как отдельное приложение. На рисунке 2.1 показана взаимосвязь между четырьмя объектами.

Рисунок 2.1 – Взаимосвязь объектов компонента Service Broker

При создании новой службы Service Broker необходимо создать и настроить все эти объекты.

Компонент Service Broker обеспечивает постановку в очередь и надежный обмен сообщениями для SQL Server. Service Broker используется как в приложениях с единственным экземпляром SQL Server, так и в приложениях, распределяющих работу между несколькими экземплярами. Внутри одного экземпляра SQL Server компонент Service Broker обеспечивает устойчивую к ошибкам асинхронную модель программирования. Компонент Service Broker также обеспечивает надежный обмен сообщениями между экземплярами SQL Server, помогая разработчикам составлять приложения из независимых, самодостаточных компонентов, которые называются службами [3].

Service Broker поддерживает следующие размещения служб:

• обе службы размещены в одной базе данных SQL Server;

• службы размещены в разных базах данных SQL Server, расположенных в одном экземпляре SQL;

• каждая служба размещена в отдельной базе данных SQL Server, расположенной на разных экземплярах SQL.

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

• XML Validate;

• XML;

• No validation (например, для двоичных данных);

• Empty (тело сообщения остается пустым).

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

Рисунок 2.2 – Проверка сообщений в Service Broker

Контракт определяет, какие типы сообщений Service Broker использует для выполнения конкретной задачи (рисунок 2.3). Контракт представляет собой соглашение между двумя сервисами, с помощью которого две конечные точки диалога обмениваются сообщениями. Необходимо создать контракт в каждой базе данных, участвующей в разговоре. Открыв контракт, можно легко определить какие типы сообщений могут быть получены и отправлены в данном диалоге.

Рисунок 2.3 – Контракт в Service Broker

Service Broker также гарантирует, что будут доставлены и обработаны только те типы сообщений, которые определены в контракте. Если отправлено сообщение, принадлежащее типу не указанному в контракте, то сообщение не будет доставлено, а инициатору придет сообщение об ошибке. Контракт также определяет направления отправки сообщений:

• от инициатора к цели;

• от цели к инициатору;

• в обе стороны.

В Service Broker очередь является объектом для хранения принятых сообщений, которые должны быть обработаны. Очереди должны быть определены как для инициатора, так и для получателя сообщений. После успешной проверки полученное сообщение помещается в целевую очередь. Очередь представляет собой таблицу, каждая строка которой является сообщением. Строка содержит информацию о сообщение, например, тип, дата получения, приоритет и контракт, к которому принадлежит сообщение [27].

Когда сообщение обрабатывается, Service Broker считывает сообщение непосредственно из очереди и выполняет необходимую работу над сообщением. Когда работа выполнена, обработанное сообщение удаляется из очереди.

Service Broker представляет очереди в виде скрытых таблиц, которые выглядят как обычные таблицы SQL Server, но использовать стандартные команды для работы с данными очереди (например, такими как INSERT, DELETE и UPDATE) невозможно. Чтобы увидеть, какие сообщения в настоящее время хранятся в очереди можно использовать команду SELECT.

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

Маршрут представляет собой объект SQL Server, который содержит информацию о нахождении службы и базы данных, в которой она определена. Маршрут необходим для доставки сообщения. По умолчанию каждая база данных содержит маршрут, который указывает расположение текущего экземпляра SQL Server.

2.2 Процесс обмена сообщениям как основа диалога

Основной задачей Service Broker является отправка и получение сообщений, которые содержат данные для выполнения той или иной задачи и являются частью разговора. Разговор представляет собой передачу сообщений между конечными точками: инициатором и целью.

Компонент Service Broker определяет два вида разговоров:

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

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

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

• гарантированную доставку сообщения;

• неограниченный срок службы;

• исключение дублирования сообщений;

• очередность обмена сообщениями;

• техническое обслуживание.

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

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

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

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

Диалог Service Broker легко справляется с перезагрузкой всего сервера, потому что сообщения и диалоги сохраняются непосредственно в базе данных. Это облегчает процесс технического обслуживания. Все открытые диалоги и необработанные сообщения сохраняются автоматически и становятся доступны, как только произойдет подключение к базе данных.

На рисунке 2.4 представлен диалог Service Broker.

Рисунок 2.4 – Диалог Service Broker

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

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

Группы взаимодействия – способ группировки всех диалогов, связанных с определённой задачей. К примеру, все транзакции, необходимые для решения конкретной задачи, можно логически объединить в одну группу взаимодействия. Эта группа будет иметь собственный идентификатор, содержащий все сообщения во всех диалогах, составляющих группу.

Основным назначением группы взаимодействия является реализация механизма блокировки для связанных сообщений, обеспечивающего параллельное обращение нескольких программ к одной и той же очереди. Блокировка используется для поддержания порядка сообщений и управления состояниями всех диалогов в группе. Это значит, что когда в каком-либо диалоге группы приходит сообщение, вся группа блокируется для выполнения транзакции его получения. За время жизни транзакции только один поток, устанавливающий блокировку, может получать сообщения от любого из диалогов группы взаимодействия [9].

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

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

Когда покупатель размещает заказ, необходимо зафиксировать транзакцию:

• в системах учета товаров;

• в системе бухгалтерского учета;

• в службе доставки;

• в системе операций с кредитными картами.

Затем клиент должен отправить подтверждение заказа через другое Web-приложение. Ожидание завершения каждого из этих процессов в синхронном режиме отрицательно скажется на масштабируемости.

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

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

Характеристики

Список файлов ВКР