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

Текст из файла

Содержание

Введение 3

1 Использование SODA для организации асинхронной обработки данных. 6

1.1 Назначение и описание SOA и SODA архитектур 6

1.2 Преимущества использования технологии обмена сообщениями 10

1.3 Обзор технологий обмена сообщениями доступных, для Windows 14

1.4 Проблемы, возникающие при использовании технологии обмена сообщениями и их решение с помощью Service Broker 17

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

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

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

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

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

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

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

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

Заключение 54

Список используемых источников 55

Приложение А. Графический материал 59

Введение

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

Одна из подобных архитектур – сервис-ориентированная архитектура баз данных (SODA) за последние годы стала стандартом де-факто для разрабатываемых приложений. Ядром SODA является промежуточные агенты – сообщения, посредством которых приложения обмениваются компонентами баз данных, и встроенный в систему управления базы данных сервис, отвечающий за надёжную приемку и отправку сообщений и характеризующий согласованность и непротиворечивость баз данных подвергающихся модификации и (или) использованию.

В составе MS SQL за развертывание и реализацию SODA отвечает специальный компонент – Service Broker. Service Broker выполняет множество посреднических функций, в том числе: автоматически управляет порядком сообщений, уникальностью доставки и идентификацией сеансов. После установления сеанса между двумя сервисами, приложение принимает каждое сообщение только раз в порядке отправки. Тем не менее, Service Broker зачастую остается незамеченным разработчиками и администраторами баз данных. Причина тому сложность настройки компонента. Чтобы его использовать, необходимо предварительно создать системные объекты, обеспечивающие процесс обмена сообщениями.

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

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

Объектом изучения и последующего использования является компонент Service Broker.

Предметом проектирования, соответственно, файловый менеджер сервисов обмена сообщениями в Service Broker.

Цель данной работы – разработка файлового менеджера, предназначенного для ускоренного создания экземпляров объектов Service Broker, такие как: сообщения, контракты, очереди и сервисы.

Исходя из обозначенной цели, поставлены следующие задачи:

• Описать преимущества и выявить проблемы связанные с использования технологии обмена сообщениями

• Изучить организацию и функционирование сервисов обмена сообщениями в Service Broker.

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

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

Практическая значимость разработки файлового менеджера в сокращении времени на создание системных объектов Service Broker .

1 Использование SODA для организации асинхронной обработки данных.

1. Назначение и описание SOA и SODA архитектур

Внедрение технологии обмена сообщениями ведет к появлению новых архитектур приложений, посредством использования которых можно решать задачи, недоступные для клиент/сервер или трехуровневых архитектур. Рассмотрим два возможных типа архитектуры технологии обмена сообщениями: Сервис-ориентированную архитектуру (SOA) и сервис-ориентированную архитектуру базы данных (SODA).

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

После нескольких десятилетий развития широкого спектра систем с использованием различных технологий и платформ, появилось много систем, которые хорошо выполняли свою работу, но совершенно не могли взаимодействовать друг с другом во все более взаимосвязанной среде. Было крайне сложно добиться обеспечения производительности кроссплатформенных современных приложений. Очевидно, что системы, которые отвечают потребностям сегодняшнего глобального взаимодействия, требуют архитектуру, которая эффективно использует унаследованные системы и обеспечивает гибкую инфраструктуру обмена данными [37].

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

SOA (Service Oriented Architecture) – концепция сервис-ориентированной архитектуры, предназначенная для решения вопросов интеграции информационной инфраструктуры компании за счет построения архитектуры, позволяющей интегрировать с максимальной гибкостью разнородные приложения [36].

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

• сервисы являются полностью автономными приложениями;

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

• сервисы независимы от языка программирования и операционной системы;

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

• интероперабельность – то есть способность взаимодействовать с другими системами без каких-либо ограничений доступа;

• повторное использование.

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

Рисунок 1.1 показывает некоторые из объектов, которые могут входить в состав слабосвязанного приложения на основе SOA . Клиент-серверная служба, которая может быть клиентским приложением, серверным приложением, таким как веб-сервер, или любым другим приложением, отправляет сообщение провайдеру услуг. В комплексных системах, маршрутизатор может сначала получить сообщение и, применив некоторую логику, перенаправить запрос к соответствующему поставщику услуг. Тогда поставщик услуг будет получать сообщение, распаковывать и редактировать его, делать всю необходимую работу над сообщением, а затем отправлять ответное сообщение потребителю услуг.

Рисунок 1.1 – Объекты слабосвязанного приложения на основе SOA

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

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

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

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

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

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

Сервис-ориентированная архитектура баз данных (SODA) – развитие архитектуры SOA. Теперь база данных является также хранилищем сообщений, промежуточных состояний, метаинформации об очередях сообщений и сервисах [35].

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

Все версии СУБД SQL Server, начиная с 2005, предлагают ряд новых функций, в том числе, следующие:

• интеграция в .NET (SQLCLR);

• уведомления о запросах;

• Service Broker;

• поддержка XML;

• поддержка веб-служб.

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

1.2 Преимущества использования технологии обмена сообщениями

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

Сообщение состоит из трех частей:

• оболочка;

• заголовок;

• тело сообщения.

Оболочка сообщения это «конверт», в котором передаются «заголовок» и «тело» сообщения. «Заголовок» сообщения содержит информацию о маршрутизации, такую как существующие посредники на маршруте, конечный пункт назначения, отправитель, приоритет, и так далее. «Тело» сообщения сохраняет полезную нагрузку, которая передается от отправителя к получателю. Тело может быть в любом формате, например в виде двоичных данных, данных XML или даже текстовые данные (например, в сообщении электронной почты) [46].

Преимущества использования технологии обмена сообщениями:

• асинхронная обработка сообщений;

• отложенная обработка сообщений;

• отказоустойчивость;

• распределенные системы.

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

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

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

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

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

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

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