Integrace

Řešil jsem teď zajímavou filozofickou otázku. Potřeboval jsem v rámci integrace někam odkládat JMS zprávy, které se nepodařilo aplikačně zpracovat. Rozhodl jsem se je odkládat do speciální fronty, kterou jsem nazval Dead Letter Queue. Což je termín, který se používá na platformě WebSphere MQ. Naopak moje platforma je SOA Suite, která žádný podobný termín nemá (a řekl bych, že nejen termín, ale ani koncept).

Své řešení jsem hrdě (a úspěšně) představil v týmu a argumentačně ho podpořil tvrzením, že jde o vzor z Enterprise Integration Patterns (EIP). Tyto patterny jsou shrnuty v knížce, kterou vřele doporučuji - zcela jednoznačně jde o bibli messagingu.

Už je to nějaký čas, co jsem knížku četl a jelikož jsem si matně pamatoval, že ve skutečnosti jsou tam dva takové podobné vzory, znovu jsem si dané kapitoly pročetl. Co kdyby se vynořila nějaká zvídavá otázka :-) Po (znovu)přečtení jsem uvažoval, kterému vzoru se moje řešení více podobá - Dead Letter Channel nebo Invalid Message Channel? Ještě než se k těmto vzorům dostanu, předestřu, jak vypadá moje řešení.


Aniž bych zabíhal do přílišných podrobností. JMS listener vyčte zprávu z JMS fronty Input Queue a pošle ji ke zpracování do orchestrační/business logiky. Zde proběhnou validace zprávy, plus nějaká omáčka a pak jsou v rámci orchestrace volaný 3-4 externí služby (z diagramu vypuštěno). Pokud je během orchestrace vyhozena SOAP fault, zapíše se iniciální zpráva do JMS fronty Dead Letter Queue. Zároveň se do hlavičky zprávy přidá "uživatelská hlavičková vlastnost" (custom header property), kam se zapíše, ze které fronty byla zpráva původně vyčtena.

Nyní k oběma vzorům. První odstavec je definice vzoru a následuje signifikantní text, který jsem si podtrhl na  Kindlu. A obrázek :-)

Dead Letter Channel

"When a messaging system determines that it cannot or should not deliver a message, it may elect to move the message to a Dead Letter Channel."

"Typically, each machine the messaging system is installed on has its own local Dead Letter Channel so that whatever machine a message dies on, it can be moved from one local queue to another without any networking uncertainties. ... When the messaging system moves the message, it may also record the original channel on which the message was supposed to be delivered."

"Determining if a message should be moved to the Dead Letter Channel is an evaluation of the messages's header performed by the messaging system."

Vzor Dead Letter Channel (zdroj EIP)

Invalid Message Channel

"The receiver should move the improper message to an Invalid Message Channel, a special channel for messages that could not be processed by their receivers."

"An Invalid Message Channel is like an error log for messaging. When Something goes wrong in an application, it's a good idea to log the error. When something goes wrong processing a message, it's a good idea to put the message on the channel for invalid messages."

"If an error occurs while processing the message, the message is invalid and should be moved to the Invalid Message Channel. If it occurs while the application processes the data from the message, that is an application error that has nothing to do with messaging."

Vzor Invalid Message Channel (zdroj EIP)

Co to teda je?

Související články

• Enterprise integrace, messaging
• WebSphere MQ, interakce s Javou
• WebSphere MQ, vzdálené posílání zpráv
• 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.

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

<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.

Pokud se chceme k WebShere MQ (WMQ) připojit z Javy, máme k dispozici dvě možnosti - buď použít WMQ třídy pro Javu, nebo je možné komunikovat pomocí Java Message Service (JMS). Obě možnosti mají svoje pro a proti, takže krátké shrnutí v pár bodech:

• WMQ třídy pro Javu:
• zapouzdřují Message Queue Interface (MQI),
• poskytují plnou sadu funkčností WMQ,
• je to proprietární řešení, ale jednodušší k používání, než JMS.
• (WMQ třídy pro) JMS:
• Java “industry standard” pro messaging,
• je součástí Java EE specifikace (a tedy součástí většiny (Java) aplikačních serverů),
• umožňuje spravovat administrované objekty (connection factory, fronty ad.) v centrální repository.

package com.adastracorp.jprase.wmq.java;

