Book a consultation

Solace Protocols and APIs: MQTT, JMS, AMQP, REST and Kafka on One Broker

Solace JMS, AMQP and REST: The Enterprise Protocols Explained

Solace JMS explained: the JMS 1.1 and Jakarta APIs, AMQP 1.0 with Qpid, REST messaging and microgateway modes, and migrating from other JMS brokers.

Vladimir Romanov

Solace JMS support comes in two Java APIs, the Solace JMS API in the javax.jms namespace and the Solace Jakarta Messaging API in jakarta.jms, and Solace’s documentation states that “both namespaces provide the same JMS 1.1 functionality” (Solace JMS API). Next to it sit two more enterprise paths: AMQP 1.0, which lets open-source clients such as Apache Qpid JMS connect, and REST messaging, which turns an HTTP POST into a topic or queue message. Together they are how existing enterprise applications reach a Solace Event Broker without a Solace-specific rewrite.

This page explains each, how they differ, and what to test when moving from another JMS broker. It belongs under Solace protocols and APIs in the Solace cluster.

Solace JMS: what the APIs provide

ItemWhat Solace documents
SpecificationJMS 1.1 functionality in both the javax and jakarta namespaces
Migration between namespaces“Existing JMS code continues to work without changes”, with updated imports for jakarta.jms
Administered objectsConnection factories and destinations through Solace JNDI objects
Application serversA JCA resource adapter for Jakarta Messaging and one for JMS on older Java EE servers
Wire protocolSMF, so applications get the broker’s full feature set
EndpointsQueues, plus topic endpoints, which Solace recommends using only for JMS durable topic subscribers

Sources: Solace JMS API; endpoints.

Why JMS 1.1 is less limiting than it sounds. Most enterprise JMS code in the field, including MES and ERP adapters written a decade ago, uses the 1.1 model: connections, sessions, producers, consumers, selectors and transacted sessions. The JMS 2.0 additions (the simplified JMSContext API, shared topic subscriptions, delivery delay) matter for newer code. For those, the documented route is Apache Qpid JMS over AMQP 1.0 (component maps).

JMS messages are ordinary Solace messages. A JMS producer publishing to a topic reaches MQTT, AMQP, REST and SMF subscribers, and a queue attracting that topic delivers to JMS consumers with guaranteed messaging. This is what makes Solace JMS useful in a plant: an MES that only speaks JMS can consume events published by an edge gateway over MQTT.

Migrating to Solace JMS from another broker

Solace runs an explicit TIBCO EMS displacement programme and states that native JMS support means no application code changes (Solace for TIBCO EMS). That is a vendor claim; standard JMS code generally does move with configuration changes, and the work concentrates elsewhere. A sequence that keeps risk visible:

  1. Inventory destinations and features. Queues, topics, durable subscribers, selectors, transactions, message sizes and any vendor-specific extension classes.
  2. Map destinations onto Solace. Queues stay queues. Topics need a hierarchy, since Solace topics are /-separated levels; flat names like PLANT1.QUALITY.HOLD should be redesigned rather than copied. See topics and wildcards.
  3. Swap JNDI and connection factories. This is usually the only change most applications need.
  4. Test behaviour, not just connectivity. Redelivery counts, dead message queues, selector performance on deep queues, and failover with in-flight transactions.
  5. Run in parallel on one representative application before moving the rest.

The broker-to-broker comparisons are on Solace vs TIBCO and Solace vs IBM MQ.

AMQP 1.0: the open-standard path

Solace supports AMQP 1.0 over TCP and TLS, for persistent messaging, with samples that use Apache Qpid JMS and Qpid Proton (component maps). The 10.26.0 long-term release added W3C trace context for AMQP, so AMQP messages can join OpenTelemetry traces (10.26.0).

Code editor in a dark theme showing a project file tree and source code
With JMS, AMQP and REST, application code stays on a standard interface; the Solace-specific part shrinks to connection settings that operations can change.

Choose AMQP when portability is the priority: application teams that want to avoid a Solace client library, or code that may later run against another AMQP 1.0 broker. Watch the dialect. AMQP 0-9-1, the protocol most RabbitMQ clients speak, is a different protocol and is not supported.

REST messaging: messaging mode and microgateway mode

REST lets anything that can send HTTP talk to the broker. Solace documents two modes (REST encoding):

  • Messaging mode. The POST path names the destination: /QUEUE/queue-name enqueues, /TOPIC/topic-string publishes, and with neither prefix the broker assumes /TOPIC/. Delivery defaults to persistent. For persistent messages the broker returns 200 OK only after the message is stored.
  • Microgateway mode. The broker publishes each request to a topic built from the method and path, such as POST/orders, so a service subscribed to that topic can answer. Delivery defaults to direct.

The Solace-Delivery-Mode header overrides the default with Direct, Non-Persistent or Persistent. Other headers carry correlation IDs, reply-to destinations, time to live and dead-message-queue eligibility. Request-reply works synchronously, with the broker holding the HTTP response until a reply arrives, or asynchronously to a reply destination. Outbound, REST Delivery Points post messages from queues to web servers (REST overview).

