Паттерны интеграции

Задача интеграции часто встречается особенно в приложениях уровня предприятия. Это связано с тем, что именно в большой организации есть множество разнородных систем, которые надо научить говорить друг с другом. Часто это системы устаревшие или несовместимые друг с другом. Системы могут работать на разных платформах, быть написаны на разных языках, разными командами, и использовать разные подходы получения, обработки, хранения и вывода данных. Между системами могут быть непреодолимые границы в виде файрволов, не позволяющие, например, офису в Каргополе подключиться напрямую к базе данных головного офиса в Шепетовке. Из-за этого при передаче данных приходится прибегать к ручному труду, многократному переконвертированию данных из одного формата в другой, передаче этих данных и повторному их вводу в другую систему тоже иногда вручную. Ручной труд усложняется с усложнением бизнес процесса. Данные уже не просто надо переложить из одного приложения в другое, а еще и обработать.

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

Общая Теория Интеграции

Исследования и опыт показали что при всем многообразии существует в общем-то всего четыре способа интегрировать разнородные системы:

• обмен данными через общую базу данных (database)
• обмен данными через общую файловую систему (file system)
• обмен данными через сообщения (messaging)
• обмен данными через удаленные вызовы (remote-procedure calls)

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

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

Приложение сбора статистики сбрасывает в лог текущие данные на диск, а приложение обработки статистики эти данные считывает построчно и обрабатывает. Это интеграция через файловую систему.

Отправка сообщений настолько распространена, что мы даже не замечаем этого: email, телеграмм-боты, социальные сети, и проч.

На принципе удаленного вызова процедур строились и строятся приложения, использующие CORBA, Micrososft COM/DCOM, Java RMI, XML-RPC, SOAP, REST и проч.

Как известно, в дизайне программ есть паттерны программирования (design patterns), о которых написаны тома, а началось все с книги Банды Четырех «Design Patterns: Elements of Reusable Object-Oriented Software». Точно так же все вышеперечисленные способы интеграции порождают определенные шаблонные решения — integration design patterns. Эти интеграционные шаблонные решения были тоже сведены в каталог и представлены в основополагающей книге «Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions«, которая вышла еще в 2003 году из под пера Греора Хохпе (Gregor Hohpe) в соавторстве с Бобби Вульфом (Bobby Woolf).

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

Apache Camel

Проект Apache Camel, которым руководит Клаус Ибсен (Claus Ibsen), был призван предложить как раз такое универсальное программное решение на базе Java/JVM. Apache Camel представляет собой фреймворк-конструктор, который позволяет легко собрать интеграционное приложение из имеющихся компонентов (или написать свои недостающие компоненты).

На Apache Camel можно построить приложение с нуля, которое для запуска будет требовать только сам Apache Camel, для упрощения конфигурации можно использовать обвязку из чистого Spring. А для упрощения компоновки приложения использовать Spring Boot. Apache Camel как библиотеку можно встроить как зависимость в уже существующее Java приложение, обогатив это приложение интеграционными функциями без полного переписывания приложения. Т.е. Apache Camle достаточно гибкий фреймворк, который не диктует вам, как именно ваше приложение должно быть написано и скомпоновано.

Скажем, вам поставлена такая задача: по электронной почте на определенный почтовый ящик приходят отчеты из низовых офисов с приложением в виде csv-файла. Эти отчеты надо из писем извлекать, разобрать каждый файл построчно, извлечь из каждой строки определенные данные, переформатировать их и занести в базу данных. А потом ежедневно в конце дня из базы данных доставать свежие записи, формировать из них красивый pdf-файл и выкладывать это файл в определенную папку на веб-сайте через sftp.

В качестве варианта все это можно было бы сделать через shell/perl скрипты, и запускать их с помощью cron-а. Но тогда теряется единство всего процесса: у вас на руках оказывается куча скриптов, к которым надо еще подключить сторонние библиотеки, чтобы они умели «разговаривать» с IBM MQ или базой данных Oracle. Apache Camel же позволяет описать все стадии движения данных в удобной форме xml-файла и создать единое целое Java-приложение, которое легко будет выкатывать на PROD, модифицировать в случае необходимости, обновлять зависимости с помощью maven/gradle хранить все исходники проекта в системе контроля версий и запускать-останавливать, как обычную программу, тестировать с помощью JUnit, пошагово отлаживать в любимом IDE.

Клаус Ибсен — автор книги Camel in Action, которая вышла недавно уже во втором издании.

В книге отлично представлен сам проект Apache Camel и объяснена цель его существования. Даны примеры интеграции, сначала простые, потом все более сложные. Описаны многие компоненты, которые включены в конструктор Apache Camel. Рассказано, как писать свои компоненты и как писать обвязку вокруг этих компонентов и конфигурировать их в цельное приложение.

Выводы

Очень рекомендую прочитать обе книги. Книга Хопхе даст общую идеи паттернов интеграции, а книга Ибсена — даст конкретные пример их реализации.

Apache Camel не является универсальным решением абсолютно всех задач интеграции, но, как показывает мой собственный опыт, многие приложения уровня предприятия, которые пишутся с нуля крупными командами, можно проще и надежнее написать с помощью именно Apache Camel. Например, в банковской сфере многие приложения Back Office — это именно приложения интеграции одних систем с другими, где из одной системы перебрасываются данные в другую систему, а оттуда извлекаются третьей системой для какой-то аналитики, преобразования и визуального отображения.