apache servicemix что это

Apache servicemix что это

Apache ServiceMix is a flexible, open-source integration container that unifies the features and functionality of Apache ActiveMQ, Camel, CXF, and Karaf into a powerful runtime platform you can use to build your own integrations solutions. It provides a complete, enterprise ready ESB exclusively powered by OSGi.

It is being released under Apache License v2.

The main features are:

reliable messaging with Apache ActiveMQ

messaging, routing and Enterprise Integration Patterns with Apache Camel

WS‐* and RESTful web services with Apache CXF

OSGi-based server runtime powered by Apache Karaf

Through additional installable features, ServiceMix also supports:

full JPA support via Apache OpenJPA

XA transaction management via JTA via Apache Aries

legacy support for the JBI standard (deprecated after the ServiceMix 3.x series) through the Apache ServiceMix NMR that includes a rich Event, Messaging and Audit API

Applications for ServiceMix can be built using:

OSGi Declarative Services

Download ServiceMix 7.0.1
Download ServiceMix 6.1.4

ServiceMix 7.0.1 released

The ServiceMix team is pleased to announce the availability of Apache ServiceMix 7.0.1.

This new patch release includes few bug fixes and picks up new versions of Apache Camel,
Apache CXF, Apache ActiveMQ and Apache Karaf.

Major dependency versions for this release:

Apache ActiveMQ 5.14.5

For more information, please see the release notes

ServiceMix 6.1.4 released

The ServiceMix team is pleased to announce the availability of Apache ServiceMix 6.1.4.
This new patch release includes few bug fixes and picks up new versions of Apache Camel
and Apache CXF.

WARNING: this is probably the last scheduled release of ServiceMix 6.x. We encourage users
to upgrade to more recent ServiceMix versions.

Major dependency versions for this release:

Apache ActiveMQ 5.12.3

For more information, please see the release notes

Источник

Apache ServiceMix

4.4.1 (22 февраля 2012)

Apache ServiceMix — пакет для создания композитных приложений, основанный на спецификации Java Business Integration (JBI). ServiceMix базируется на концепции корпоративной сервисной шины (Enterprise Service Bus — ESB), комбинируя сервис-ориентированную архитектуру (Service Oriented Architecture — SOA) и cобытийно-ориентированная архитектуру (Event Driven Architecture — EDA).

ServiceMix часто используется совместно с Apache ActiveMQ, Apache Camel и Apache CXF в SOA-проектах. Также ServiceMix как JBI-контейнер используется в ChainBuilder ESB.

На основе ServiceMix был сделан пакет Fuse ESB, компании LogicBlaze. В 2007 году Iona Technologies приобрела LogicBlaze, через год её саму купила Progress Software, а в 2012 году это ПО выкупила компания Red Hat.

Ссылки

Apache Software Foundation
Проекты верхнего уровня	ActiveMQ • Ant • Apache HTTP Server • APR • Beehive • Cassandra • Cayenne • Camel • Commons • Cocoon • CouchDB • DB • Directory • Excalibur • Forrest • Geronimo • Gump • Hadoop • Harmony • HBase • HiveMind • HttpComponents • iBATIS • Jackrabbit • James • JMeter • Lenya • Maven • Mina • mod perl • MyFaces • Nutch • OFBiz • OpenOffice.org • POI • Portals • Santuario • ServiceMix • Shale • Shiro • SpamAssassin • Struts • Subversion • Tapestry • Tcl • Tomcat • Turbine • Velocity • WebWork 2 • Wicket • Xalan • Xerces • XMLBeans
Подпроекты	Apache Commons BCEL • BSF • JCS Apache Lucene Lucene Java • Lucene4c • Lucy• Solr Apache DB Derby • Torque • DdlUtils • OJB • JDO
Apache Web Services	Axis • Axis2 • CXF • WS-Commons • EWS • JaxMe • jUDDI • Kandula • Mirae • Muse • Pubscribe • Sandesha • Scout • SOAP • Synapse • TSIK • Tuscany • Woden • WSIF • WSRF • WSS4J • XML-RPC
Другие проекты	Batik • FOP •Log4j
Развивающиеся проекты (Incubator)	XAP • River • OpenEJB • OpenJPA • Graffito • Tuscany • Log4Net • Roller • Felix • Abdera • CeltiXfire • FtpServer • Heraldry • Ivy • JuiCE • Kabuki • Lokahi • Lucene.Net • mod_ftp • NMaven • Ode • stdcxx • Woden • WSRP4J • Yoko • WADI • Qpid • stdcxx • TripleSoup • UIMA• Adobe Flex
Списанные проекты (Attic)	AxKit • Cactus • ECS • Jakarta • ORO • Regexp • Slide • Taglibs
Лицензия: Лицензия Apache • Сайт: apache.org

