ServiceMix Atomikos XA transaction JDBC JMS

Снова вернемся к важному вопросу о XA транзакциях. Рассмотрим реализацию XA транзакций с использованием популярного менеджера распределенных транзакций Atomikos. Это широко используемый диспетчер транзакций JTA с открытым исходным кодом, который предназначен для сред отличных от J2EE. Это как раз наш случай.
В данном примере будет представлена готовая конфигурация транзакций.
Приложение разделено на модули, которые разделяют настройку ресурсов, от бизнес логики. Фактически вы можете установить модули в ServiceMix и заняться разработкой, не разгребая как во многих других примерах системную и бизнес логику.
Итак модули:

1. ts - поднимает транзакционные артефакты JtaTransactionManager, UserTransactionManager, UserTransactionImp
2. ds - поднимает транзакционный источник данных на примере БД Oracle OracleXADataSource, AtomikosDataSourceBean
3. amq - поднимает транзакционные артефакты для работы с JMS на примере ActiveMQ, ActiveMQXAConnectionFactory, AtomikosConnectionFactoryBean
4. testXA - приложение для ServiceMix демонстрируещее работающие транзакции 

Контекст модуля ts определяет два бина txMgr и userTransaction. Классы реализации предоставляются Atomikos и реализуют интерфейсы TransactionManager и UserTransaction из стандарта J2EE. После этого определяется бин jtaTxMgr с классом реализации JtaTransactionManager и внедряются два бина транзакций предоставляемые Atomikos. Это информирует Spring о необходимости использования Atomikos JTA для управления транзакциями. Далее сконфигурированный менеджер транзакций выставляется как osgi-сервис, чтобы позволить другим модулям его переиспользовать.

Authentication and authorization ActiveMQ

Итак, если вам надо управлять доступом к очередям на ActiveMQ, предоставляю пример как это можно сделать. Может кому пригодится. В файле activemq.xml делаем следующее

<plugins>
 <simpleAuthenticationPlugin>
  <users>
   <authenticationUser username="admin" password="admin" groups="producers,consumers,admins" />
   <authenticationUser username="producer" password="producer" groups="producers" />
   <authenticationUser username="consumer" password="consumer" groups="consumers" />
  </users>
 </simpleAuthenticationPlugin>
 <authorizationPlugin>
  <map>
   <authorizationMap>
    <authorizationEntries>
     <authorizationEntry queue=">" write="producers" read="consumers" admin="admins" />
     <authorizationEntry topic="ActiveMQ.Advisory.>" write="producers,consumers" read="producers,consumers" admin="admins" />
    </authorizationEntries>
    <tempDestinationAuthorizationEntry>
     <tempDestinationAuthorizationEntry write="producers" read="consumers" admin="admins" />
    </tempDestinationAuthorizationEntry>
   </authorizationMap>
  </map>
 </authorizationPlugin>
</plugins>

Теперь положить сообщение в очередь может пользователь producer, а прочитать consumer

Best practices ServiceMix and Apache Camel

В этой статье я решил поделится всеми своими рекомендациями при разработке с применением ServiceMix и Apache Camel. По мере развития статья будет дополняться.

• Используйте Spring DSL вместо Java DSL. Это позволит в некоторых случаях при необходимости вести разработку в обычном текстовом редакторе, избавит вас от format-hell. Так же в силу древовидности XML вам не придется использовать костыли по типу end(), которые вы вынуждены вставлять чтобы контролировать блоки кода.
• При подключении к ActiveMQ всегда используйте failover (failover:tcp://127.0.0.1:61616)
• При использовании файлового адаптера читающего файлы из директории, всегда подключайте фильтр на проверку пустого файла.

  import org.apache.camel.component.file.GenericFile;
  import org.apache.camel.component.file.GenericFileFilter;
  import org.apache.log4j.Logger;
  
  public class EmptyFilter<T> implements GenericFileFilter<T> {
   private static Logger log = Logger.getLogger(EmptyFilter.class);
  
   public boolean accept(GenericFile<T> file) {
    boolean res = false;
    if (!file.isDirectory()) {
     if (file.getFileLength() > 0) {
      res = true;
     }
    }
    return res;
   }
  }
  
  

  Иcпользование:
  

  file:{{inbox}}?filter=#emptyFilter
  

ActiveMQ Master/Slave and load balancer cluster

Пришло время объединить все технологии кластеризации ActiveMQ вместе, и продемонстрировать систему устойчивую к сбоям и позволяющую распределять нагрузку. Для примера построим архитектуру кластера на базе 8 инстансов ActiveMQ. Схема выглядит следующим образом.

Рассмотрим детально:

• Инстансы связаные общим хранилищем Master/Slave 1-2, 3-4, 5-6, 7-8. По идее каждая пара разворачивается на отдельной машине. Для возможности развертывания на отдельной машине, все инстансы разнесены по портам.
• С помощью Network Broker каждая пара с связана с каждой парой.
• Для каждой пары на этом же хосте, с помощью Apache Camel поднимается HTTP точка, принимающая запросы от внешнего балансировщика и прокидывающая запрос в очередь.
• Все инстансы из каждой группы могут делиться сообщения с другими группами
• Отдельные клиенты разворачиваются каждый на своем хосте и читают сообщения и очереди.
• Балансировщик для простоты тоже реализован с помощью Apache Camel

Ниже можно взглянуть на настройки каждого инстанса и исходный код.

ActiveMQ Master/Slave and Broker Networks cluster

В предыдущей статье мы рассмотрели высоко-нагруженый кластер ActiveMQ для распределения нагрузки. Однако эта конфигурация все таки обладает следующим недостатком. При выходе из строя одного из узлов ActiveMQ, сообщения размещенные в нем становятся более недоступны, и будут вычитаны только после того как конкретный инстанс ActiveMQ будет снова поднят. Проблема может быть решена с помощью конфигурации Master/Slave, в которой два, или больше инстанса ActiveMQ имеют общее хранилище. Пара Master/Slave может быть связана с аналогичной парой, размещенной на другом хосте, и связаны с помощью  Broker Networks. Схематично это выглядит следующим образом.
Для простоты развертывания все производится на одной машине. Инстансы ActiveMQ инстансы разделены по портам.

Ниже будут представлены настройки каждого из узлов кластера

ActiveMQ high availability load balancer cluster

Рассмотрим актуальную задачу Load Balancer между инстансами ActiveMQ. Балансировка в таком случае строиться с помощью networkConnectors. Для простоты развертывания инстансы ActiveMQ развернем на одной машине, разделение будет строиться на базе портов. Вот схематичное представление кластера:

Конфигурация каждого инстанса ActiveMQ представлена ниже: