ActiveMQ, messaging podle Apache

Poslední dobou jsem se zabýval integračním projektem, který používal komerční technologii od IBM - WebSphere Messaage Broker, který jako infrastrukturu využívá WebSphere MQ. Abych měl, jako solution architekt, k tomuto řešení nějakou alternativu, rozhodl jsem se nastudovat open source messagingovou platformu ActiveMQ od Apache Software Foundation (ASF).

ActiveMQ je messagingový server postavený nad specifikací Java Message Service (JMS), a který ve spojení i frameworkem Apache Camel implementuje Enterprise Integration Patterns (EIP). Obecné vlastnosti ActiveMQ se dají shrnout do následujících bodů:

• implementace JMS 1.1,
• integrace se Springem,
• integrace s (Java) aplikačními servery,
• vlastní protokol OpenWire pro high perfomance klienty v Javě, C, C++ a C#,
• embedded broker,
• broker clustering,
• REST API,
• AJAX API,
• ad.

Výborným zdrojem informací je kniha AcitveMQ in Action přímo od autorů a přispěvatelů ActiveMQ. Vypíchnul bych z ní pár momentů, které mne zaujaly.

Komunikační protokoly
Klienti se můžou k brokeru připojit pomocí různých protokolů, které jsou vystaveny pomocí tzv. transportních konektorů. Mmj. jsou k dispozici obligátní:

• TCP
• SSL
• HTTP(S)
• UDP

Pokud klient i broker běží v jednom JVM, může klient použít VM protokol, který spustí embedded broker. Komunikace pak neprobíhá po síti, jako u ostatních typů konektorů, ale klient volá přímo metody na objektu (instanci) brokeru.

Pro konfiguraci konektoru se používá následující URI:

• scheme://host:port?queryKey=queryValue

Konfigurace několika konektorů pak může vypadat třeba takto:

<transportConnectors>
    <transportConnector
        name="openwire"
        uri="tcp://localhost:61616?trace=true"/>
    <transportConnector
        name="ssl"
        uri="ssl://localhost:61617"/>
    <transportConnector
        name="vm"
        uri="vm://localhost"/>
</transportConnectors>

Message Storage
JMS specifikace definuje dva způsoby doručení zpráv (DeliveryMode) - perzistentní a neperzistentní. Pokud jsou zpráva, nebo producent nastavený jako perzistentní, musí JMS provider zajistit bezpečné uložení zpráv (aby např. přežily výpadek serveru). ActiveMQ nabízí pro uskladnění zpráv čtyři strategie:

• KahaDB message store. Rychlá a škálovatelná file-based perzistence s transakčním žurnálem a rychlým zotavením.
• AMQ message store. Předchůdce KahaDB, obdobné vlastnosti.
• JDBC message store. Perzistence zpráv do relační databáze.
• Memory message store. Všechny pezistentní zprávy jsou drženy v paměti, tj. nejsou perzistovány ve smyslu JMS specifikace.

KahaDB se skládá ze tří komponent:

• Cache drží zprávy pro aktivní konzumenty.
• Data logy slouží jako transakční žurnál. Obsahují uložené zprávy a transakční příkazy.
• BTree indexy referencují zprávy v data logu.

Schéma KahaDB  (zdroj ActiveMQ in Action)

REST API
ActiveMQ poskytuje jednoduché API pro publikaci a konzumaci zpráv RESTovým způsobem. Vzhledem k tomu, že JMS poskytuje pouze dvě operace - send a receive - je mapování na HTTP velmi přímočaré. Pro publikování zpráv je to (HTTP) POST, pro jejich konzumaci (HTTP) GET nebo DELETE.

Mapování na URI pak vypadá takto:

• http://host:port/queue
• http://host:port/topic/subtopic

High Availability
Pokud budeme chtít zajistit vysokou dostupnost našeho messagingového řešení, budeme potřebovat několik brokerů běžících na různých strojích. Něco jako:

High Availability v režii ActiveMQ je zajištěna dvěma typy Master/Slave konfigurací:

• Shared nothing
• Shared storage

U shared nothing konfigurece má master i slave vlastní message store. Slave se po startu připojí k masteru a veškeré stavy masteru (zprávy, akcknowledgements, transakce atd.) jsou replikovány na slave. Když master spadne, jsou všichni klienti přesměrováni (pomocí fail over protokolu) na slave, který se stává novým masterem. Konfigurace fail over protokolu vypadá takto:

• failover://(tcp://master:61616,tcp://slave:61616)

Omezením tohoto řešení je, že master může mít definovaný pouze jeden slave (a slave nemůže mít definovaný další vlastní slave).

Shared nothing master/slave (zdroj ActiveMQ in Action)

Shared storage konfigurace umožňuje, aby bylo definováno více slave brokerů, které spolu s masterem, sdílejí společný storage mechanismus - tím může být sdílený filesystem, nebo relační databáze. Master má pak storage zamknutý. Když master spadne, jeden ze slave brokerů se stane novým masterem a zamkne si storage pro sebe.

Shared storage master/slave (zdroj ActiveMQ in Action)

Závěrem
Pokud to mám říct jednou větou - ActiveMQ se mi architektonicky/technologicky líbí a pokud bych na nějakém projektu potřeboval řešit messaging v Javě, určitě by to byl žhavý kandidát. Taky mi to nedá, abych nesrovnal ActiveMQ s WebSphere MQ. Co se týče funkčností, jsou obě řešení srovnatelná. Veliký rozdíl ovšem bude v pracnosti a nákladech - ActiveMQ půjde implementovat nesrovnatelně levněji a rychleji. No a samozřejmě cena, zde je rozdíl astronomický - ActiveMQ je zdarma, WebSphere MQ bude stát řádově miliony korun jenom na licencích.

Další cesta, jak rozvíjet znalosti o ActiveMQ je celkem jednoznačná - Apache Camel, což je implementace EIP od ASF, která řeší věci jako vytváření zpráv, jejich směrování, transformaci, orchestraci ad.