Von ActiveMQ zu echtem IBM MQ: was sich wirklich aendert

Beispiel: IbmMqRequestReplyIT (novaris-integration-tests) gegenueber den ActiveMQ- basierten Tests aus Phase 1-3 (ClaimSubmissionRequestReplyTest, NotificationTopicFanoutTest).

Was sich NICHT aendert

Der gesamte Anwendungscode - ClaimIntakeMDB, ClaimSubmissionClient, PolicyEventPublisherBean, PolicyDocumentGenerationMDB, CustomerNotificationMDB - bleibt vollstaendig unveraendert. Er ist ausschliesslich gegen die Standard-javax.jms-API programmiert (ConnectionFactory, Session, MessageProducer, MessageConsumer, ...) - genau das ist der Sinn eines JMS-Standards: der Provider dahinter ist austauschbar. Das war das Versprechen der ActiveMQ-Ersatzloesung in den fruehen Phasen, und IbmMqRequestReplyIT belegt es konkret: derselbe Request/Reply-Mechanismus (JMSReplyTo, JMSCorrelationID, Message-Selektoren), nur gegen einen echten IBM-MQ-Container statt eines eingebetteten ActiveMQ-Brokers.

Was sich aendert: die Client-Konfiguration

MQConnectionFactory connectionFactory = new MQConnectionFactory();
connectionFactory.setHostName("localhost");
connectionFactory.setPort(mappedPort);
connectionFactory.setChannel("DEV.APP.SVRCONN");
connectionFactory.setQueueManager("QM1");
connectionFactory.setTransportType(WMQConstants.WMQ_CM_CLIENT);

IBM MQ kennt Konzepte, die ActiveMQ (und die meisten anderen JMS-Provider) nicht in dieser Form haben:

Queue-Manager - eine benannte administrative Einheit, die eine oder mehrere Queues/ Topics besitzt. Jede Verbindung geht an einen bestimmten Queue-Manager, nicht "an den Server" allgemein.
Kanal (Channel) - ein benannter Kommunikationsweg zwischen Client und Queue-Manager (hier: DEV.APP.SVRCONN, ein Server-Connection-Kanal fuer Client-Verbindungen). Kanaele tragen eigene Sicherheitsregeln (CHLAUTH) - siehe naechster Abschnitt.
WMQ_CM_CLIENT - der "Client"-Transportmodus (TCP/IP-Verbindung zu einem entfernten Queue-Manager), im Gegensatz zum "Bindings"-Modus (direkter In-Process-Zugriff, nur wenn Anwendung und Queue-Manager auf demselben Server laufen - historisch der Standardfall fuer WebSphere-Anwendungen, die auf demselben Server wie ihr MQ liefen).

Ein echter, waehrend der Entwicklung gefundener Stolperstein: CHLAUTH

Der erste Versuch, IbmMqRequestReplyIT auszufuehren, scheiterte mit MQRC_NOT_AUTHORIZED (2035), obwohl der Container laengst lief. Grund: neuere IBM-MQ- Dev-Images verlangen per Default eine authentifizierte Verbindung selbst fuer den eigentlich "offenen" Entwickler-Kanal DEV.APP.SVRCONN (Channel Authentication Records, CHLAUTH) - anonyme Verbindungen werden abgelehnt. Der Fix: den Container mit -e MQ_APP_PASSWORD=... starten und sich explizit als Benutzer app mit diesem Passwort verbinden (connectionFactory.createConnection("app", password)), statt der parameterlosen createConnection().

Warum das ein guter Fund ist, kein Makel: genau solche Details - Sicherheits-Defaults aendern sich zwischen Produktversionen, Dokumentation hinkt manchmal hinterher - sind Alltag in echten IBM-MQ-Projekten. Wer nur mit einem generischen JMS-Provider (wie dem ActiveMQ-Ersatz) gearbeitet hat, waere davon in einer echten IBM-MQ-Umgebung ueberrascht worden. Dieser Fund ist deshalb selbst Teil des Lernwerts von Phase 5.

⌂ Cockpit