Дипломная работа: Реализация сервисной шины Flexberry Service Bus RMQ

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

Первым фрагментов информации, необходимым RabbitMQ для осуществления маршрутизации в надлежащее местоположение является некий обмен для выполнения по нему маршрута. Exchange получает сообщения, отправляемые в RabbitMQ и определяет куда они были направлены. Обмен определяет необходимое поведение маршрутизации, которое следует применять к сообщениям, обычно исследуя атрибуты данных, передаваемых с самим этим сообщением или которые содержатся в свойствах такого сообщения. Очередь (queue) отвечает за хранение полученных сообщений и может содержать информацию настроек, которая определяет, что можно делать с этим сообщением. Некая очередь может держать сообщения только в оперативной памяти, либо может сохранять их на диск, прежде чем доставлять их в порядке первый- пришедший первым- и уходит (FIFO, first-in, first-out). Для определения взаимодействия между очередями определяются binding (связывания). В RabbitMQ связывания, или binding keys (ключи связывания) сообщают некоторому обмену в какую из очередей доставлять сообщение. Для некоторых типов обмена определяемое связывание также указывает обмену фильтрацию того какие сообщения оно может доставлять в некую очередь. При публикации некоторого сообщения в каком- то обмене приложения применяют атрибут routing-key (ключ маршрутизации). Это может быть название очереди либо это может быть строка, которая семантически описывает подходящее сообщение. Когда обмен сообщение для определения маршрутизации необходимых очередей, такой ключ маршрутизации сообщения вычисляется для ключа связывания.

1.5 Вывод по задаче интеграции информационных систем

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

Была проанализирована система Flexberry Service Bus, ее компоненты, функциональные возможности, а также рассмотрены особенности интегрируемого компонента RabbitMQ.

В результате анализа аналоговых систем выявлены наиболее значимые критерии и проведено сравнение. Краткое сравнение по критериям вышеописанных сервисных шин см. в табл. 1.1. Все значения находятся в пределе от 1 до 3, где больше - лучше.

Таблица 1.1. Сравнение сервисных шин

Наиболее значимыми критериями являются критерий распространенности на рынке и критерий сообщества активных разработчиков. Как видно из таблицы, наилучшие показатели по этим критериям у сервисной шины Mule. При анализе таблицы был сделан вывод, что на высокие показатели этих критериев больше всего повлияли высокие показатели по критериям гибкости и расширяемости логики и интеграции с другими open source проектами. Эти моменты стоит учесть при разработке сервисной шины Flexberry.

Глава 2. Технико-экономическое обоснование

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

2.1 Расчет затрат на разработку продукта

Разработкой системы занимается команда ресурсно-технологического отдела компании ООО «Новая Платформа». Оценим трудоёмкость разработки по методу экспертных оценок. В качестве экспертов выступили инженеры-программисты компании ООО «Новая платформа» (табл. 2.1):

Таблица 2.1. Трудоёмкость разработки

Средняя оценка эксперта по компоненте программной системы определяется по формуле (1):

,

где k - индекс (номер) эксперта;

i - индекс (номер) программного компонента/работы;

о - оптимистическая оценка;

r - реалистичная оценка;

p - пессимистическая оценка.

Таким образом, получаем следующие оценки (табл. 2.2):

Таблица 2.2. Средние оценки экспертов

Результирующая оценка трудоемкости рассчитывается по формуле (2):

,

где k - индекс (номер) эксперта;

L - количество экспертов;

i - индекс (номер) программного компонента/работы;

N - число программных компонентов/работ в программной системе;

- средняя оценка эксперта по компоненте программной системы.

Получаем (3): информационный тестирование сервисный шина

= = 180,2ч.

Средняя заработная плата разработчика-программиста по Пермскому краю составляет 64 516 р/мес. [16]. Таким образом, затраты на разработку системы составляют (4):

= 180,2ч.*=72 661,145р.

