История одного проекта.
Вы когда-нибудь мечтали о верблюдах? Я тоже.
Но когда работаешь с Camel третий год, не только о верблюдах начинаешь мечтать.
В общем, поделюсь своим опытом, напишу о верблюдах и научу их готовить.
Это серия статей в трёх частях: первая часть будет для тех, кому интересны истории и муки творчества; вторая более техническая, о паттернах интеграции, их применении, а третья часть — об ошибках и отладке.
Если вам необходимо консолидировать свои услуги, здесь вы узнаете, для чего подходит Camel. Если вы хотите научиться использовать что-то новое, мы начнем с основ.
Если вам нравятся истории и оригинальные особенности, которые есть у каждой команды, то читайте дальше.
Задача интеграции
Начну с того, как возникла необходимость в служебном автобусе.Мы разрабатываем большую систему, которую за спиной ласково называем «монстром».
Монстр оказался большим и страшным, но на самом деле это был один из БПМ системы (система управления бизнес-процессами).
Все началось несколько лет назад. Однажды на совещании руководитель проекта заговорил о планах на будущее: — Коллеги, в ближайшее время мы планируем интеграцию с большим количеством внутренних и внешних систем.
Сейчас нам нужно выработать системный подход, чтобы наши аналитики могли приступить к подготовке задач.
Потом какое-то время он говорил о системах, с которыми нам придется интегрироваться.
Существовали как внешние известные системы, например, elibrary.ru, так и внутренние, еще не созданные.
В конце рассказа были выявлены характерные особенности интеграции с разными типами систем.
Для внешних систем это большая неопределенность в описании процессов и объектов предметной области (бизнес-объектов), которыми предстояло обмениваться; но направление передачи данных (загрузка или выгрузка) было понятно; Рассмотрены дополнительные требования по защите каналов передачи данных, обеспечению гарантированной доставки и предпосылки создания средств исправления ошибочных данных.
По второму — внутренним системам было больше ясности.
Было четко описано функциональное назначение каждой системы.
Благодаря этому удалось проработать круг передаваемых объектов.
Но для этих систем неопределенность проявлялась на уровне: успеем – не успеем, успеем – не успеем реализовать.
Не вдаваясь в подробности области применения, ограничусь типичными задачами, на которых мы сосредоточились.
- Необходимо загрузить информацию в основную систему по стандартному протоколу.
На момент обсуждения для внешних систем были упомянуты две: HTTP, ftp; для внутреннего: JMS, HTTP, NFS, SMB и/или с использованием интерфейса RMI. Какую архитектуру мы могли бы использовать для решения этой проблемы?
- Предположим, вам необходимо загрузить информацию из основной системы и передать ее во внешнюю систему по одному из стандартных протоколов.
Какие могут быть пути решения такой проблемы?
- Или вам нужно перенести один, два, n бизнес-объектов.
Как мы можем подготовить данные и какой формат нам следует использовать?
- Допустим, вам нужно отправить сообщение электронной почты через почтовый сервер, который временно недоступен.
Для этого пользователю нужно будет либо подождать, пока последний станет доступен, либо получить сообщение о том, что он не может завершить свою работу сейчас.
Как мы могли бы построить систему, которая гарантировала бы доставку без блокировки пользователей?
- Предположим, нам необходимо иметь возможность получить информацию из внешней системы в 1 или 3 часа ночи, но наша система в это время прервала свою работу на техническое обслуживание.
Как сделать так, чтобы процессы загрузки и скачивания данных не останавливались при недоступности основной системы?
- И последняя задача: вам нужно иметь возможность быстро менять логин и пароль для доступа к внешней системе или протокол связи с ftp на sftp. Как мы могли сделать так, чтобы изменение настроек можно было производить гибко, не нарушая работу основной системы?
Идея использования промежуточного звена не нова и известна в мире интеграции под термином служебный автобус предприятия или ЕСБ.
Давайте обрисуем спектр функционала, которым должно обладать наше приложение.
За основу взяты формулировки задач.
Он должен иметь возможность:
- взаимодействовать с другими системами по стандартным протоколам: HTTP, FTP, а также JMS или с помощью интерфейса РМИ .
- чтение, запись и создание файлов в локальной файловой системе для работы с NFS
- отправлять сообщения электронной почты через SMTP-сервер.
- проанализировать один из транспортных форматов XML, JSON
- иметь гибкие настройки
- уметь описывать правила согласования форматов на одном из языков программирования Java, Groovy. Мы работали с этими языками, поэтому могли рассчитывать на отсутствие дополнительных затрат на обучение.
- возможность работать с XSLT и xPath будет дополнительным бонусом.
От рассуждений к практике
Спустя некоторое время, когда процесс поиска только набирал обороты, аналитики написали первое заявление по просьбе клиента: - Ребята, мы тут пьесу написали, надо быстро сделать.Вчера клиент очень этого ждал, так что старайтесь изо всех сил.
Такое с нами случается часто, но нам всегда удается вовремя доставить новый функционал.
Этот раз не исключение; перед нами стоял большой объем работы и сжатые сроки реализации.
Хотя мы не могли использовать сервисную шину для этого производства, мы использовали производство как первую практическую задачу по созданию прототипа.
А пока нам предстояло выбрать технологии, на которых будет построен наш прототип.
Изобретать велосипед и начинать с нуля — это здорово, но слишком дорого.
Собственные решения также не использовались, поскольку результат требовался быстро, а на согласование и решение финансовых вопросов требовалось время.
Поэтому мы обратились к opensource-проектам.
Выбора на тот момент было немного, поэтому мы смогли оценить достоинства «верблюда» с первого взгляда.
Как видно из диаграммы, Apache Camel — это модульная, легко расширяемая платформа для интеграции приложений.
Основные структурные элементы: компонентная модель, механизм маршрутизации, механизм обработки сообщений.
Модель компонентов — это набор фабрик, создающих конечные точки маршрутизации.
Например, конечная точка может быть абстракцией, которая отправляет сообщения в очередь JMS брокера.
Механизм маршрутизации связывает конечные точки с абстракциями обработки сообщений.
Последний, механизм обработки сообщений, позволяет манипулировать данными сообщения.
Например, конвертировать в другой формат, выполнять проверку, добавлять новый контент, журнал и многое другое.
Все три архитектурных компонента являются модульными, и благодаря этому возможности Camel постоянно расширяются.
Подробнее об архитектуре можно узнать на сайте Википедия и дальше Официальный веб-сайт .
Только появившись, Apache Camel обзавелся солидной коллекцией компонентов.
Мы нашли компоненты, удовлетворяющие всем нашим требованиям: JMS, HTTP, ftp, файловый, SMTP, xPath, xslt, XStream, Groovy, Java. Прям как автор статьи Какую инфраструктуру интеграции следует использовать — Spring Integration, Mule ESB или Apache Camel? , мы выбрали Camel. В этой статье сравниваются три фреймворка: Spring Integration, Mule ESB и Apache Camel. Автор описывает ключевые преимущества следующим образом:
.Возможность использования свободное владение Java DSL вместо «корявого» XML стал для нас большим преимуществом.Apache Camel благодаря своим потрясающим DSL для Java, Groovy и Scala в сочетании со многими поддерживаемыми технологиями.
Возникает вопрос: что такое коряво? XML — отличный язык разметки, но уже давно его предпочитают JSON или YAML. Им отдается предпочтение из-за их простоты, лучшей читаемости, меньшего количества вспомогательной информации и более простых алгоритмов анализа.
Такие языки программирования, как Java, Groovy, Scala, полностью поддерживаются современными IDE, а это значит, что в отличие от XML появляется возможность отладки и рефакторинга.
В отношении Camel сомнений не было, и он лег в основу нашего служебного автобуса.
Тот факт, что этот проект был использован другие компании , добавило уверенности в правильности выбора.
Оставался главный вопрос — как интегрировать Camel в нашего монстра.
Выбор: JMS против RMI.
Интеграцию сервисной шины и нашего монстра можно было реализовать с помощью одного из множества компонентов, поддерживаемых Camel. Исходя из поставленных выше задач, мы сформировали требования: связь должна быть стабильной и гарантировать доставку сообщений.
Мы остановились на трех вариантах: первые два были синхронными RMI и HTTP и один асинхронный JMS. Из трех мы остановились на двух самых простых вариантах, подходящих для наших Java-проектов: JMS, RMI. JMS (служба сообщений Java) — это стандарт отправки сообщений; он регулирует правила отправки, получения, создания и просмотра сообщений.
Второй, RMI (Удаленный вызов метода) — это программный интерфейс удаленного вызова процедур, который позволяет вызывать методы одной JVM в контексте другой.
Стандартная процедура удаленного вызова включает упаковку объектов Java и их передачу.
Справедливости ради стоит отметить, что противопоставлять JMS и RMI некорректно, поскольку JMS может быть транспортом и компонентом RMI. Мы противопоставляем стандартную реализацию RMI реализации JMS — ActiveMQ. Ранее мы использовали RMI для интеграции двух приложений.
Почему его тогда выбрали? Когда оба приложения написаны на Java, нет ничего проще, чем RMI. Для того, чтобы его использовать, достаточно описать интерфейс и зарегистрировать объект, реализующий этот интерфейс.
Но нам пришлось решать проблемы, возникавшие с RMI при передаче большого объема данных между приложениями: память забивалась, и приложения «сворачивались».
Мы искали пути решения этой проблемы и обсуждали ее с разработчиками JVM из JavaOne. Оказалось, что сборщики мусора в виртуальной машине и распределенные сборщики мусора — это две разные вещи.
Все сводилось к тому, что для стандартного сборщика мусора можно было выбрать его тип и настроить оптимальные параметры, а для распределенного такой возможности не было.
Другими словами, RMI ограничила интеграцию с приложениями, работающими на JVM, а JMS этого не сделала.
Помимо описанных сложностей, было желание узнать что-то новое: отказаться от RMI и использовать альтернативное решение.
Первый прототип Camel
Вернемся к созданию прототипа.Первая практическая задача для сервисной шины была такая: пользователь инициирует процесс загрузки данных, система подготавливает их и отправляет на сервисную шину.
Вся работа по доставке данных ложится на нее.
На рисунке показан пример постановки задачи в символах шаблонов интеграции корпоративных приложений (EIP).
Служебная шина объединяет получение сообщений из канала JMS, их преобразование и отправку через HTTP. Канал JMS и канал отправки сообщений в формате HTML, отмеченные на рисунке, предполагалось реализовать с помощью компонентов JMS и Jetty компании Camel. Процесс преобразования данных может быть реализован на Java и/или с использованием механизмов шаблонов, таких как VM (Apache Velocity).
Предложенная схема передачи данных реализована на языке Java DSL в одну строку.
Пример:
В приведенном выше примере показан маршрут в Java DSL. Маршрут — это описание маршрута передачи сообщения.from("jms:queue:se.export") .setHeader(Exchange.HTTP_METHOD,constant(org.apache.camel.component.http.HttpMethods.POST)) .
process( new JmsToHttpMessageConvertor() ) .
inOnly("jetty:{{externalsystem.uri}}");
В Camel описания могут быть двух типов: Java DSL и XML DSL. Характеристики такого маршрута — это начальная точка и одна или несколько конечных точек, обозначенных токенами «от» и «до» соответственно.
Маршрут описывает путь сообщения от начальной точки до конечной точки.
Если конечные точки указаны последовательно, сообщение будет отправлено первой, служебная шина будет ждать ответа, который затем будет отправлен следующей конечной точке.
Могут существовать маршруты, выбирающие нужную конечную точку ( Динамический маршрутизатор ) или отправку сообщения сразу в несколько точек ( Список получателей ).
Параметр токена from и to представляет собой строку с URI. URI — это тройка параметров, состоящая из имени компонента Camel, идентификатора ресурса и параметров соединения.
Давайте посмотрим на пример: from(“jms:queue:se.exportЭtimeToLife=10000”)
Это описание точки входа, использующей компонент JMS. Компонент JMS предоставляет возможность получать данные из ресурса Queue:se.export. Если очередь — это тип канала сообщений, это может быть очередь или тема.
Далее идет имя канала «se.export».
Очередь с этим именем будет создана брокером сообщений.
Последняя часть URI, параметры конечной точки: «timeToLife=10000», указывает, что время жизни пакета составляет 10 секунд. Из примера понятно, как мы планировали организовать передачу данных; следующая статья будет содержать больше реального кода и примеров.
Итак, мы решили проблему передачи данных, создали прототип интеграционной шины, который состоял из Camel и был практически готов к реализации.
Оставалось только решить проблему его правильной и удобной настройки.
Настройка прототипа
Меня очень впечатляет эта тема, так как практических советов и примеров реализации найти сложно.Структура нашего стенда следующая: У каждого разработчика есть своя копия программного обеспечения, и он полностью настраивает ее перед запуском.
Есть два тестовых стенда для ручного тестирования и конечно есть рабочая система.
Формулировка проблемы следующая:
- небольшие доработки на каждом из стендов нужно было делать просто редактированием минимального количества параметров в файлах конфигурации системы
- Основная кастомизация (добавление новых функций) прошла незаметно для всех стендов.
В этой задаче много сложностей: Camel подключен к JMS-брокеру, что заставляет использовать разные каналы для разных стендов или разных брокеров сообщений.
Мы пошли по самому простому пути, запустив встроенный в шину брокер ActiveMQ. В этом случае осталось указать настройки подключения для разных серверов.
Перейдем к примерам использования параметров в настройках Camel:
- Пример из файла Camel-config.xml
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> <property name="locations"> <list> <value>classpath:system.properties</value> <value>classpath:smtp.properties</value> </list>
-
Итоги Предпродажи И Новости Проекта
19 Oct, 24 -
Просмотр 3D-Фильмов Дома
19 Oct, 24 -
Беспроводные Видеоочки
19 Oct, 24 -
New.bwc.ru Глазами Артемия Лебедева
19 Oct, 24