import com.ibm.mq.MQMessage;
import com.ibm.mq.MQQueue;
import com.ibm.mq.MQQueueManager;
import com.ibm.mq.constants.CMQC;


public class JavaProvider {

    private static final String QM_NAME = “QM_JAVA”;
    private static final String HOSTNAME =
                                        “192.168.6.128”;
    private static final String CHANNEL =
                                        “JAVA.CHANNEL”;
    private static final int PORT = 5557;
    private static final String QUEUE = “JPRASE”;

    private static void init() {
        MQEnvironment.hostname = HOSTNAME;
        MQEnvironment.channel = CHANNEL;
        MQEnvironment.port = PORT;
    }

    public static void main(String[] args)
                                    throws Exception  {
        init();

        MQQueueManager queueManager =
                            new MQQueueManager(QM_NAME);
        MQQueue queue = queueManager
                        .accessQueue(QUEUE,
                                     CMQC.MQOO_OUTPUT |
                                     CMQC.MQOO_INQUIRE);

        MQMessage message = new MQMessage();
        message.writeUTF(“Hello, WMQ!");

        queue.put(message);

        queue.close();
        queueManager.disconnect();
    }
}

Chystám teď do firmy takovou kumulovanou prezentaci o Enterprise Integration Patterns (EIP), WebSphere MQ (WMQ) a WebSphere Message Brokeru (WMB), tak bych se chtěl postupně podělit o pár konceptů. První z nich je koncept remote messaging na WMQ.

Následující příklad předpokládá již hotovou instalaci WMQ a je zaměřen na komunikaci dvou instancí WMQ - jedna je na lokálním a jedna na vzdáleném prostředí. Pro vyzkoušení, nebo prezentaci je možné použít i jenom jedinou, lokální instanci. Nejdřív si na úvod definujeme základní komponenty, které bude potřeba vytvořit, a které spolu budou komunikovat:

Queue Manager
Správce front vlastní a spravuje fronty, kanály a další objekty. Je to první WMQ objekt, který je nutné na čisté instalaci vytvořit. Správce umožňuje další objekty vytvářet, konfigurovat, spouštět, vypínat atd. Pro přístup k frontám a zprávám poskytuje queue manager dvě rozhraní (API):

• Message Queue Interface (MQI) - proprietární rozhraní umožňující kompletní přístup k WMQ.
• Java Message Service (JMS) - Java specifikace pro asynchronní messaging.

Queue
Datová struktura pro ukládání zpráv. V našem příkladu budeme používat čtyři typy front:

• Local queue - lokální fronta pro ukládání zpráv.
• Remote queue - definice fronty, která je vlastněná jiným queue managerem.
• Transmission queue - (lokální fronta,) dočasné úložiště zpráv určených pro vzdáleného queue managera.
• Dead-letter queue - lokální fronta určená pro nedoručitelné zprávy.

Barevně jsou vyznačeny nově vytvářené objekty. V případě, že existuje pouze jedna (lokální) instance WMQ, je možné oba queue managery vytvořit lokálně. Obecný postup vytvoření objektů je následující:

1. Vytvoření queue managera.
2. Vytvoření dead-letter queue.
3. Vytvoření local (remote) queue.
4. Vytvoření transmission queue.
5. Vytvoření message channelu.
6. (Spuštění sender message channelu.)

Jelikož nejde o tutoriál, nebudu popisovat vytvoření jednotlivých objektů - to je dobře popsáno v dokumentaci. Pouze bych zde zmínil, že všechny uvedené objekty lze vytvořit dvěma způsoby - buď pomocí grafického rozhraní MQ Explorer (velice snadné), nebo pomocí MQ Script Commands (MQSC).

Výsledná architektura vypadá takto:


A k čemu je to vůbec dobré, posílat zprávu z jednoho queue managera na jiný? Jenom čistě pro posílání zpráv to samozřejmě smysl nemá - na to by stačily fronty definované v rámci jednoho queue managera, ke kterým by se připojovali komunikující konzumenti a provideři.

Smysl to začíná dávat v momentě, pokud potřebuje komunikovat více queue managarů, např. z důvodů high availability, škálovatelnosti apod.

Messaging může být jedním ze způsobů integrace enterprise komponent. Jaké jsou základní koncepty messagingu? (A knížka jako bonus.)