Доклад на конференции Kolesa/Web 1.0

1. Enterprise Service Bus
ИНТЕГРАЦИЯ И УПРАВЛЕНИЕ СИСТЕМАМИ С ПОМОЩЬЮ ESB

2. Finlab Group
2 основных проекта (3-й на подходе)
Порядка 8-ми вспомогательных проектов и 25-ти сервисов
Java/PHP, MySQL/PostgreSQL, Delphi, C++
4 физ. сервера + 14 виртуалок + 2 сервера in-house

3. Finlab Group в квадратиках
K24
(b)
DEV
K24
(f)
PD
CRM PBX
Сервер на colocation
Сервер в офисе
Виртуалка
Script-service

4. Задача из жизни
Хотим, чтобы в интерфейсе одного из веб-сервисов показывались карточки входящих
звонков

5. Реализация
K24
(b)
DEV
K24
(f)
PD
CRM PBX
Сбор информации
Обработка информации
Передача json-массива

6. Минусы
- В одном сервисе – 100500 подключений к базам
- Быстродействие и отказоустойчивость сервиса оставляют желать лучшего
- Изменение в каком-либо компоненте требуют изменение сервиса и наверняка –
обработчика массива на веб-проекте
- Бардак в коде сервиса при его росте
- Реализация поддержки кучи протоколов для общения с другими сервисами
- Аналогичных сервисов – очень много и все разные

7. Реалии до ESB
K24
(b)
DEV
K24
(f)
PD
CRM PBX
rest/json/xml/soap/http/file/wsdl etc.

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

9. ESB in da house
Сервисная шина предприятия — связующее
программное обеспечение, обеспечивающее
централизованный и унифицированный событийно-
ориентированный обмен сообщениями между
различными информационными системами на
принципах сервис-ориентированной архитектуры.
(c) Wikipedia

10. ESB in da house
ESB
REST
SOAPJSON
XML
HTTP
HTTPS
MQ/JMS
BPEL

11. Зачем?
Системы независимы друг от друга
Нет дублирования кода
Высокий уровень безопасности
Управляемая нагрузка
Централизованные логи
Отказоустойчивость и гарантии выполнения интеграционного процесса
Возможность отладки всего интеграционного процесса
Нет зависимости от персонала (точнее, зависимости намного меньше)
Эффективное повторное использование
Валидация сообщений XML-схемами
Единое место для реализации бизнес-логики интеграционных решений
Минимум программирования – почти вся работа делается в студии (click-programming)
ESB
REST
SOAPJSON
XML
HTTP
HTTPS
MQ/JMS
BPEL

12. ESB в правильной архитектуре
Система 1
ESB
Система 2 Система 3
Система 4 Система 5 Система 6
Адаптер системы
Канонический сервис

13. Что есть зачем
- Система-потребитель 1 запрашивает у шины
информацию с систем-поставщиков 4 и 6
- Адаптер системы 1 преобразует входящее
сообщение в канонический (унифицированный)
формат и передает в сервис-обработчик
- Сервис понимает, с какого адаптера и с какими
данными пришло сообщение и передает его на
адаптер нужной системы-поставщика
- Адаптер преобразует сообщение в формат систем-
поставщиков и отправляет запрос в эти системы
- После отправки сообщения и получения ответа
цепочка запускается в обратном порядке
Система 1
ESB
Система 2 Система 3
Система 4 Система
5 Система 6

14. Адаптер VS. канонический сервис
Адаптер – набор сервисов, через которые информационная система взаимодействует с
интеграционной шиной. Должен учитывать специфику системы, с которой
взаимодействует. Внутренняя и внешняя точки адаптера – WSDL/XSD с наборами правил,
описанием преобразования данных, sql-запросами и т.п.
Канонический сервис - унифицированный сервис, построенный в соответствии с общими
правилами, ориентированный на повторное использование. Правила и маршрутизация
сообщений описываются также с помощью WSDL/XSD.

15. Канонический
сервис
Запросы в базу
системы
(WSDL)

17. ESB по-простому
Система 1
(потребитель)
Система 2
(поставщик)
ESB Сервис 1 Сервис 2 Сервис 3

18. Без задела на будущее
Система 1
(потребитель)
Система 2
(поставщик)
ESB Сервис
1
Сервис
2
Сервис
3
Плюсы:
- Централизованно
- Быстро
- Стандартизировано (отчасти)
- Не трогаем протоколы систем
Минусы:
- На каждый обмен сообщениями - свой сервис
- Интеграция схожа со схемой точка-точка
- В случае замены или модификации любой из систем -
модификация точек сервиса-обработчика
- 100500 сервисов, по одному на каждый обмен
- Тяжелое обслуживание

19. По простому - 2
Система 1
(потребитель)
Система 2
(поставщик)
ESB Сервис 1

20. Без задела на будущее - 2
Система 1
(потребитель)
Система 2
(поставщик)
ESB Сервис 1
Плюсы:
- В одном сервисе принимаем все возможные форматы
сообщения и преобразуем во все возможные форматы на
выходе
Минусы:
- Обслуживать большой сервис сложно
- Модификация любого сообщения от любой из систем
потребует модификацию и повторное тестирование
сервиса

21. Как настроить?
Java Environment (JDK/Tomcat)
OpenESB + Glassfish Server (v2.3)
Nginx/Apache
https://rest.esb.kredit24.kz/pbx/getIncomingCalls?phone=77776779818

22. Вопросы и информация
dev0@prodengi.kz
dev1@prodengi.kz