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

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

Рисунок 2.5 – Процесс блокировки группы взаимодействия

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

В Service Broker последовательность и взаимосвязь сообщений обеспечивается с помощью порядковых номеров. Как только инициатор посылает сообщение, ему присваивается текущий порядковый номер, в соответствие с которым пользователь на принимающей стороне будет получать сообщения и извлекать их из очереди (рисунок 2.6).

Рисунок 2.6 – Порядок отправки сообщений в Service Broker

Если по какой-то причине сообщение не было доставлено, отправитель повторно посылает сообщение до тех пор, пока не придет подтверждение от получателя о доставленном сообщении.

На рисунке 2.7 показано, как сообщения, отправляемые по сети, помещаются во временную очередь, называемой очередью передачи.

Рисунок 2.7 – Надежный обмен сообщениями в Service Broker

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

Рассмотрим подробнее процесс обмена сообщениями между сервисами. На рисунке 2.8 представлена диаграмма кооперации, которая показывает этапы диалога.

Рисунок 2.8 – Диаграмма кооперации

Контракт включает в себя два типа сообщений: Сообщение-запрос (RequestMessage) и сообщение-ответ (ResponseMessage). Для начала диалога контракт и оба типа сообщения должны быть созданы в каждой базе данных SQL Server. На стороне отправителя необходимо создать очередь инициатора (InitiatorQueue). Точно также, на стороне цели создается очередь получателя (TargetQueue). После создания и настройки этих объектов необходимо выполнить ряд действий для того, чтобы отправить сообщение от сервиса инициатора (InitiatorService) к сервису получателя (TargetService) [46].

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

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

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

На четвертом этапе сообщение-запрос извлекается из очереди и обрабатывается получателем.

Пятый этап предполагает написание сообщения-ответа для сервиса инициатора.

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

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

Восьмой шаг предполагает обработку ответного сообщения сервисной программой и информирование клиента о результатах его запроса.

2.3 Обеспечение безопасности диалога

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

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

Service Broker обеспечивает два различных типа безопасности: безопасность транспорта и безопасность диалога.

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

Безопасность диалога шифрует сообщения в отдельных диалогах и проверяет подлинность участников диалога. Безопасность диалога также предусматривает удаленную авторизацию и выполняет проверку сообщения на целостность. Устанавливает подтвержденную шифрованную связь между двумя службами Service Broker [48].

На рисунке 2.9 представлена схема транспортной безопасности и безопасности диалога Service Broker.

Рисунок 2.9 – Схема транспортной безопасности и безопасности диалога

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

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

Если используется обеспечение безопасности диалога, компонент Service Broker шифрует все сообщения, отправляемые за пределы экземпляра SQL Server. Сообщения, не покидающие экземпляр SQL Server, никогда не шифруются. При обеспечении безопасности диалога доступ к соответствующим сертификатам нужен только базам данных, являющимся узлами службы-инициатора и целевой службы. Это означает, что экземпляр, выполняющий пересылку сообщений, вполне может не поддерживать возможность дешифрования пересылаемых сообщений [11].

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

1. механизм полного обеспечения безопасности;

2. механизм анонимного обеспечения безопасности.

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

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

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

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

3 Файловый менеджер манипулирования сервисами обмена сообщениями

3.1 Последовательность создания элементов

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

Рисунок 3.1 – Граф зависимости объектов в Service Broker

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

Следовательно, чтобы начать диалог необходимо выполнить действия в следующем порядке:

• создать типы сообщений, определяющие данные, которые будут передаваться в рамках диалога;

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

• создать очереди, которые будут хранить входящие сообщения для сервера;

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

3.2 Создание диалога

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

Файловая система разработана в среде Microsoft Visual Studio 2012 и объединяет только самые нужные для пользователя функции по работе с компонентом Service Broker в наглядном и простом виде.

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

Рисунок 3.2 – Главное окно «Начать диалог»

Следующая форма файловой системы позволяет начать новый диалог или продолжить уже существующий. Для того чтобы продолжить диалог, необходимо выбрать связанные с ним объекты. Для этого используется элемент управления ComboBox, который отображает редактируемое текстовое поле и раскрывающийся список допустимых значений (рисунок 3.3).

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

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