Знакомство с Spring Integration

Марк Фишер: Многие приложения требуют некоторой логики интеграции, такой как преобразование данных и маршрутизация между несколькими конечными точками (например, JMS и File). Существует несколько способов удовлетворения этих требований, охватывающих спектр от внутренних реализаций до тяжеловесных, а иногда и дорогих продуктов ESB. Внутренний подход обычно является результатом признания того, что полномасштабный ESB является избыточным для конкретной рассматриваемой проблемы. В лучшем из этих случаев реализована чистая внутренняя структура, но она добавляет нагрузки, связанные с поддержкой общего кода платформы, а не с акцентом на основные бизнес-проблемы.

В худшем случае логика интеграции запутывается в бизнес-логике, что приводит к чрезмерно сложным, непроверяемым приложениям. Посредством консультаций и обратной связи с сообществом мы часто сталкивались с этими проблемами и получали запросы на предоставление некоторой поддержки в качестве «расширения» текущих предложений Spring, таких как поддержка JMS и веб-сервисов. Мы чувствовали, что это требование оправдывает прагматическое решение в портфеле Spring.

Мотивация заключалась в том, чтобы обеспечить самый тонкий из возможных уровней поверх Spring Framework, который был бы согласованным на уровне модели программирования и конфигурации. Это обеспечивает постепенное принятие и не требует каких-либо дополнительных зависимостей, кроме Spring Integration JAR. С внутренней точки зрения, наличие нашего собственного портфельного проекта для решения этих проблем позволяет нам сотрудничать и обеспечивать бесшовную интеграцию с другими портфельными проектами Spring, а также сосредоточиться на поддержке развертывания приложений Spring Integration в SpringSource dm Server. Мы также будем оказывать поддержку в SpringSource Tool Suite и Application Management Suite.

Сагру: Реализует ли проект весь набор шаблонов в книге «Шаблоны интеграции предприятия»?

Фишер: Между реализацией и шаблоном не существует прямого взаимно-однозначного сопоставления, поскольку некоторые шаблоны на самом деле являются концепциями проектирования высокого уровня (например, Трубы и Фильтры). Кроме того, некоторые из них «реализованы» во взаимодействии между компонентами (например, последовательность сообщений). Наконец, некоторые из шаблонов реализованы как часть другого компонента (например, «Адрес возврата» сохраняется как заголовок в сообщении).

Тем не менее, мы реализуем большинство шаблонов, которые четко отображаются на компонент (например, Service Activator, Transformer, Router, Splitter, Aggregator, Wire Tap, Channel Purger и т. Д.).

Во многих из этих случаев мы фактически предоставляем адаптер, который позволяет разработчику подключить существующий POJO для выполнения роли. Адаптер управляется конфигурацией на основе XML или аннотаций (например, @Router на уровне метода). Именно поэтому мы описываем Spring Integration как расширение модели программирования Spring *. Есть сходство с поддержкой Spring JMS и даже поддержкой аннотаций Spring 2.5 для MVC.

Есть несколько «составных» шаблонов, которые мы планируем реализовать в будущих версиях, таких как Routing Slip и Process Manager. Мы также можем предоставить поддержку более высокого уровня для некоторых составных шаблонов, которые уже поддерживаются. Например, «Обработчик составленных сообщений» состоит из Сплиттера, Маршрутизатора и Агрегатора. Мы уже предоставляем поддержку для этих 3 отдельных шаблонов, но мы пока не предоставляем реализацию этого составного шаблона более высокого уровня напрямую.

Сагру: Какой твой любимый аспект проекта?

Фишер: Простота модели, управляемой конфигурацией, и повышенная производительность.

Сагру: Можете ли вы привести пример того, как Spring Intergation упрощает вещи?

Фишер: Вот простой пример, который должен прояснить, как это упрощает логику интеграции:

<service-activator input-channel="tickers" output-channel="quotes" ref="quoteService" method="getQuote"/>

 

public Quote getQuote(String ticker) {
  ...
}

Сообщение интеграции Spring, отправленное на входной канал, будет иметь тикер String, а компонент, подписанный на канал «quotes», получит сообщение с объектом Quote в качестве полезной нагрузки.

Абстракция канала также упрощает использование различных транспортов. Например, у нас есть канальные адаптеры:

<file:inbound-channel-adapter channel="filesIn" directory="file:/some/directory/"/>

<jms:outbound-channel-adapter channel="jmsOut" destination="someQueue"/>

Дополнительные примеры вы можете найти в справочном руководстве: http://static.springframework.org/spring-integration/reference/htmlsingle/spring-integration-reference.html.

Сагру: Где отсюда для весенней интеграции?

Фишер: В будущих версиях мы будем использовать возможности Spring 3.0, такие как поддержка языка выражений. Мы также планируем расширить нашу существующую интеграцию с другими проектами Spring, такими как Spring Security и Spring Web Services, и мы добавим интеграцию с дополнительными проектами, включая Groovy и Grails. Мы также запустили проект Spring Extensions для добавления адаптеров Spring Integration помимо тех, которые предусмотрены в основном дистрибутиве.