Затраты на сопровождение и адаптацию в месяц равны месячным заработным платам сотрудников ресурсно-технологического отдела (примерно 420 000р).

2.2 Расчет стоимостной оценки результата

Прирост прибыли осуществляется за счет продажи лицензий на сервисную шину Flexberry Service Bus и последующей разработки адаптеров клиентов и поддержки системы. Прибыль рассчитывается по формуле (5):

,

где - стоимость лицензии;

- стоимость услуг по внедрению, разработке адаптеров и поддержке;

k - количество заказов;

C - затраты на разработку системы;

- затраты на сопровождение и адаптацию в месяц;

n - количество месяцев, прошедших после выпуска системы.

В среднем, стоимость лицензии составляет 100 000р, услуги по внедрению, разработке адаптеров и поддержке - около 800 000р.

Таким образом, прибыль за полгода с условием трех заказов составит (6):

П=(100 000р+800 000р)*3-(72 661р+420 000р*6мес)=107 339р.

Прибыль с учетом ставки на прибыль (18%) составит 88 018р.

Таким образом, разработка и поддержка системы окупятся за полгода при хотя бы трех заказах на лицензию и ее сопровождение.

Глава 3. Проектирование Flexberry Service Bus RMQ

Во второй главе представлены основные этапы проектирования Flexberry Service Bus RMQ. В ходе проектирования будут представлены диаграммы прецедентов, активностей UML.

Как было указано в главе 1.2, Flexberry Service Bus включает в себя следующие компоненты: сервис шины, административное приложение шины, базу данных шины и адаптеры. Следует отметить, что Flexberry Service Bus RMQ - название лишь разрабатываемого модуля, а не всей сервисной шины Flexberry Service Bus. Изменения должны коснуться компонента сервиса шины, отвечающего за передачу сообщений. Работу этого компонента в настоящий момент можно представить следующим образом (рис. 3.1.):

Рисунок 3.1. Модель AS-IS

Диаграмма компонентов имеющейся системы (см. рис. 3.2):

Рисунок 3.2. Диаграмма компонентов Flexberry Service Bus

На диаграмме отражены основные элементы Flexberry Service Bus, а также элементы клиента шины. В систему Flexberry Service Bus входит административное приложение, состоящее из отдельных frontend и backend приложений, база данных, содержащая сообщения, ожидающие доставки, настройки шины, статистическую информацию о фактах передачи данных между клиентами, а также сам сервис шины, в которую входят компоненты, содержащие понятия о клиентах, типах сообщений и т.л., обеспечивающие передачу и получение сообщений клиентами, компоненты для тестирования системы.

Исходя из анализа предметной области и выявленных требований к системе, была построена модель TO-BE (см. рис. 3.3).

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

Рисунок 3.3. Модель TO-BE

Изменения должны быть добавлены в новый компонент Flexberry.ServiceBus.RabbitMQ, его местоположение на диаграмме компонентов (см. рис. 3.4):

Рисунок 3.4. Диаграмма компонентов Flexberry Service Bus RabbitMQ

Как видно из диаграммы, компонент Flexberry.ServiceBus.RabbitMQ входит в кластер компонентов сервиса шины, не затрагивая другие компоненты, что обеспечит минимизацию проблем при обновлении со старой версии системы и облегчит тестирование.

3.1 Диаграмма прецедентов

Чтобы ознакомиться с работой системы рассмотрим диаграмму прецедентов (рис. 3.5):

Рисунок 3.4. Диаграмма прецедентов

Название: Выбор конфигурации

Акторы: Клиент

Краткое описание: Клиент выбирает интерфейс для обработки сообщений (Flexberry Service Bus или Rabbit MQ)

Триггер: Настройка конфигурации клиента

Основной поток представлен в табл. 3.1.

Таблица 3.1. Выбор конфигурации

Название: Отправка сообщения

Акторы: Клиент

Краткое описание: Клиент отправляет сообщение в шину

Триггер: Клиент инициирует отправку сообщения

Основной поток см. в табл. 3.2.