En

JazzTeam Software Development Company

Agile Java Development

Платформа для создания продуктов на базе сервис-ориентированной архитектуры

Описание проекта: для одного из наших заказчиков требовалось создать платформу для разработки различного рода продуктов на базе сервисно-ориентированной архитектуры (SOA). Суть ее в том, что используется ряд слабосвязанных сервисов и построение приложения происходит путем комбинации данных сервисов, которые взаимодействуют на основе определенного интерфейса. Сервисы могут находиться на разных операционных системах. В одном случае взаимодействия точка вызова (endpoint) может быть на Windows, в другом – на Linux. Схематически это изображено на рис.1.

Элементы сервис-ориентированной архитектурыРисунок 1. Элементы сервис-ориентированной архитектуры.

Разработанная нами платформа представляет собой сервисную шину предприятия (ESB), с расширенной функциональностью. Пользователь может применять универсальный набор инструментов для построения SOA:

Работа над проектом велась по всем канонам SCRUM. Формировался бэклог продукта. На основании данного продукта перед началом спринта происходило его планирование, на котором команда определяла цели спринта и формировала из бэклога продукта бэклог спринта. Ежедневно проводились стендапы, в конце каждого спринта команда проводила демонстрацию результатов, а затем – ретроспективу. В качестве трекинговой системы использовалась Jira.

Как мы говорили, в основе разработанной системы лежит SOA со своим набором сервисов. Каждый сервис представлял собой набор различных конечных точек взаимодействия (endpoints). И здесь очень важно было написать интеграционные End-to-End тесты для проверки корректности работы приложений, воспроизвести максимально возможное кол-во ситуаций, которые могут случиться во время жизненного цикла приложения. Для более удобной работы нашей командой был разработан собственный фреймворк для End-to-End интеграционного тестирования. Разработанный фреймворк позволял создавать интеграционные тесты, в которых можно было отслеживать состояние системы на любом уровне стека вызовов.

На рисунке 2 показано, как при запуске интеграционного теста сообщение отправляется к первому компоненту, далее оно передается ко второму компоненту. Фреймворк позволял указывать в сообщениях требуемое поведение, чтобы была возможность воспроизводить различные ситуации. К примеру, в скрипте может быть указано, что второй компонент должен выбросить исключение, тогда вызвавшему сервису будет отправлено сообщение о том, что произошла ошибка (выброшено определенное исключение). Далее после прохождения всех вызовов фреймворк записывает дерево вызовов и случившихся ситуаций, и полученный результат сравнивается с эталонным деревом вызовов.

Схематический пример выполнения интеграционного тестаРисунок 2. Схематический пример выполнения интеграционного теста.

В процессе проведения интеграционного тестирования и использования фреймворка, команда реализовала применение DDT (Data Driven Testing). Впоследствии похожий подход к интеграционному тестированию продукта, когда последовательно вызываются компоненты и полученный результат запросов-ответов сравнивается с эталонным, мы применили для разработки собственного продукта XML To Selenium.

В результате реализации этого проекта, наши сотрудники получили дополнительный опыт работы с огромными кодовыми базами, сложной архитектурой и, конечно с разнообразными рантаймами: OSGI, Tomcat, SOA.

Технологии:

Stack:‌ Java, JBI, EJB, OSGI, SOAP.
Infrastructure: Git, IntelliJ IDEA, Jira.

Особенности проекта:

Результат проекта:

Достижения компании на проекте: