MSSQL 2005 (Yukon) – работа с очередями и асинхронная обработка данных
Категория реферата: Рефераты по информатике, программированию
Теги реферата: реферат биография, скачать на телефон шпаргалки
Добавил(а) на сайт: Kozin.
Предыдущая страница реферата | 1 2 3 4 5 6 7 8 9 10 11 | Следующая страница реферата
MESSAGE TYPE (тип сообщения): Любое сообщение должно быть ассоциировано с определенным типом. Это метка, которая передается вместе с сообщением и позволяет получателю понять, какого типа сообщение к нему приехало. По желанию, если сообщение представляет собой XML, то метка может быть ассоциирована с произвольной XML-схемой. В этом случае при получении производится проверка соответствия сообщения этой схеме, и если сообщение проверку не проходит, то оно отвергается.
CONTRACT (контракт): Контракт – это набор типов сообщений, при этом для каждого типа сообщения в контракте указывается, кому из участников диалога сообщение данного типа может принадлежать: отправителю, получателю или им обоим. Каждый диалог обязательно ассоциируется с контрактом. Иными словами, если тип сообщения не соответствует ни одному типу из контракта, ассоциированного с диалогом, то передать такое сообщение по этому диалогу не получится.
SERVICE (сервис): Сервис связывает несколько контрактов с очередью. Имя сервиса является синонимом для конечной точки диалога. Таким образом, контракт определяет, сообщения каких типов могут быть посланы через очередь посредством диалога, а сервис является конечной точкой, через которую сообщение попадает в очередь.
Схематично, весь этот зоопарк можно изобразить примерно следующим образом:
Отправитель и получатель – достаточно условные понятия, они имеют смысл только на этапе создания канала общения. После того, как канал создан, сообщения могут свободно гулять в обоих направлениях. Иными словами, отправитель – это та сторона, которая создает диалог. При этом само создание диалога не вызывает создания физического канала связи, канал создается лишь в тот момент, когда необходимо доставить первое сообщение, и удерживается до тех пор, пока диалог не завершится.
Через сервис отправителя сообщение попадает в очередь отправителя, если соответствует одному из типов сообщения, упомянутых в контракте. После этого оно передается в очередь получателя, где при получении также проходит проверку, после чего забирается оттуда собственно получателем. Если же получатель желает как-то ответить, то он в свою очередь формирует сообщение и отправляет его через свой сервис, и оно путешествует обратно тем же манером.
Теперь самое время приступить к практическим экспериментам. Для начала создадим все необходимые объекты:
|
-- тип сообщения, просто текст, для простоты безо всяких проверок и xml -- CREATE MESSAGE TYPE [TestType] VALIDATION = NONE -- теперь можно создать контракт, разрешающий сообщения этого типа -- для любой из сторон -- CREATE CONTRACT [TestContract] ([TestType] SENT BY ANY) -- для отправляющей стороны необходимо создать очередь -- и сервис на основе этой очереди -- CREATE QUEUE [SourceQueue] CREATE SERVICE [SourceService] ON QUEUE [SourceQueue] -- Для принимающей стороны так же нужно создать принимающую очередь -- и принимающий сервис, причем принимающий сервис обязательно -- должен иметь контракт, хотя для отправляющего это не обязательно -- CREATE QUEUE [TargetQueue] Рекомендуем скачать другие рефераты по теме: рефераты на казахском языке, реферат на тему время. Предыдущая страница реферата | 1 2 3 4 5 6 7 8 9 10 11 | Следующая страница реферата Поделитесь этой записью или добавьте в закладкиКатегории: |