Overview
This is a typical engagement for a regional insurer, or any team with a TIBCO EMS estate behind policy, claims and billing applications, that wants to move to RabbitMQ and cannot stop the business to do it. EMS has run for years, some applications have been touched by nobody recently, and the renewal question has made the move a project.
Challenge
JMS applications that only send and receive move with small changes. The hard cases are the ones that use features RabbitMQ's JMS client documents as limited: XA interfaces are not implemented, local transactions do not guarantee atomicity, and message selectors for queues are not supported by the client. Nobody knows which applications use which. The estate also mixes the javax.jms and jakarta.jms namespaces, which EMS supports through two jar sets.
Environment
A TIBCO EMS server pair with queues and topics, durable subscribers, a mix of Java applications on different JMS namespaces and Java versions, and a RabbitMQ target cluster to be built alongside.
Approach
The engagement starts with an inventory from the server configuration and from application code, then records the JMS features each application uses. Each feature is set against the RabbitMQ JMS client documentation and, for streaming flows, Kafka. The result is a gap list with a decision for each gap: redesign, workaround, or leave the application on EMS for now. Applications then move in waves with old and new brokers in parallel.
Solution
- Inventory queues, topics, durable subscribers, routes, connection factories and every connecting application
- Record JMS feature use per application: transactions, selectors, queue browsing, acknowledgement mode, client identifiers and namespace
- Map each feature to the RabbitMQ JMS client documentation and decide redesign, workaround or stay for each gap
- Route streaming and replay requirements to Kafka and queued work and request-reply to RabbitMQ, flow by flow
- Choose a bridge or dual-publish pattern per flow so applications can move one at a time
- Rehearse failure on the target: broker loss, consumer reconnection and restart
- Reconcile counts and ordering per flow, and write the rollback for each wave before it starts
Outcome
The engagement delivers a complete inventory of the EMS estate, a per-application JMS gap list with a decision for each gap, a target choice per flow, a wave plan with a rollback for each wave, and a rehearsed first migration. Surprises are found in the plan rather than in production.
Technologies
RabbitMQJMS
IBM MQ
Kafka
Docker
PostgreSQL
Kubernetes
MariaDB