Полезное

Смотреть что такое «Apache ServiceMix» в других словарях:

Apache ServiceMix — Infobox Software name = Apache ServiceMix caption = developer = Apache Software Foundation latest release version = 3.2.2 latest release date = release date|2008|07|31 latest preview version = latest preview date = operating system = Cross… … Wikipedia

ServiceMix — Saltar a navegación, búsqueda Apache ServiceMix es ESB (enterprise service bus) distribuido de clase empresarial y una caja de herramientas para crear una arquitectura orientada a servicios (SOA). Este fue construido desde el comienzo usando la… … Wikipedia Español

Apache Felix — Apache Felix … Википедия

Apache CXF — Developer(s) Apache Software Foundation Stable release 2.4.3 / October 12, 2011; 24 days ago (2011 10 12) Development status Active … Wikipedia

Apache ActiveMQ — Тип Java Message Service Message Oriented … Википедия

Apache Geronimo — Standard Startseite des Apache Geronimo Basisdaten Entwickler … Deutsch Wikipedia

Apache Camel — Maintainer Apache Software Foundation Aktuelle Version 2.8.1[1] (16. September 2011) … Deutsch Wikipedia

Apache CXF — Entwickler Apache Software Foundation Aktuelle Version 2.4.0 (18. April 2011) Betriebssystem plattformübergreifend Programmier­sprache Java … Deutsch Wikipedia

Apache ActiveMQ — Infobox Software name = Apache ActiveMQ caption = developer = Apache Software Foundation latest release version = 5.1 latest release date = release date|2008|05|07 latest preview version = latest preview date = operating system = Cross platform… … Wikipedia

Apache Camel — Infobox Software name = Apache Camel caption = developer = Apache Software Foundation latest release version = 1.4.0 latest release date = July 22, 2008 latest preview version = latest preview date = operating system = Cross platform programming… … Wikipedia

Источник

Обзор ESB-систем ServiceMix и Fuse

Представляю вашему вниманию небольшой обзор систем ESB (Enterprise Service Bus) на основе Apache Camel: Apache ServiceMix и Red Hat JBoss Fuse. Эти две системы построены на одних и тех же компонентах и обладают схожими возможностями. Более того, в большинстве случаев, они взаимозаменяемы. Apache ServiceMix разрабатывается open-source сообществом, Red Hat JBoss Fuse компанией Red Hat. По большей части, это одни и те же люди.

Для начала, разберемся что такое ESB и зачем системы такого класса используются в информационной инфраструктуре предприятий. На современных предприятиях используется всё большей приложений различного класса: ERP, CRM, BPM, DWH, ECM и ещё множество трех-буквенных аббревиатур. Все эти приложения используют для интеграции различные протоколы и различные форматы данных. Для того чтобы связать все эти системы между собой и используется ESB.

Итак ESB-системы выполняют следующие основные функции:

Apache Camel реализует непосредственно функции ESB на основе паттернов EIP (Enterprise Integration Patterns). Apache Camel имеет свой DSL для задач интеграции. Существует несколько его реализаций: Spring DSL, Blueprint DSL, Java DSL, Groovy DSL, Scala DSL. Так же, в состав Apache Camel входит более 100 компонент отвечающих за подключение по различным протоколам и преобразование данных.

