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

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

Рисунок 3.3 – Фора «Создать диалог»

На первом этапе создания нового диалога необходимо задать тип сообщений (Message type name), определяющий имя сообщения (AUTHORIZATION owner name) и проверку (VALIDATION), выполняемую Service Broker для сообщений с этим именем (рисунок 3.4).

Рисунок 3.4 – Форма «Создать новое сообщение»

Данная форма заменяет SQL-команды, применяемые в Service Broker для создания нового типа сообщения. Листинг 3.1 содержит код создания нового типа сообщений в Service Broker.

CREATE MESSAGE TYPE "Request msg"

VALIDATION = NONE

CREATE MESSAGE TYPE "Response msg"

VALIDATION = NONE

Листинг 3.1 – Создание нового типа сообщения

Выбрать один конкретный параметр проверки из группы пользователю позволяет элемент RadioButton. При подведении курсора к соответствующему элементу появляется всплывающая подсказка, вызванная элементом ToolTip, которая отображает информацию об интересующем объекте (рисунок 3.5).

Рисунок 3.5 – Всплывающая подсказка

Аргументы, используемые для создания нового типа сообщения:

1. Message type name.

Имя создаваемого типа сообщений. Создается новый тип сообщений в текущей базе данных, которой владеет участник, указанный в предложении AUTHORIZATION. Не могут быть указаны имена сервера, базы данных и схемы. Аргумент message_type_name может иметь длину не более 128 символов.

1. AUTHORIZATION owner_name.

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

1. VALIDATION.

Указывает, как компонент Компонент Service Broker производит проверку текста сообщения этого типа.

• NONE: указывает, что проверка не выполняется;

• EMPTY: указывает, что текст сообщения должен быть NULL;

• WELL FORMED XML: указывает, что текст сообщения должен содержать корректные XML-данные;

• VALID XML WITH SCHEMA COLLECTION: указывает, что текст сообщения должен содержать XML-данные, которые соответствуют схеме в указанной коллекции схем.

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

Рисунок 3.6 – Форма «Создать новый контракт»

Данная форма заменяет SQL-команды, применяемые в Service Broker для создания нового контракта. Листинг 3.2 содержит код создания нового контракта в Service Broker.

CREATE CONTRACT "Contract"

( "Request msg" SENT BY INITIATOR,

"Response msg" SENT BY TARGET )

Листинг 3.2 – Создание нового контракта

Аргументы, используемые для создания нового контракта:

1. Contract name.

Имя создаваемого контракта. Новый контракт создается в текущей базе данных и передается во владение участнику, указанному в предложении AUTHORIZATION. Не могут быть указаны имена сервера, базы данных и схемы. Параметр contract_name может иметь длину не более 128 символов.

1. AUTHORIZATION owner name.

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

1. Message type name.

Имя типа сообщений, включаемого в качестве части контракта.

1. SENT BY.

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

• INITIATOR: указывает на то, что только инициатор диалога может посылать сообщения определенного типа. Служба, которая начинает диалог, называется инициатором сеанса связи.

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

• ANY: указывает на то, что сообщения этого типа могут посылаться как инициатором, так и целью.

1. [ DEFAULT ].

Указывает на то, что данный контракт поддерживает сообщения с установленным по умолчанию типом сообщений. По умолчанию во всех базах данных содержится тип сообщений с названием DEFAULT. Этот тип данных использует проверку типа NONE. В контексте данного предложения DEFAULT не является ключевым словом и должен быть отделен как идентификатор. Microsoft SQL Server также предоставляет контракт DEFAULT, указывающий тип сообщения DEFAULT.

После того, как определены соответствующие типы сообщений и контракты, необходимо создать очереди, в которых полученные сообщения будут сохраняться для дальнейшей обработки с помощью сервисной программы. Также необходимо указать сведения о хранимых процедурах, которые нужно активировать, чтобы начать обработку сообщений в этой очереди. Чтобы определить максимальное количество экземпляров хранимой процедуры активации, запускаемых очередью одновременно, был использован элемент DomainUpDown, который отображает единичное строковое значение, выбранное пользователем из списка элементов с помощью кнопок «вверх-вниз» элемента управления (рисунок 3.7).

