A JMS bridge connects existing messaging workloads to Azure Service Bus while their applications continue to use their current broker. In this post, we look at an on-premises IBM MQ application sending order events to a workload in Azure through Azure Service Bus Premium. IBM MQ is one example; the same pattern applies to other JMS-compatible messaging systems.

Connect the two messaging systems

Java Message Service, or JMS, provides a common Java API for sending and receiving messages. Each provider supplies a client library and connection factory for its messaging system. The bridge uses the IBM MQ connection factory to receive messages and the Service Bus connection factory to forward them over AMQP 1.0. For our example, the application sends order events to a dedicated MQ integration queue. The bridge forwards them to a Service Bus queue, where the Azure workload receives and processes them.

Order events flow from an on-premises application through a dedicated IBM MQ integration queue and a standalone JMS bridge to a Service Bus queue and Azure workload. The bridge connects to Service Bus over AMQP 1.0 over TLS.

Once the bridge acknowledges a message, MQ removes it from the source queue. If the bridge shares that queue with an existing consumer, they compete for messages. Where both need every event, deliver a copy to each consumer's queue.

Use a Jakarta-compatible JMS bridge

Apache Artemis provides a JMS bridge that can run as a standalone application. MQ and Service Bus are the two brokers in this setup; you do not need an Artemis broker between them. The Jakarta version of the bridge is available in the artemis-jakarta-server module. Pair it with the IBM MQ Jakarta Messaging client and com.azure:azure-servicebus-jms, our Service Bus JMS library. All three use the jakarta.jms API namespace.

Configure an MQ-to-Service Bus path

Create a Service Bus Premium namespace and a target queue named orders-from-mq. For the MQ source, use a dedicated integration queue named ORDERS.FOR.CLOUD. The bridge needs a connection factory and destination for each side:

For the Service Bus connection, follow our JMS connection factory guidance to supply a Microsoft Entra ID credential. Assign the bridge identity the Azure Service Bus Data Sender role on the target queue. Use these factories and destinations to configure Artemis's JMSBridgeImpl, then start the bridge. The Artemis configuration reference covers the remaining parameters, including batching and reconnection settings.

Run the bridge on-premises

Running the bridge on-premises keeps the MQ connection on the local network. The bridge opens an outbound connection to Service Bus, so the Azure workload does not need direct access to MQ. The same pattern can carry messages in the other direction. A second bridge receives from Service Bus and forwards to MQ, using separate queues for the return path.

Allow for duplicate messages

With DUPLICATES_OK, the bridge acknowledges the MQ message after sending it successfully to Service Bus. If it stops before that acknowledgment reaches MQ, the message can be forwarded again after recovery.

Additionally, carry the same order event ID through each retry. If forwarded messages use that ID as their MessageId, enabling duplicate detection on the Service Bus queue filters repeated sends within its configured window. The receiving workload can use the same event ID to recognize completed work and avoid creating a second order if a duplicate still reaches it.

More information

More information can be found in the Apache Artemis JMS bridge documentation and the Azure Service Bus JMS developer guide.