Apache ActiveMQ — система очередей сообщений. Реализуется различные функции обмена сообщениями: обмен сообщениями по моделям отправитель-получатель (sender-receiver), издатель-подписчик (publish-subscribe), синхронный обмен (request-response), персистентные сообщения (persistent message), поддержку транзакций, включая распределенные XA-транзакции.

Apache CXF — библиотека, реализующая функции веб-сервисов, включая SOAP и REST.

Apache Karaf — платформа для запуска приложений на основе OSGi. OSGi позволяет устанавливать, удалять и обновлять различные модули (bundle) без перезапуска всей системы и без остановки зависимых модулей. Это особенно важно в корпоративной инфраструктуре, где остановки компонент крайне нежелательны, так как могут привести к прямым финансовым потерям. В системах на основе OSGi всё является модулем (bundle): библиотеки, маршруты интеграции, подключения к ресурсам.

Для Red Hat JBoss Fuse существует альтернативный вариант запуска. Вместо Apache Karaf можно использовать Red Hat JBoss EAP.

Обе системы поддерживают отказоустойчивую (failover) конфигурацию по модели master-slave.

Встает резонный вопрос, если Apache ServiceMix и Red Hat JBoss Fuse состоят из одних и тех же компонент, реализуют одну и ту же функциональность, разрабатываются одними и теми же людьми, то зачем платить больше? Кроме указанных выше компонентов, Red Hat JBoss Fuse включает несколько дополнительных, упрощающих работу администратора и позволяющих управлять кластером.

Hawtio — графическая консоль управления, позволяющая подключать различные плагины, в том числе для управления Apache Camel, Apache ActiveMQ, Fuse Fabric и т.д… Несмотря на то что Hawtio не входит в состав Apache ServiceMix, она может быть установлена на любую версию Apache ServiceMix двумя командами.

Fuse Fabric — система управления кластером на основе Fabric8. Позволяет управлять конфигурациями узлов кластера группами или по отдельности. Поддерживает версионирование конфигурации. Так же как и Hawtio, Fabric8 может быть легко установлена на Apache ServiceMix. Кроме того, для Apache ServiceMix имеется альтернативный способ управления кластером на основе Apache Karaf Cellar.

При приобретении подписки Red Hat JBoss Fuse вы получаете поддержку от компании Red Hat и возможность использовать инструмент мониторинга Red Hat JBoss Operation Network. Для Apache ServiceMix можно использовать RHQ, open-source аналог Red Hat JBoss Operation Network. Как альтернатива, для целей мониторинга Apache ServiceMix может быть использован Apache Karaf Decanter.

Apache ServiceMix’у тоже есть чем похвастаться. В состав последних версий Apache ServiceMix входит движок бизнес-процессов Activiti, который позволяет реализовывать персистентные интеграционные процессы. Apache Camel не предназначен для реализации интеграционных взаимодействий разнесенных по времени. Если при использовании Apache Camel без Activiti происходит сбой, то все не отправленные данные будут потеряны, все транзакции откатятся. В то же время, с использованием Activiti мы можем сохранить состояние процесса в БД. Red Hat для решения подобных задач предлагает использовать Red Hat JBoss BPM Suite.

Основным преимуществом Apache ServiceMix перед Red Hat JBoss Fuse является то что Apache ServiceMix включает более новые версии компонент.

Что выбрать? Универсального ответа нет. Если у вас есть команда профессионалов, имеющих опыт работы с Apache ServiceMix или Red Hat JBoss Fuse, то можно задействовать все преимущества Apache ServiceMix и заплатить при этом меньше. Если же опыт отсутствует, то поддержка от компании Red Hat не будет лишней.

Кроме рассмотренных систем, на основе Apache Camel существует Talend ESB. Но я не имел практического опыта работы с ней, поэтому в обзор она не включена.

Источник

Опыт построения интеграционной платформы на базе ServiceMix (Camel) и RabbitMQ

