Пермский филиал федерального государственного автономного образовательного учреждения высшего образования
«Национальный исследовательский университет
Выпускная квалификационная работа
Реализация сервисной шины 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.