Реализация сервисной шины Flexberry Service Bus RMQ
Исследование интеграции информационных систем. Расчет затрат на разработку продукта. Проектирование Flexberry Service Bus RMQ. Физическая реализация структуры данных. Особенность функционального тестирования. Основная характеристика сервисных шин.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 10.12.2019 |
| Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Пермский филиал федерального государственного автономного образовательного учреждения высшего образования
«Национальный исследовательский университет
Выпускная квалификационная работа
Реализация сервисной шины Flexberry service bus RMQ
Тетерина Светлана Олеговна
Пермь, 2019 год
Аннотация
Тетерина Светлана Олеговна. Реализация сервисной шины Flexberry Service Bus RMQ. Выпускная квалификационная работа.
В работе содержится: стр. 44, ил. 14, табл. 9.
Данная работа описывает процесс разработки и программной реализации модуля Flexberry Service Bus RMQ для системы Flexberry Service Bus, являющейся частью Flexberry Platform - среды, предназначенной для решения бизнес-задач посредством создания программного обеспечения.
Работа содержит описание анализа аналогов, анализ исходной системы и анализ аналогичных систем, также рассмотрены особенности интегрируемого компонента RabbitMQ. Далее представлены этапы выбора стека разработки и программной реализации интеграционного модуля.
Работа будет полезна разработчикам, сталкивающимся с проблемой взаимодействия систем и отдельных компонентов.
С.О. Тетерина - Реализация сервисной шины Flexberry Service Bus RMQ - 2019.
Содержание
Введение
Глава 1. Задача интеграции информационных систем
1.1 Анализ предметной области
1.2 Анализ Flexberry Service Bus
1.3 Анализ существующих решений
1.4 Анализ RabbitMQ
1.5 Вывод по задаче интеграции информационных систем
Глава 2. Технико-экономическое обоснование
2.1 Расчет затрат на разработку продукта
2.2 Расчет стоимостной оценки результата
Глава 3. Проектирование Flexberry Service Bus RMQ
3.1 Диаграмма прецедентов
3.2 Диаграммы активностей
3.3 Результаты проектирования
Глава 4. Реализация системы Flexberry Service Bus RMQ
4.1 Физическая реализация структуры данных
4.2 Функциональное тестирование
4.3 Нагрузочное тестирование
4.4 Результаты реализации, тестирования и внедрения
Заключение
Библиографический список
Введение
Решение многих задач, возникающих при создании современных веб-приложений, в наше время возлагается на веб-сервисы - не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских веб-приложений. Поддержка веб-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске серверов приложений, систем управления базами данных и средств разработки приложений. Таким образом, изменился подход к построению архитектуры программных продуктов, и сервис-ориентированная архитектура стала очень распространена.
Сервис-ориентированная архитектура (SOA, service-oriented architecture) - модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами. Такой подход позволяет легко интегрировать различные компоненты и сервисы, а не создавать каждый раз их с нуля. Большое число разработчиков и интеграторов предлагают инструменты и решения на основе SOA, например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft и т.д [1-2].
Сервисная шина - связующее программное обеспечение, упрощающее вызов службы как для потребителя, так и для поставщика, управляющее всеми сложными взаимодействиями между ними. Шина не только упрощает вызов службы приложениями (или их частями), но и помогает им передавать данные и распространять уведомления о событиях. Такой принцип работы позволяет сохранить вложенные средства в уже существующие информационные системы, а также сэкономить средства на переобучение персонала. Примерами сервисных шин являются Mediator ESB, Oracle Service Bus, IBM WebSphere ESB. Однако, сервисная шина имеет ряд недостатков, например, шина является единой точкой отказа, способной обрушить системы связи всей компании, поэтому большинство современных шин включают в себя брокер сообщений [3-5].
Брокеры сообщений выступают в роли посредника между различными сервисами. Они существенно снижают нагрузку и повышают быстродействие доставки сообщений, т.к. обрабатываемые задачи распределяются между рабочими процессами, предназначенными исключительно для выполнения этих задач. Они обеспечивают надёжный канал передачи сообщений от одного приложения другому. Примерами брокеров сообщений выступают RabbitMQ, ZeroMQ, Apache Kafka.
Однако, брокеры сообщений также имеют серьезный недостаток - разные веб-сервисы тяжело интегрировать из-за различий в языках передачи сообщений. В описанной выше проблеме и состоит актуальность темы исследования. В ходе данной работы предстоит совместить надежность брокера сообщений и простоту подключения и отключения сервисов сервисной шины [6-7].
Существуют как различные сервисные шины, так и различные брокеры сообщений. Также существуют корпоративные сервисные шины, которые являются интеграцией сервисной шины с брокером сообщений. Планируется проанализировать существующие решения и выявить их достоинства и недостатки.
Flexberry Platform - платформа, предоставляющая широкий ряд продуктов для разработчиков, в том числе сервисную шину Flexberry Service Bus. Fexberry - постоянно развивающаяся платформа. В ходе работы была выявлена необходимость интеграции Flexberry Service Bus с брокером сообщений.
Таким образом, объектом работы являются Flexberry Service Bus и RabbitMQ, предметом работы - Реализация Flexberry Service Bus RMQ - реализация на основе брокера сообщений RabbitMQ.
Целью работы является добавление в разрабатываемую систему Flexberry Service Bus поддержку RabbitMQ в стандартной поставке для обеспечения надежности, функциональности и простоты использования.
Для достижения цели необходимо выполнить следующие задачи:
- проанализировать существующие решения и выявить их особенности;
- спроектировать компонент интеграции Flexberry Service Bus и RabbitMQ;
- реализовать поддержку RabbitMQ в стандартной поставке;
- создать тесты и провести тестирование интегрированной системы;
- включить новую версию продукта в дистрибутив.
Гипотеза исследования: можно ожидать, что интеграция Flexberry Service Bus с RabbitMQ повысит надежность и быстродействие системы.
Методы исследования:
- анализ научной литературы;
- изучение принципов объектно-ориентированного моделирования;
- анализ имеющихся решений, построенных на SOA;
- тестирование системы до и после интеграции с RabbitMQ.
Научная новизна состоит в том, чтобы произвести интеграцию уникального продукта - Flexberry Service Bus - с RabbitMQ. Flexberry Service Bus - универсальное средство интеграции систем посредством обмена сообщениями, организация которого построена на принципах корпоративной сервисной шины. Вместо топологии «каждый с каждым» получается топология «хаб», где каждый элемент общей системы соединен с другим посредством центрального хаба, роль которого играет Flexberry Service Bus. Также, Flexberry Service Bus является частью Flexberry Platform и легко может использоваться с другими продуктами платформы для проектирования и написания приложений. Интеграция Flexberry Service Bus с RabbitMQ, как предполагается, позволит повысить надежность и функциональность работы системы, а также, использующих его приложений.
Разрабатываемая система может применяться для связи различных сервисов между собой в самых разнообразных предметных областях и сэкономить деньги и время на разработку. Пользователям также удобнее работать с интегрированными системами, т.к. это позволит экономить время и не вводить данные в каждую систему отдельно.
Структура работы:
- аннотация;
- введение;
- теоретическая глава - анализ предметной области и аналогов разрабатываемой системы;
- практическая глава - проектирование системы, построение диаграмм;
- реализация - реализация и тестирование системы;
- заключение;
- библиографический список;
- приложения - техническое задание, руководства пользователя и программиста, листинг программы.
Глава 1. Задача интеграции информационных систем
В первой главе представлена теоретическая часть исследования.
Рассмотрим особенности сервисной шины и брокера сообщений по отдельности и вместе, а также проанализируем уже существующие решения.
1.1 Анализ предметной области
На сегодняшний день существует множество ИТ-компонентов, функционирующих на различных платформах: mainframe, UNIX, Windows и т.д., зачастую присутствующих в единой корпоративной среде. Этим большим разнообразием чрезвычайно трудно управлять, а его обслуживание становится затруднительным. В лучшем случае, между этими компонентами налажена какая-то связь, которая осуществляется, в основном по мере необходимости между конкретными компонентами. В худшем случае интеграция отсутствует. Может существовать отлаженный механизм взаимодействия определенных компонентов, но не всех компонентов в совокупности.
Сервис-ориентированная архитектура (service-oriented architecture, SOA) представляет собой новый этап эволюции корпоративных систем, направленный на обеспечение интеграции создаваемых и существующих компонентов и минимизации затрат на эту интеграцию. В основном, в качестве основного интегрирующего звена используется корпоративная сервисная шина (Enterprise Service Bus, ESB), реализующая архитектуру SOA (рис. 1.1).
Рисунок 1.1. SOА-архитектура
Использование сервис-ориентированной структуры имеет несколько преимуществ:
- при использовании центральной шины данных, становится возможным избавиться от огромного числа прямых соединений приложений между собой - вместо топологии «каждый с каждым» получается топология «хаб», где каждый элемент общей системы соединен с другим посредством центрального хаба, роль которого играет ESB;
- ESB и SOA позволяют сохранить вложенные средства в уже существующие информационные системы и сэкономить средства на переобучение персонала;
- такой подход позволяет с наименьшими затратами и постепенно планируя, производить подключение существующих и вновь создаваемых информационных систем, подключать модули для дополнительного преобразования информации, поступающей для обмена между системами и производить перенаправление и совершенствование обработки и анализа данных [8].
В рамках SOA приложение должно строиться как набор веб-сервисов со стандартизированным общим интерфейсом, асинхронно взаимодействующих друг с другом. Однако, таким взаимодействием желательно управлять, а кроме того, необходимы удобные механизмы организации передачи сообщений между программными сервисами. Для этого и служит ESB, которая стандартизирует и организует указанные процессы.
В основу синхронизации данных различных информационных систем и баз данных в таком решении положена сервис-ориентированная архитектура и ее основной компонент - корпоративная сервисная шина. Для всех интегрируемых информационных систем, подключаемых к системе, должны быть разработаны специализированные адаптеры, при помощи которых источники данных будут подключены к ESB и смогут обмениваться необходимой информацией в реальном времени.
1.2 Анализ Flexberry Service Bus
Flexberry - это технологическая программная платформа для профессиональной разработки программного обеспечения. Flexberry Service Bus является функциональной подсистемой платформы Flexberry. Flexberry Service Bus - это Open Source решение для интеграции информационных систем, основанное на парадигме Enterprise Service Bus. Данное решение позволяет создавать сложные информационные системы, функционирующие в едином информационном пространстве. В качестве примера можно привести SOA-архитектуру информационной системы, которая в своём основании использует сервисную шину.
Flexberry Service Bus включает в себя следующие компоненты (рис. 1.2):
- сервис шины - осуществляет приём и передачу сообщений, логирует факты передачи данных между клиентами;
- административное приложение шины - позволяет настраивать работу шины и контролировать потоки данных;
- база данных шины - содержит сообщения, ожидающие доставки; настройки шины; статистическую информацию о фактах передачи данных между клиентами;
- адаптеры - клиентская часть компонентов шины, которые специфичны для каждого подключенного к шине приложения [9].
Рисунок 1.2. Компоненты Flexberry Service Bus
Основной задачей Flexberry Service Bus является передача сообщений клиентам, прием сообщений от отправителей и доставка сообщений получателям. Возможности системы включают:
- прием сообщений от клиентов;
- получение сообщений клиентами;
- доставка сообщений клиентам (callback)
- управление потоками сообщений шины;
- взаимодействие через WCF интерфейс;
- взаимодействие через REST интерфейс;
- логирование процесса работы;
- сбор статистики о полученных и переданных сообщениях;
- сжатие накопленной статистики.
Шина принимает сообщения от клиентов имеющих разрешение на передачу сообщений данного типа. При передаче сообщения можно указать приоритет, группу или добавить теги. Для передачи сообщения в шину можно воспользоваться одним из доступных на данный момент интерфейсов, WCF или REST.
Подписавшийся на определенный тип сообщений клиент, может получить имеющиеся в шине сообщения, после получения сообщения клиентов, в шине оно не хранится. При получении сообщения клиент может указать индекс, чтобы получить не первое сообщение в очереди, очередь сообщений сортируется с учетом приоритета и времени получения сообщения. Также можно указать теги которые должно иметь сообщение. Для получения сообщений из шины можно также воспользоваться одним из доступных на данный момент интерфейсов, WCF [10] или REST [11].
При использовании подписки с опцией callback, доставка сообщений выполняется по инициативе шины, на указанный у клиента адрес, выбранным способом.
Для управления потоками сообщений разработано административное приложение, которое позволяет:
- просматривать и редактировать типы сообщений;
- просматривать и редактировать клиентов;
- просматривать и редактировать подписки;
- просматривать и редактировать очередь сообщений;
- просматривать и редактировать настройки ведения и сжатия статистики.
Одним из возможных вариантов взаимодействия с шиной является использование платформы WCF для вызова методов предоставляемых интерфейсом шины. На данный момент этот интерфейс наиболее полно охватывает возможности шины. WCF интерфейс позволяет:
- передавать сообщения в шину;
- получать сообщения из шины;
- подписывать клиентов на типы сообщений.
Еще одним вариантом взаимодействия с шиной является выполнение запросов по протоколу HTTP в стиле REST. REST интерфейс позволяет:
- передавать сообщения в шину;
- получать сообщения из шины.
1.3 Анализ существующих решений
Сервисная шина Mule ESB
Mule - система маршрутизации сообщений, позволяющая обеспечить обмен данными между различными системами. Mule относится к свободному программному обеспечению с открытым кодом, распространяемому по CPAL-лицензии. По сравнению с аналогичными решениями Mule имеет ряд существенных преимуществ:
- возможность связывания компонентов из различных программных сред (framework);
- повторное использовать компонентов;
- компоненты не требуют изменений кода непосредственно под выполнение в Mule, а специфические программные API отсутствуют;
- бизнес-логика полностью отделена от логики обмена сообщениями;
- поддержка любого формата сообщений, например, это может быть сообщение SOAP или даже двоичный образ файла;
- отсутствие ограничений на приложения по архитектуре, например, передача только XML сообщений или организация WSDL-сервисов;
- развертывание в разнообразных топологиях;
- обеспечение безопасности, масштабируемости и адаптивности к изменениям;
- отсутствие протекционизма и блокировок от/на конкретных производителей.
Вне зависимости от технологий, используемых приложениями (JMS, Web-сервисы, JDBC, HTTP и пр.) Mule позволит обеспечить связь между ними, причем не имеет значения, размещены ли они в одной виртуальной машине или распределены в Интернет. Построенная на основе Enterprise Service Bus (ESB) архитектуры данный программный продукт выступает в качестве транзитной системы для «перевозки» данных, что позволяет приложениям, находящимся в интрасети или Интернет связываться друг с другом.
Архитектура Mule позволяет разделить уровень бизнес-логики от транспортного уровня, т.е. обработку полезной составляющей сообщения от его передачи и преобразования, предоставляя таким образом достаточную гибкость в организации архитектуры приложений и упрощая саму настройку бизнес-логики. Имеется возможность разворачивать Mule в различных топологиях, например, иметь несколько экземпляров Mule распределенных по сети. Такой подход полезен на случай отказа, если один экземпляр Mule становится недоступным, другой экземпляр Mule берет на себя его сообщения. Аналогичный подход можно применить для балансировки нагрузки [12].
Сервисная шина Apache ServiceMix
Apache ServiceMix - пакет для создания композитных приложений, базирующийся на концепции Enterprise Service Bus и комбинирующий сервис-ориентированную архитектуру и событийно-ориентированную архитектуру. ServiceMix реализует также спецификацию Java Business Integration (JBI).
Основными функциями сервисной шины Apache ServiceMix являются:
- надежный обмен сообщениями с Apache ActiveMQ;
- шаблоны обмена сообщениями, маршрутизации и интеграции предприятия с Apache Camel;
- веб-сервисы WS? * и RESTful с Apache CXF;
- серверная среда на основе OSGi от Apache Karaf.
Также имеется возможность установить дополнительные пакеты, поддерживающие следующие функции:
- BPM engine через Activiti;
- полная поддержка JPA через Apache OpenJPA;
- управление транзакциями XA через JTA через Apache Aries;
- унаследованная поддержка стандарта JBI (устарела после серии ServiceMix 3.x) через ЯМР Apache ServiceMix, который включает в себя богатый API событий, обмена сообщениями и аудита.
Приложения для ServiceMix могут быть построены с использованием:
- план OSGi;
- OSGi Декларативные услуги;
- Spring DM [13].
Сервисная шина OpenESB
OpenESB - это сервисная шина с открытым исходным кодом. Данный программный продукт можно использовать как платформу для интеграции корпоративных приложений и сервис-ориентированной архитектуры. OpenESB позволяет интегрировать устаревшие системы, внешние и внутренне системы и новые разработки.
Фреймворк состоит из облегченной реализации JBI на Java. Эта реализация не зависит от контейнера и может работать на любой платформе и любом контейнере. В дополнение к тому, что инфраструктура OpenESB легка, она также надежна и легко масштабируется. Система встроена в виртуальную машину Java и взаимодействует с другими экземплярами инфраструктуры через компоненты Binding. Эта архитектура соответствует новым облачным архитектурам и позволяет легко развертывать и управлять в очень сложных инфраструктурах. Каркас полностью управляем с помощью любого инструмента на основе JMX, такого как Jconsole, или более сложных инструментов, таких как Opsview или Nagios.
Платформа реализует виртуальную шину, известную как нормализованный маршрутизатор сообщений (NMR). Это мощный асинхронный интеллектуальный канал связи между компонентами.
Спецификация JBI определяет два типа компонентов: ядро служб (SE) и компонент привязки (BC). SE и BC реализуют один и тот же контракт интерфейса, однако ведут себя по-разному:
- Связующие компоненты действуют как интерфейс между внешней средой и сервисной шиной, являющиеся способными на генерацию данных (сообщений) шины при получении стимулов от внешнего источника или на генерацию внешнего действия/взаимодействия в ответ на сообщение, полученное от сервисной шины.
- Сервисные движки получают сообщения с шины и отправляют сообщения на шину. Движки не имеют прямого контакта с внешним миром. Они полагаются на шину для взаимодействия с другими компонентами, будь то обязательные компоненты или другие сервисные механизмы [14].
Сервисная шина OW2 Petals
Petals ESB - это ESB с открытым исходным кодом. Данный продукт является инструментом для реализации сервис-ориентированной архитектуры (SOA). Он является стандартным, модульным и физически распределенным для адаптации к крупномасштабным инфраструктурам.
Petals ESB основана на отраслевой спецификации JBI (JSR 208). Основанный на стандартах, он также поддерживает стандарты SOA, такие как возможности BPMN и шаблоны корпоративной интеграции.
Инфраструктура фрактального развертывания, подключаемые компоненты JBI и лицензирование с открытым исходным кодом делают его модульным и настраиваемым. Оригинальность Petals заключается в реализации высокораспределенной топологии [14].
1.4 Анализ RabbitMQ
RabbitMQ ? это брокер сообщений. Его основная цель ? принимать и отдавать сообщения. RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.
В RabbitMQ, а также обмене сообщениями в целом, используется следующая терминология:
- Producer ? программа, отправляющая сообщения;
- Queue ? имя очереди. Она существует внутри RabbitMQ. Хотя сообщения проходят через RabbitMQ и приложения, хранятся они только в очередях. Очередь не имеет ограничений на количество сообщений, она может принять сколь угодно большое их количество ? можно считать ее бесконечным буфером. Любое количество поставщиков может отправлять сообщения в одну очередь, также любое количество подписчиков может получать сообщения из одной очереди;
- Consumer ? программа, принимающая сообщения. Обычно подписчик находится в состоянии ожидания сообщений.
Поставщик, подписчик и брокер не обязаны находиться на одной физической машине (обычно они находятся на разных).
Возможное взаимодействие этих трех компонентов представлено на рис. 1.3, где P - Producer (программа-отправитель), Q - Queue (очередь), C - Consumer программа-получатель сообщения).
Рисунок 1.3. Компоненты RabbitMQ
RabbitMQ имеет много возможностей и преимуществ, рассмотрим наиболее важные из них.
Открытый исходный код. Первоначально разработанный в партнёрстве LShift, LTD и Cohesive FT как RabbitMQ Technologies, RabbitMQ теперь находится в собственности Pivotal Software Inc. и выпускается под лицензией Mozilla Public License. Будучи проектом с открытым исходным кодом, написанным на Erlang, RabbitMQ обладает свободой и гибкостью, одновременно используя мощность Pivotal, стоящую за ним как за продуктом. Разработчики и инженеры из сообщества RabbitMQ могут вносить улучшения и дополнения, а Pivotal может предлагать коммерческую поддержку и стабильный дом для постоянного вызревания продукта.
Нейтральность к платформе и производителю. Т.к. брокер сообщений, который реализует нейтральную к платформам и производителям спецификацию Advanced Message Queuing Protocol (AMQP), имеются клиенты, доступные практически для любого языка программирования и на всех основных платформах.
Лёгкий вес. Он является легковесным, требуя менее чем 40 МБ ОЗУ для исполнения центрального ядра приложения RabbitMQ совместно с подключаемыми модулями, такими как UI Управления. Однако, важно отметить, что добавление сообщений в очередь может увеличить потребление памяти и делает это.
Библиотеки клиента для большинства современных языков. Обладая библиотеками клиента, имеющими целью основные современные языки программирования на множестве платформ, RabbitMQ предлагает привлекательный брокер для его программирования. Не существует привязки к какому-либо производителю или языку при выборе того на как вы будете разрабатывать программы, которые будут общаться с RabbitMQ. RabbitMQ предоставляет полезный мост, который делает возможным для таких языков, как Java, Ruby, Python, PHP, JavaScript и C# совместно использовать данные в различных операционных системах и средах.
Гибкость в контроле компромиссов обмена сообщениями. RabbitMQ предоставляет гибкость в контроле необходимых компромиссов надёжности обмена сообщениями с пропускной способностью сообщений и производительностью. Так как нет "одного размера под все" типы приложений, сообщения могут назначать должны ли они сохраняться на диск перед отправкой и, если они настроены в кластере, очереди могут быть настроены на высокую доступность, распространяясь на множество серверов и гарантируя что сообщения не утратятся в случае отказа сервера.
Подключаемые модули для сред с высокой латентностью. Т.к. не все сетевые топологии и архитектуры одинаковы, RabbitMQ предназначается для обмена сообщениями в средах с низкой латентностью, а подключаемые модули для окружений с высокой латентностью, например, для Всемирного интернета.
Подключаемые модули сторонних разработчиков. Как центральный пункт для интеграции приложений, RabbitMQ предоставляет гибкую систему подключаемых модулей (plugin). Например, имеются подключаемые модули сторонних разработчиков для сохранения сообщений непосредственно в базах данных при помощи записей RabbitMQ напрямую в базу данных.
Уровни безопасности. В RabbitMQ безопасность предоставляется на множестве уровней. Клиентские соединения могут быть обеспечены безопасностью усилением взаимодействия только через SSL и удостоверением сертификата клиента. Доступ пользователя может управляться на уровне виртуального хоста, предоставляя изоляцию сообщений и ресурсов на высоком уровне. Кроме того, доступ к возможностям настройки, чтение из очередей и запись в обмен управляются соответствиями шаблонов регулярных выражений (regex). Наконец, для интеграции с внешними системами аутентификации, такими как LDAP, могут применяться подключаемые модули [15].
Многие достоинства RabbitMQ, включая его гибкость, проистекают из спецификации AMQP. В отличии от таких протоколов как HTTP и SMTP, спецификация AMQP определяет не только некий сетевой протокол, но также и службы и поведение стороны сервера.
Существует три абстрактных компонента в программном обеспечении брокера, которые определяют поведение маршрутизации сообщений:
- Exchange (Обмен): Этот компонент брокера обмена сообщениями осуществляет маршрутизацию сообщений в очереди;
- Queue (очередь): структура данных на диске или в оперативной памяти, которая сохраняет сообщения;
- Binding (связывание): некое правило, которое сообщает имеющемуся обмену в какой из очередей эти сообщения должны сохраняться.
Гибкость 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 |
ServiceMix |
Open ESB |
PEtALS |
|
|
Поддержка функциональности ЕСБ ядра |
2 |
2 |
2 |
2 |
|
|
Хорошо написанная документация |
2 |
1 |
2 |
1 |
|
|
Распространенность на рынке |
3 |
2 |
1 |
1 |
|
|
Сообщество активных разработчиков и поддержка |
3 |
2 |
1 |
2 |
|
|
Гибкая и легко расширяемая логика построения продуктов |
3 |
2 |
1 |
2 |
|
|
Поддержка широкого спектра транспортных протоколов и настроек соединения |
2 |
2 |
1 |
2 |
|
|
Интеграция с другими Open source проектами |
3 |
3 |
1 |
2 |
|
|
Поддержка разработки решений через IDE |
2 |
2 |
3 |
2 |
Наиболее значимыми критериями являются критерий распространенности на рынке и критерий сообщества активных разработчиков. Как видно из таблицы, наилучшие показатели по этим критериям у сервисной шины Mule. При анализе таблицы был сделан вывод, что на высокие показатели этих критериев больше всего повлияли высокие показатели по критериям гибкости и расширяемости логики и интеграции с другими open source проектами. Эти моменты стоит учесть при разработке сервисной шины Flexberry.
Глава 2. Технико-экономическое обоснование
Цель главы - произвести анализ, расчет, оценку экономической целесообразности реализации предлагаемой системы. Технико-экономическое обоснование основано на сопоставительной оценке затрат и результатов, полученных в процессе проектирования и реализации.
2.1 Расчет затрат на разработку продукта
Разработкой системы занимается команда ресурсно-технологического отдела компании ООО «Новая Платформа». Оценим трудоёмкость разработки по методу экспертных оценок. В качестве экспертов выступили инженеры-программисты компании ООО «Новая платформа» (табл. 2.1):
Таблица 2.1. Трудоёмкость разработки
|
№ |
Функция/Работа |
Эксперт № |
Оптимистичная оценка, час. |
Реалистичная оценка, час. |
Пессимистичная оценка, час. |
|
|
Проектирование компонента |
1 |
6 |
8 |
10 |
||
|
2 |
7 |
8 |
9 |
|||
|
3 |
8 |
10 |
12 |
|||
|
Получение сообщений |
1 |
16 |
21 |
27 |
||
|
2 |
16 |
22 |
30 |
|||
|
3 |
21 |
24 |
27 |
|||
|
Отправка сообщений; |
1 |
15 |
20 |
25 |
||
|
2 |
12 |
16 |
20 |
|||
|
3 |
19 |
22 |
25 |
|||
|
Подписка на получение определенного типа сообщений; |
1 |
10 |
14 |
18 |
||
|
2 |
14 |
16 |
18 |
|||
|
3 |
14 |
18 |
22 |
|||
|
Сбор статистики |
1 |
15 |
19 |
25 |
||
|
2 |
19 |
22 |
24 |
|||
|
3 |
16 |
20 |
24 |
|||
|
Конвертер сообщений |
1 |
8 |
14 |
18 |
||
|
2 |
10 |
16 |
22 |
|||
|
3 |
10 |
14 |
20 |
|||
|
Логирование |
1 |
8 |
10 |
12 |
||
|
2 |
10 |
14 |
18 |
|||
|
3 |
11 |
13 |
15 |
|||
|
Редактирование и настройка тестовых приложений для проведения нового тестирования |
1 |
6 |
8 |
12 |
||
|
2 |
7 |
8 |
9 |
|||
|
3 |
7 |
9 |
11 |
|||
|
Тестирование |
1 |
8 |
14 |
17 |
||
|
2 |
10 |
14 |
18 |
|||
|
3 |
11 |
14 |
17 |
|||
|
Отладка |
1 |
12 |
16 |
18 |
||
|
2 |
15 |
18 |
21 |
|||
|
3 |
17 |
21 |
25 |
|||
|
Повторное тестирование |
1 |
8 |
14 |
17 |
||
|
2 |
10 |
14 |
18 |
|||
|
3 |
11 |
14 |
17 |
|||
|
Внедрение |
1 |
8 |
12 |
16 |
||
|
2 |
10 |
12 |
14 |
|||
|
3 |
8 |
12 |
16 |
Средняя оценка эксперта по компоненте программной системы определяется по формуле (1):
,
где k - индекс (номер) эксперта;
i - индекс (номер) программного компонента/работы;
о - оптимистическая оценка;
r - реалистичная оценка;
p - пессимистическая оценка.
Таким образом, получаем следующие оценки (табл. 2.2):
Таблица 2.2. Средние оценки экспертов
|
№ |
Функция/Работа |
Эксперт № |
Средняя оценка, час. |
|
|
Проектирование компонента |
1 |
8 |
||
|
2 |
8 |
|||
|
3 |
10 |
|||
|
Получение сообщений |
1 |
21,2 |
||
|
2 |
22,3 |
|||
|
3 |
24 |
|||
|
Отправка сообщений; |
1 |
20 |
||
|
2 |
16 |
|||
|
3 |
22 |
|||
|
Подписка на получение определенного типа сообщений; |
1 |
14 |
||
|
2 |
16 |
|||
|
3 |
18 |
|||
|
Сбор статистики |
1 |
19,3 |
||
|
2 |
21,8 |
|||
|
3 |
20 |
|||
|
Конвертер сообщений |
1 |
13,7 |
||
|
2 |
16 |
|||
|
3 |
14,3 |
|||
|
Логирование |
1 |
10 |
||
|
2 |
14 |
|||
|
3 |
13 |
|||
|
Редактирование и настройка тестовых приложений для проведения нового тестирования |
1 |
8,3 |
||
|
2 |
8 |
|||
|
3 |
9 |
|||
|
Тестирование |
1 |
13,5 |
||
|
2 |
14 |
|||
|
3 |
14 |
|||
|
Отладка |
1 |
15,7 |
||
|
2 |
18 |
|||
|
3 |
21 |
|||
|
Повторное тестирование |
1 |
13,5 |
||
|
2 |
14 |
|||
|
3 |
14 |
|||
|
Внедрение |
1 |
12 |
||
|
2 |
12 |
|||
|
3 |
12 |
Результирующая оценка трудоемкости рассчитывается по формуле (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. Выбор конфигурации
|
Действия акторов |
Отклик системы |
|
|
Клиент прописывает в конфигурации системы желаемый интерфейс для обработки сообщений (Flexberry Service Bus или Rabbit MQ) |
Система записывает выбранную конфигурацию в базу данных шины |
Название: Отправка сообщения
Акторы: Клиент
Краткое описание: Клиент отправляет сообщение в шину
Триггер: Клиент инициирует отправку сообщения
Основной поток см. в табл. 3.2.
Таблица 3.2. Отправка сообщения
|
Действия акторов |
Отклик системы |
|
|
Клиент инициирует отправку сообщения |
Система проверяет есть ли у данного клиента права отправлять запрашиваемый тип сообщений. При положительном варианте, система конвертирует сообщение для передачи RabbitMQ и передает его |
Название: Прием сообщения
Акторы: Клиент
Краткое описание: Клиент получает сообщение из шины
Триггер: Шина получает новое сообщение
Основной поток представлен в табл. 3.3.
Таблица 3.3. Прием сообщения
|
Действия акторов |
Отклик системы |
|
|
Клиент отправляет сообщение |
Система проверяет наличие подписок на данных тип сообщения. При наличии подписки хотя бы у одного клиента, система получает от RabbitMQ сообщение, конвертирует его для передачи клиенту и передает |
|
|
Клиент получает сообщение |
Система получает подтверждение отправки. После получения сообщения всеми подписанными клиентами, сообщение удаляется из базы данных шины |
Название: Управление подписками клиентов
Акторы: Клиент
Краткое описание: Клиент подписывается или отписывается от типа сообщений
Триггер: Клиент подписывается или отписывается от типа сообщений
Основной поток представлен в табл. 3.4.
Таблица 3.4. Управление подписками клиентов
|
Действия акторов |
Отклик системы |
|
|
Клиент подписывается на тип сообщений, используя административное приложение шины |
Система добавляет соответствующую запись в базу данных шины |
|
|
Клиент отписывается от типа сообщений, используя административное приложение шины |
Система добавляет соответствующую запись в базу данных шины |
3.2 Диаграммы активностей
Функция отправки сообщения клиентом выглядит следующим образом (см. рис. 3.5):
Рисунок 3.5. Отправка сообщения
Как видно из рисунка, клиент инициирует отправку сообщения, после чего система проверяет есть ли у клиента-отправителя разрешение на отправку данного типа сообщений. В случае, если разрешение есть, система конвертирует сообщение в тип, принимаемый Rabbit MQ, и передает его. После чего Rabbit MQ принимает сообщение и добавляет запись об этом в лог.
Функция приема сообщений (см рис. 3.6):
Рисунок 3.6. Прием сообщения
Чтобы получить сообщение, клиент должен быть подписан на прием данного типа сообщений. При получении нового сообщения система проверяет, есть ли клиенты с действительной подпиской на полученный тип сообщения. Для найденных клиентов собирается информация о количестве сообщений, которые ожидают передачи клиенту, затем передаются сами сообщения. После получения подтверждения о том, что клиент получил сообщение, это сообщение удаляется из базы данных шины.
3.3 Результаты проектирования
В ходе текущей главы был спроектирован компонент интеграции Flexberry Service Bus и Rabbit MQ. На диаграмме компонентов показано его место в имеющейся системе. С помощью диаграммы прецедентов были определены функции и роли акторов в системе. Для моделирования бизнес-процессов были построены диаграммы активностей.
Глава 4. Реализация системы Flexberry Service Bus RMQ
4.1 Физическая реализация структуры данных
Система реализована в среде разработки Microsoft Visual Studio с поддержкой баз данных Microsoft SQL Server, PostgresSQL на языке программирования C#.
Для интеграции с RabbitMQ создан пакет NewPlatform.Flexberry.ServiceBus.RabbitMQ с реализацией следующих компонентов:
- ReceivingManager - позволяет получать сообщения хранящиеся в RabbitMQ привычным для клиентов Flexberry Service Bus способом
- SendingManager - позволяет отправлять сообщения в RabbitMQ привычным для клиентов Flexberry Service Bus способом
- StatisticsService - собирает статистику сообщений RabbitMQ и преобразует ее в статистику Flexberry Service Bus
- SubscriptionsManager - позволяет управлять маршрутизацией сообщений в RabbitMQ
- SubscriptionsSynchronizer - актуализирует настройки маршрутизации сообщений в RabbitMQ
- MessageConverter - преобразует сообщения в формат Flexberry Service Bus
- MessageManager - позволяет управлять сообщениями хранящимися в RabbitMQ
Полученную в результате реализации диаграмму классов (см. рис. 4.1):
Рисунок 4.1. Диаграмма классов
Классы IMessageConverter и RmqMessageConverter используются для конвертирования сообщения шины в формат, принимаемый RabbitMQ. IMessageManager и RmqMessageManager содержат методы для управления сообщениями в RabbitMQ (возвращение сообщений из RabbitMQ и их количества, конвертер сообщений из формата RabbitMQ в формат Flexberry Service Bus, удаление сообщений из очереди). Класс RmqReceivingManager служит для приема сообщений из сервисной шины в RabbitMQ. Класс RmqConsumer следит за подписками клиента и определяет, когда послать ему сообщение. RmqSendingManager - класс для доставки сообщений из RabbitMQ. RmqStatisticsCollector собирает статистику из RabbitMQ. RmqSubscriptionsManager - класс работы с объектами маршрутизации RMQ. Класс RmqSubscriptionSynchronizer - класс для синхронизации подписок в RabbitMQ и шине Flexberry Service Bus. AmqpNamingManager используется для перевода наименований объектов маршрутизации шины и наименований объектов в AMQP (Advanced Message Queuing Protocol). В классе Queue задается формат сообщения очереди.
4.2 Функциональное тестирование
В целях проверки реализуемости функциональных требований системы проведем функциональное тестирование (табл. 4.1) [17].
Таблица 4.1. Функциональное тестирование
|
№ теста |
Действие |
Ожидаемый результат |
Полученный результат |
-/+ |
|
|
1 |
Отправить сообщение, на тип которого никто не подписан |
Ни один из клиентов не получил сообщения |
Ни один из клиентов не получил сообщения |
+ |
|
|
2 |
Отправить сообщение, на тип которого подписан один клиент |
Подписанный клиент получил сообщение |
Подписанный клиент получил сообщение |
+ |
|
|
3 |
Отправить сообщение, на тип которого подписано несколько клиентов |
Подписанные клиенты получили сообщение |
Подписанные клиенты получили сообщение |
+ |
|
|
4 |
Отправить сообщение, на тип которого подписан один клиент с опцией callback |
Подписанный клиент получил сообщение |
Подписанный клиент получил сообщение |
+ |
|
|
5 |
Отправить сообщение, на тип которого подписано несколько клиентов с опцией callback |
Подписанные клиенты получили сообщение |
Подписанные клиенты получили сообщение |
+ |
|
|
6 |
Отправить сообщение, на тип которого подписано несколько клиентов с разными типами подписок |
Подписанные клиенты получили сообщение |
Подписанные клиенты получили сообщение |
+ |
|
|
7 |
Подписаться на тип сообщений |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
8 |
Подписаться на тип сообщений с опцией callback |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
9 |
Получить сообщение с просроченной подпиской |
Сообщение не доставлено |
Сообщение не доставлено |
+ |
|
|
10 |
Получить сообщение с просроченной подпиской с опцией callback |
Сообщение не доставлено |
Сообщение не доставлено |
+ |
|
|
11 |
Оформить подписку на тип сообщений с взаимодействием через WCF интерфейс |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
12 |
Получить сообщение для клиента с подпиской с взаимодействием через WCF интерфейс |
Подписанный клиент получил сообщение |
Подписанный клиент получил сообщение |
+ |
|
|
13 |
Оформить подписку на тип сообщений с взаимодействием через REST интерфейс |
Клиент подписан на тип сообщений |
Клиент подписан на тип сообщений |
+ |
|
|
14 |
Получить сообщение для клиента с подпиской с взаимодействием через REST интерфейс |
Подписанный клиент получил сообщение |
Ошибка |
- |
|
|
15 |
Отправить сообщение. Запустить клиента с подпиской на данный тип сообщения |
Клиент получил все сообщения, которые были отправлены до запуска работы клиента |
Клиент получил все сообщения, которые были отправлены до запуска работы клиента |
+ |
|
|
16 |
Отправить сообщение. Запустить клиента с подпиской на данный тип сообщения с опцией callback |
Клиент не получил сообщений. При последующей отправке с запущенным клиентом сообщения приходят |
Клиент не получил сообщений. При последующей отправке с запущенным клиентом сообщения приходят |
+ |
|
|
17 |
Запустить клиента с действительной подпиской, не отправляя никаких сообщений в шину |
Клиент запущен, сообщений не получено |
Ошибка |
- |
|
|
18 |
Запустить клиента с действительной подпиской с функцией callback, не отправляя никаких сообщений в шину |
Клиент запущен, сообщений не получено |
Клиент запущен, сообщений не получено |
+ |
|
|
19 |
Отправить сообщение из приложения клиента-отправителя, отключить питание, включить, запустить приложение клиента-получателя |
Сообщение доставлено, несмотря на «сбой» |
Сообщение доставлено, несмотря на «сбой» |
+ |
Как видно из таблицы, два случая не прошли тестирование (тесты №14 и №17). Следовательно, предстоит отладить работу с REST интерфейсом и баг с запуском клиента без сообщений.
Тестирование проводилось с учетом того, что в конфигурации сервисной шины Flexberry Service Bus выбрана передача сообщений через RabbitMQ.
4.3 Нагрузочное тестирование
Для исследования времени отклика системы в зависимости от нагрузки проведем нагрузочное тестирование. Для проведения тестирования воспользуемся средствами тестирования среды Microsoft Visual Studio 2017, а именно шаблоном пошаговой нагрузки.
Зададим следующие настройки:
- начальное число пользователей: 100;
- максимальное число пользователей: 2000;
- длительность шага (секунд): 1800;
- время увеличения шага (секунд): 20;
- число пользователей на шаге: 100.
Для тестирования будем использовать одного клиента-отправителя и пошагово добавлять клиентов-получателей.
Результаты тестирования представлены на диаграмме (см. рис. 4.2):
Как видно из диаграммы, уровень отклика (уведомления о получении клиентом-получателем сообщения от клиента-отправителя) резко возрос по достижении семисот клиентов-получателей. Однако на протяжении всего тестирования время отклика не превышает одной секунды, что удовлетворяет требованиям к системе.
Рисунок 4.2. Нагрузочное тестирование Flexberry Service Bus RMQ
Если сравнивать время отклика полученной системы со старой версией Flexberry Service Bus (рис.4.3), т.е. без использования RabbitMQ, видно, что конфигурация RabbitMQ нагружает систему немного больше.
Рисунок 4.3. Нагрузочное тестирование Flexberry Service Bus
Дополнительная нагрузка на систему обусловлена тем, что использование RabbitMQ требует дополнительного времени, чтобы записывать данные в базу данных брокера сообщений, тогда как в варианте конфигурации без RabbitMQ данные записываются только в базу данных сервиса шины.
4.4 Результаты реализации, тестирования и внедрения
В ходе главы была реализована система Flexberry Service Bus RMQ. Изменения затронули один компонент, как и было заявлено требованиями. Было проведено функциональное и нагрузочное тестирование, которое показало улучшение отказоустойчивости системы.
Несмотря на то, что время отклика системы без использования конфигурации RabbitMQ ниже, использование этой конфигурации дает преимущества в плане надежности системы. Использование дополнительной базы данных RabbitMQ позволяет сохранить непереданные сообщения, и в случае непредвиденного сбоя (отключения любого из клиентов, либо отказа самой шины) передать сообщения после восстановление работоспособности компонента. Тестирование Flexberry Service Bus без конфигурации RabbitMQ показало, что в случае сбоя, непереданные сообщения теряются.
Система введена в эксплуатацию и доступна посредством docker-образа. После обновления Flexberry Service Bus можно запускать как с использованием RabbitMQ, так и без. Подробнее об этом в руководстве программиста (см. прил. Б).
Заключение
В ходе работы была проанализирована предметная область, а именно назначение и принцип работы сервисных шин. В процессе анализа теоретической части исследования было решено спроектировать и реализовать модуль Flexberry Service Bus RMQ для системы Flexberry Service Bus, входящей в состав Flexberry Platform. Следуя функциональным требованиям и учитывая структуру уже имеющейся системы, была построена модель TO-BE. Было написано техническое задание (см. прил. А) и технико-экономическое обоснование.
Был реализован модуль Flexberry Service Bus RMQ с помощью языка программирования C#. Работа функций системы была протестирована на тестовых приложениях: клиенте-отправителе и клиентах с разными видами подписок. Тестирование показало повышении надежности системы и, также, выявило наличие ошибки при использовании одного из типов подписок. Обновленная система доступна для использования в виде docker-образа.
Подобные документы
Спецификация организации службы Short Message Service. Алгоритм работы сервера и возможность расширения функциональных возможностей. Реализация проекта на языке высокого уровня С++ на платформе Linux. Расчет себестоимости и цены программного продукта.
дипломная работа [168,6 K], добавлен 19.01.2014Концептуальное проектирование базы данных. Выделение информационных объектов. Выходная и входная информация. Алгоритмы реализации отчетов и сервисных процедур. Создание структуры таблиц. Проектирование форм и отчетов. Реализация сервисных процедур.
курсовая работа [2,7 M], добавлен 28.01.2016Характеристика предметной области. Проведение исследования функциональных требований к системе. Проектирование структуры хранения данных. Программирование функциональной структуры. Реализация программного средства. Особенность тестирования программы.
курсовая работа [632,0 K], добавлен 23.02.2023Концептуальное проектирование базы данных. Характеристика предметной области. Выходная и входная информация. Выделение информационных объектов. Алгоритмы реализации отчетов и сервисных процедур. Реализация базы данных. Создание структуры таблиц и отчетов.
курсовая работа [2,0 M], добавлен 12.03.2016Реализация приложения "Книжный магазин" средствами систем управления базами данных. Проектирование структуры базы данных, определение сущности и атрибутов. Логическое проектирование базы данных и реализация базы данных в СУБД Microsoft Office Access.
курсовая работа [7,8 M], добавлен 13.02.2023Значение Информационных технологий. Традиционные проблемы взаимодействия. Принципы организации и возможности автоматизированной Диспетчерской службы. Основные преимущества компьютеризированной реализации службы Service Desk. Классификация, учет обращений.
лекция [2,0 M], добавлен 04.12.2014Понятие, модели и назначение информационных систем. Функциональное моделирование ИС. Диаграмма потоков данных. Декомпозиция процессов и миниспецификации. Реализация макета системы средствами MS SQL Server 2005. Создание базы данных. Скалярные функции.
курсовая работа [1,0 M], добавлен 16.09.2012Опис специфічних просторів імен, класів, функцій, використаних при роботі з системними процесами. Створення Windows service та клієнта-програми до неї, що виводить діючі курси валют (купівлі\продажу долара, євро та рубля) деяких банків в режимі онлайн.
курсовая работа [659,1 K], добавлен 21.04.2015Рассмотрение взаимосвязи информационных подсистем предприятия. Характеристика сервис-ориентированной архитектуры информационных систем. Оценка реализации SOA-инфраструктуры на базе сервисной шины предприятия. Анализ бизнес-цели внедрения SOA-решений.
контрольная работа [1,0 M], добавлен 28.03.2018Необходимость программы "Мониторинг" для службы Service Desk в АО "Алюминий Казахстана". Обработка заявок в службе Service Desk по установке программного обеспечения, покупке и замене офисной техники и расходных материалов. Управление уровнем сервиса.
курсовая работа [3,4 M], добавлен 23.02.2015