Как только в компании появляется хотя бы две информационных системы, которым необходимо обмениваться данными, возникает вопрос, как организовать их взаимодействие. Вариантов множество: файловый обмен, линки между базами данных, web или rest сервисы, различные системы обмена сообщениями, устаревшие RPC и CORBA, новомодный gRPC и т.д. Выбор зависит от предпочтений участников проекта и от возможностей систем (архитектура системы, используемая платформа, наличие готового API и пр.). Предположим, выбрали какой-то способ обмена, системы начали взаимодействовать, все хорошо. Но потом возникает третья система, с которой тоже надо интегрироваться, потом четвертая и т.д. Нужно опять садиться и выбирать способ обмена, и не факт что удастся ограничиться уже используемыми технологиями (где-то это продиктовано ограничениями новых систем, где-то разработчик настоял на другой технологии или захотел попробовать что-то новое). С ростом количества систем растет количество и сложность взаимодействий между ними, растет количество используемых технологий. В итоге вся интеграционная архитектура компании начинает напоминать запутанный клубок разноцветных ниток, как-то связывающих системы компании, который все сложнее распутывать при разборе ошибок и доработках. Рано или поздно начинают приходить мысли о создании единой интеграционной среды, которая прозрачно и расширяемо свяжет все системы воедино.

В этой статье я расскажу об опыте использования Apache ServiceMix (Camel) и RabbitMQ для построения такой интеграционной среды.

Стэк технологий

RabbitMQ

RabbitMQ – система обмена сообщениями на базе протокола AMQP. Подробно описывать саму систему не стану, на Хабре уже есть несколько статей, которые детально описывают функционал системы, расскажу о том, где и как RabbitMQ используется у нас.

Через RabbitMQ мы обмениваемся данными с информационными системами компании. Для каждой системы создается набор очередей. Например, нужно организовать поиск клиентов по ФИО и дате рождения в учетной системе. Создаем пару очередей. Одна входящая по отношению к учетной системе, в нее будем посылать запросы с указанием ФИО и даты рождения клиента. Учетная система слушает входящую очередь и обрабатывает поступающие запросы. Вторая — исходящая, в которую учетная система будет отправлять ответы со списком найденных клиентов, подходящих под условия запроса.

Apache ServiceMix

ServiceMix – Karaf контейнер с предустановленным набором бандлов, которые пригодятся для решения различных интеграционных задач.

Немного более подробно о том, что входит в состав продукта:

Apache Camel

Ключевым компонентом ServiceMix является фреймворк Apache Camel, который позволяет строить интеграционные процессы, которые в терминологии Camel называются роутами.
Покажу на примере — что такое роут:

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

Camel поддерживает различные нотации для описания роутов, наиболее распространенные Java DSL и Spring XML. Мы используем Spring XML. Вот как бы выглядел роут на картинке в нотации Spring XML:

Весьма приятным дополнением является то, что Camel прекрасно интегрирован со Spring. Можно использовать привычный Spring XML, в котором определяются бины, и в этом же Spring XML определять Camel роуты. При этом, из роутов можно вызывать бины, а из бинов можно обращаться к роутам. Вызов бинов из роутов реализован со свойственной Camel гибкостью, можно передавать в метод бина тело сообщения, можно передавать заголовки + тело, а можно передать только значение определенного тэга XML сообщения, указанного через XPATH выражение, а результат выполнения метода использовать в конструкции choice для последующего определения маршрута. И все это практически в одну строку.

Вот пример элегантности в стиле Camel:

Еще одно важное понятие в Camel – это endpoint (далее эндпоинт). Роуты могут читать сообщения из эндпоинтов, могут посылать сообщения в эндпоинты. Эндпоинтом может выступать, например, RabbitMQ очередь, файл в директории, опубликованный rest сервис и т.д. Если роут читает эндпоинт, то при поступлении сообщения в этот эндпоинт роут начинает его обработку. Это позволяет опубликовать роут, т.е. дать возможность обращаться к нему внешним системам. Если у вас есть роут, который выполняет какую-то задачу, например, проверяет корректность заполненных в анкете данных, то вы его можете опубликовать как web сервис, или дать возможность обращаться к нему через JMS, а можете сделать и то и другое, чтобы внешние системы могли пользоваться возможностями вашего роута, кто-то через вызовы web сервиса, а кто-то путем обмена сообщениями через JMS очереди.

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