Рисунок 3.7 – «Создать новую очередь»

Данная форма заменяет SQL-команды, применяемые в Service Broker для создания новой очереди. Листинг 3.3 содержит код создания новой очереди в Service Broker.

CREATE QUEUE InitiatorQueue

WITH

STATUS = ON,

RETENTION = ON,

ACTIVATION

(STATUS = ON,

PROCEDURE_NAME = procedure_name,

MAX_QUEUE_READERS = max_queue_readers

EXECUTE AS = OWNER )

ON filegroup

CREATE QUEUE TargetQueue

WITH

STATUS = ON

RETENTION = ON

ACTIVATION

(STATUS = ON

PROCEDURE_NAME = procedure_name

MAX_QUEUE_READERS = max_queue_readers

EXECUTE AS = OWNER )

ON filegroup

Листинг 3.3 – Создание новой очереди

Аргументы, используемые для создания новой очереди:

1. STATUS (очередь).

Указывает, доступна очередь (ON) или нет (OFF). Когда очередь недоступна, нельзя ни добавлять в нее сообщения, ни удалять их из нее. Можно создать очередь в состоянии недоступности, чтобы сообщения не поступали в очередь до тех пор, пока очередь не будет сделана доступной с помощью инструкции ALTER QUEUE. Если это предложение опущено, значение по умолчанию равно ON, и очередь доступна.

1. RETENTION.

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

1. ACTIVATION.

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

• STATUS (активация): указывает, запускает ли компонент Компонент Service Broker хранимую процедуру. Если параметр STATUS = ON, то очередь запускает хранимую процедуру, указанную параметром PROCEDURE_NAME. Если количество выполняемых в настоящий момент хранимых процедур меньше, чем значение MAX_QUEUE_READERS, и если сообщения прибывают в очередь быстрее, чем хранимые процедуры получают сообщения. Если параметр STATUS = OFF, то очередь не активирует хранимую процедуру. Если это предложение не указано, значение по умолчанию равно ON.

• PROCEDURE NAME: указывает имя хранимой процедуры, которая должна быть активирована для обработки сообщений в данной очереди. Это значение должно являться идентификатором SQL Server.

• MAX QUEUE READERS: определяет максимальное количество экземпляров хранимой процедуры активации, запускаемых очередью одновременно. Значение аргумента max_readers должно быть числом от 0 до 32767.

• EXECUTE AS: указывает учетную запись пользователя базы данных SQL Server, от имени которого выполняется хранимая процедура активации. SQL Server должен быть в состоянии проверить разрешения для пользователя, когда очередь запускает хранимую процедуру. SELF указывает, что хранимая процедура выполняется как текущий пользователь. OWNER указывает, что хранимая процедура выполняется в контексте владельца очереди. 'user name' имя пользователя, от имени которого выполняется хранимая процедура. Аргумент user name должен быть именем допустимого пользователя SQL Server, указанным в виде идентификатора SQL Server.

1. ON filegroup / [DEFAULT].

Указывает файловую группу SQL Server, на основании которой должна создаваться эта очередь. Можно использовать аргумент filegroup для идентификации файловой группы или идентификатор DEFAULT, чтобы использовать файловую группу по умолчанию для базы данных компонента Service Broker. В контексте данного предложения слово DEFAULT не является ключевым словом и должно быть отделено как идентификатор. Если файловая группа не задана, то очередь использует файловую группу по умолчанию для базы данных.

3.3 Редактирование и удаление диалога

Для того чтобы редактировать диалог было использовано дерево папок, которое представляет собой объект класса TreeView, в который программным образом загружается иерархическая файловая структура носителей информации Базы данных. Дерево файлов обеспечивает быстрый доступ к отдельным объектам файловой системы. Корнем дерева служит компонент «Service» (рисунок 3.8).

Рисунок 3.8 – Форма «Редактировать диалог»

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

Рисунок 3.9 – Форма «Удалить сообщение»

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

3.4 Структура и состав программной оболочки

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

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