From an HTTP POST to JMS, AMQP and webhook consumers A REST producer sends an HTTP POST to the path /TOPIC/site1/quality/hold. The Solace Event Broker, in messaging mode, maps the path to the topic site1/quality/hold, stores the message because delivery is persistent by default, and only then returns 200 OK to the producer. Queues subscribed to the topic deliver the message to a JMS consumer in the MES and to an AMQP 1.0 client. A REST Delivery Point takes messages from a third queue and posts them over HTTP to a webhook on an external web server. REST producer POST /TOPIC/site1/quality/hold 1 3. 200 OK, after the message is stored Solace Event Broker Messaging mode: path to site1/quality/hold 2. Persistent by default: stored on the spool Queues subscribed to the topic MES JMS consumer on a queue Quality app AMQP 1.0 client REST Delivery Point HTTP POST to a webhook One HTTP request in, three consumers out, each on its own protocol and its own queue. Microgateway mode differs: the topic is built from method and path, for example POST/orders.
REST is the simplest way into the broker. The 200 OK after storage is what makes an HTTP publish safe to rely on for records such as quality holds.

A plant example: three protocols, one event

An illustrative scenario, not a description of any one project.

A packaging plant wants a quality hold raised on the line to stop shipments within minutes. Three systems are involved, and none of them can be changed much:

  1. The line’s quality station is a small web application. It can make an HTTP call and nothing else, so it posts the hold to /TOPIC/site1/quality/hold in messaging mode and retries on anything but 200 OK.
  2. The MES has a JMS adapter written years ago against another broker. After a connection factory and JNDI change, it consumes the same event from a queue subscribed to site1/quality/>.
  3. The warehouse system’s vendor offers only an inbound webhook. A REST Delivery Point posts each hold to it from its own queue, so a slow vendor endpoint backs up only that queue.

The point is not the protocols, it is the isolation. Each consumer has its own queue, so a slow or offline system delays only itself, and the event is stored once and delivered three times. Designing that kind of boundary between plant and business systems is the core of our IT/OT integration work.

Solace JMS, AMQP and REST compared

JMS / Jakarta (Solace API)AMQP 1.0 (open clients)REST
ClientSolace Java librariesQpid JMS, Qpid Proton and othersAny HTTP client
PortabilityStandard JMS code, Solace providerHighestHigh; Solace paths and headers
FeaturesFull broker feature set over SMFPersistent messagingPublish, request-reply, outbound delivery
ThroughputHighHighLowest: one HTTP request per message
Best fitExisting Java EE and MES integrationTeams avoiding vendor librariesScripts, SaaS webhooks, low-volume systems

For Spring and Quarkus integrations, and the other language APIs, see the sibling page on Solace SDKs.

Where it gets hard

  • Vendor extensions. Code that uses TIBCO or IBM extension classes is not plain JMS and will need changes.
  • Flat topic names. Copying dotted JMS topic names into Solace loses wildcard routing. Redesign the hierarchy once.
  • Selectors at scale. A selector on a deep queue makes the broker inspect messages; prefer topic-based filtering into separate queues.
  • REST error handling. A client that ignores non-200 responses loses messages silently. Treat anything but 200 as a retry.
  • Slow webhooks. A REST Delivery Point is only as fast as the web server behind it. Watch the queue depth behind each one.

Related: the Kafka integration page for the streaming side, and the Solace hub.

Frequently asked questions

Which JMS version does Solace support?

Solace's own JMS API and its Jakarta Messaging API both provide JMS 1.1 functionality; Solace's documentation says both namespaces offer the same JMS 1.1 features. Applications that need the JMS 2.0 programming model can use the open-source Apache Qpid JMS client over AMQP 1.0, which Solace's samples show connecting to the broker. Check which features your code uses before choosing.

Can I migrate from TIBCO EMS or IBM MQ to Solace JMS without code changes?

Solace states that its native JMS support means EMS applications can move without application code changes. In practice, standard JMS code usually needs only new connection factories and JNDI entries, while vendor-specific extensions, selectors on high-volume queues, transaction behaviour and administration scripts need testing and sometimes rework. Plan a pilot on one representative application first.

How does Solace REST messaging work?

In messaging mode, a client sends an HTTP POST to a path that starts with /TOPIC/ or /QUEUE/, and the broker publishes the body to that topic or queue. For persistent messages the broker returns 200 OK only after storing the message. To deliver messages out to HTTP endpoints, you configure a REST Delivery Point that posts each message to a web server.

What is Solace microgateway mode?

Microgateway mode turns the broker into a lightweight HTTP gateway. Instead of reading /TOPIC/ or /QUEUE/ from the path, the broker publishes each request to a topic built from the HTTP method and path, such as POST/orders, so a back-end service can subscribe to it and reply. Messages default to direct delivery in this mode, unlike messaging mode.

Does Solace support AMQP 0-9-1 for RabbitMQ clients?

No. Solace documents AMQP 1.0, over TCP and TLS. AMQP 0-9-1 is a different protocol that RabbitMQ clients typically use, and those clients will not connect to a Solace broker. Moving a RabbitMQ application usually means switching to an AMQP 1.0 client, MQTT, or a Solace API, and remapping exchanges and bindings onto Solace topics and queues.

References and further reading

  1. Solace JMS API and Jakarta Messaging API · SolaceStates the JMS 1.1 scope, JNDI and the JCA resource adapters.
  2. Solace REST messaging overview · Solace
  3. Solace REST HTTP message encoding · SolaceThe /TOPIC/ and /QUEUE/ paths, microgateway mode and the Solace headers.
  4. Component maps: protocols and APIs · Solace
  5. Solace for TIBCO EMS · SolaceThe vendor's own migration claims, to read with that in mind.

← Protocols and APIs

Have a project that needs technical ownership?

Send us the situation. If it is not something we should take on, we will say so.

Book a consultation Contact