Интеграционная архитектура

В нашей компании используется некоторое количество информационных систем. Для того чтобы организовать интеграционную среду, через которую системы будут обмениваться данными, нужно для начала подключить наши системы к интеграционной платформе. Для этого для каждой системы на ServiceMix разрабатывается адаптер, который будет отвечать за обмен данными с системой и преобразование форматов данных.

Для каждой системы выбирается одна технология обмена данными между системой и ServiceMix. Можно выбрать несколько, но это усложняет реализацию, как на стороне системы, так и на стороне ServiceMix. В общем случае использование нескольких разных технологий не оправдано, но технически вполне может быть реализовано. В основном для обмена с системами мы используем RabbitMQ (создаем наборы очередей, через которые ServiceMix обменивается сообщениями с интегрируемыми системами). Но встречаются и другие случаи, в которых нам очень помогает набор готовых адаптеров, который входит в состав ServiceMix. Например, в случае с нашей учетной системой мы используем хранимые процедуры в БД. Для вызова хранимых процедур используем компонент MyBatis, который позволяет маппировать сообщения, которые ходят по ServiceMix, на параметры хранимых процедур. Вот пример такого маппинга для процедуры установки логина пользователю по его ID:

Также адаптеры отвечают за преобразование форматов, в которых системы взаимодействуют с интеграционной платформой, к внутреннему формату. Кто-то предпочитает обмениваться в формате JSON, кто-то использует свой формат XML, но внутри интеграционной платформы компоненты обмениваются данными во внутреннем каноническом XML формате. Сейчас XML теряет популярность ввиду его тяжеловесности и появившихся альтернатив в виде JSON, Protobuf и т.д. Но, на мой взгляд, XML все же удобен для решения интеграционных задач. Есть много полезных технологий, таких как XSLT и XPATH, которые сильно упрощают жизнь, плюс он вполне человекочитаем.

Маршрутизация сообщений между компонентами (адаптерами) осуществляется на основании правил маршрутизации. Роуты внутри одного компонента интеграционной платформы взаимодействуют через внутренние эндпоинты Camel (direct, seda). Между собой компоненты обмениваются через очереди RabbitMQ. Это позволяет сделать компоненты интеграционной платформы независимыми. Падение одного компонента не влияет на работоспособность других. При временном повышении нагрузки сообщения будут накапливаться в очереди компонента, не оказывая влияния на весь остальной обмен.

Чем такая архитектура лучше, чем прямое взаимодействие между системами по принципу точка-точка:

Отказоустойчивость

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

Отказоустойчивость ServiceMix достигается за счет использования кластера из двух нод ServiceMix. При этом часть бандлов работают параллельно, если это допустимо. Например, адаптеры, которые читают одну RabbitMQ очередь, вполне могу делать это параллельно, одно сообщение всегда получит только кто-то один из них, но при этом сообщения будут равномерно распределяться между двумя нодами. В случае падения одной из нод всю нагрузку берет на себя вторая нода. Часть бандлов активна только на одной ноде, но при ее падении бандлы активируются на второй ноде. Например, в случае если адаптер читает общий сетевой каталог, то одновременное чтение одного и того же файла может привести к дублированию и коллизиям. Такой режим работы достигается за счет использования разделяемых блокировок на основе Hazelcast. Бандл, который первым захватил блокировку, переходит в активный режим и выполняет свою функцию, второй бандл висит в ожидании освобождения блокировки.

Hello world

В завершении хочу привести простой пример Hello world приложения на Camel, которое мы запустим на ServiceMix. Наше приложение будет просто один раз писать в лог ServiceMix фразу “Hello world” при запуске бандла (например, при деплое бандла или перезапуске ServiceMix).

HelloWorldRoute | 43 — org.apache.camel.camel-core — 2.16.3 | Hello world

Попробуйте зайти в ssh консоль и просмотреть список Camel контекстов context-list и список роутов route-list. В выводе команд вы найдете наши HelloWorldContext и HelloWorldRoute.

Источник