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

Solace protocols are the reason many architects shortlist the Solace Event Broker in the first place. One broker accepts Solace’s own SMF protocol plus the open standards MQTT 3.1.1 and 5.0, AMQP 1.0, REST over HTTP and WebSocket, serves JMS and Jakarta Messaging applications through its Java APIs, and connects to Kafka through bridging, a proxy or connectors. Because every message is converted to one internal format and routed by topic, an MQTT publish from a line gateway can reach a JMS application, a REST endpoint and a Kafka topic without a separate integration server in between (Solace component maps; Solace Event Broker).

This page explains how that translation works, which protocol or API suits which application, and the documented limits as of October 2026. It sits in the Solace cluster; the four pages under it go deeper on MQTT, JMS and REST, Kafka and the SDKs.

How Solace protocols work on one broker

Everything becomes SMF inside. SMF, the Solace Message Format, is the broker’s native binary protocol, carried over TCP, TLS or WebSocket. When a client connects over MQTT, AMQP or HTTP, the broker terminates that protocol at the edge of the broker and converts the message to SMF for routing (component maps). A Wireshark dissector for SMF exists in SolaceLabs for anyone who needs to see it on the wire.

Topics are the common currency. Routing does not care which protocol a message arrived on. It cares about the topic string and which subscriptions match it. An MQTT topic like site1/packaging/line3/filler/state is a valid Solace topic, and a queue can subscribe to it so that a JMS consumer receives the same events with guaranteed delivery. The messaging model page explains topics, queues and the exchange patterns.

Payloads pass through; metadata is translated. The body bytes travel unchanged. Headers, user properties, correlation IDs, reply-to addresses and quality-of-service levels are mapped from one protocol’s model to another’s, and the maps are not always one to one. An MQTT 5 user property, a JMS property and an HTTP header are three different things that the broker reconciles as best it can.

The Solace protocols compared

The table summarises what Solace documents for each protocol, what usually connects over it, and the point to check first. Versions are as of October 2026.

Protocol	Versions and transports	Typical clients	Best fit	Check first
SMF	Solace native; TCP, TLS, WebSocket	Solace APIs in C, Java, .NET, Python, Go, JavaScript, Node.js	Full feature set, lowest latency	It ties code to Solace’s APIs
MQTT	3.1.1 and 5.0; TCP, TLS, WS, WSS	Edge gateways, Ignition, devices, Eclipse Paho	Plant telemetry, unified namespace feeds	QoS 2 becomes QoS 1; retained messages are Controlled Availability
AMQP	1.0; TCP, TLS	Apache Qpid JMS and Proton	Portable enterprise apps, JMS 2.0 style code	Not AMQP 0-9-1 (the RabbitMQ dialect)
JMS / Jakarta	JMS 1.1 functionality, javax and jakarta namespaces	Java EE and Jakarta EE servers, Spring	Migrating from TIBCO EMS, IBM MQ JMS, ActiveMQ	JMS 2.0 features come through Qpid over AMQP, not Solace’s API
REST	HTTP POST in; REST Delivery Points out	Scripts, SaaS webhooks, appliances	Low-volume integration without a client library	One request per message limits throughput
WebSocket	SMF or MQTT over WS and WSS	Browsers, mobile web	Live dashboards and operator screens	Firewall and proxy rules for long-lived connections
Kafka	Bridging, wireline proxy, connectors	Kafka clusters and clients	Feeding analytics, coexisting with Kafka	In-broker bridging is documented for software brokers only

Sources: Using MQTT, component maps, Solace JMS API, REST encoding, Kafka bridging.

Why the breadth matters to a plant. A manufacturer rarely gets to choose one protocol. Line equipment and edge software speak MQTT. The MES vendor ships a JMS adapter. The ERP integration team prefers REST. The data platform team runs Kafka. Without a multi-protocol broker, each pair needs its own bridge, and every bridge is a component someone has to patch, monitor and explain during an outage. Our IT/OT integration work starts by drawing exactly that map.

Open protocols or Solace APIs

The second decision is whether an application connects through an open protocol or through one of Solace’s own messaging APIs, which all speak SMF.

Question	Open protocol (MQTT, AMQP, REST)	Solace API (SMF)
Portability to another broker	High; clients are vendor-neutral	Low; code uses Solace classes
Feature coverage	The protocol’s feature set, with documented deviations	The full broker feature set
Client libraries	Many, maintained by third parties	Maintained by Solace, in about ten languages
Performance tuning	Depends on the client library	Solace documents C as lowest CPU, highest throughput
Who supports the client	The open-source project or its vendor	Solace support

Our view. Put devices, packaged products and anything you might move to another broker on open protocols. Use Solace’s APIs where you have chosen Solace for the long term and need what only SMF exposes. Most estates end up mixed, and that is fine, as long as the choice is written down per application rather than left to whichever developer wrote the first prototype.

Choosing a protocol per application

A short procedure that holds up in design reviews:

1. Start from the client, not the broker. What does the application or device already speak? Changing a packaged MES or a PLC gateway is expensive; changing a broker setting is not.
2. Decide the delivery guarantee. If losing a message costs money or compliance evidence, the consumer needs a queue with guaranteed messaging, whatever the protocol. See guaranteed messaging.
3. Check the documented deviations for that protocol (the MQTT and Kafka limits below are the common ones).
4. Check metadata. List the headers or properties consumers rely on and test their mapping end to end.
5. Write a topic convention before the first publisher goes live. Translation works only if every protocol publishes into the same hierarchy. The topics and wildcards page covers design.

An illustrative scenario. A food plant publishes filler states from an edge gateway over MQTT. Quality needs every reject event in its LIMS, which reads a JMS queue. The cloud data team wants the same events in Kafka for a weekly yield model. On one Solace broker this becomes one MQTT topic tree, one queue subscribed to site1/*/*/*/reject for the JMS consumer, and a Kafka Sender bound to a second queue. Three consumers, one publish, no custom code in the middle.

Where protocol translation goes wrong

Multi-protocol brokers fail in predictable ways, and none of them is specific to Solace. The ones we would design against:

• Silent quality-of-service changes. A device team configures QoS 2 because it sounds safest, the broker treats it as QoS 1, and a consumer that cannot tolerate duplicates double-counts production. The fix is idempotent consumers, not a protocol setting.
• Lost metadata. A JMS consumer filters on a property the MQTT publisher never set, so messages arrive and are ignored. Nobody sees an error.
• Topic sprawl by protocol. Each team invents its own hierarchy because each protocol “feels” different. Six months later the same machine state exists on three topics with three payload formats.
• Slow consumers on a shared broker. A REST endpoint that answers in two seconds holds back a delivery point while MQTT telemetry keeps arriving. Queue quotas and alerts need to be set per consumer, not per broker.

These are design problems, which is why they belong in the architecture review rather than in the first incident report. Our MQTT guide for manufacturing covers the device side of the same questions.

Limits and open questions

As of October 2026, the public documentation states or leaves open the following:

• MQTT QoS 2 is downgraded. Solace accepts QoS 2 publishes and subscriptions and treats them as QoS 1, and QoS 1 shared subscriptions are downgraded to QoS 0 (MQTT 5.0 conformance). Details on the MQTT page.
• Retained messages are Controlled Availability, implemented through retain caches (Using MQTT). That matters for Sparkplug B, covered on the Sparkplug page.
• Kafka bridging is documented for software brokers only, “and not appliance event brokers” (Kafka bridging). The page we read does not mention Solace Cloud. Ask.
• JMS means JMS 1.1 functionality in Solace’s own API; the docs state both namespaces “provide the same JMS 1.1 functionality” (Solace JMS API).
• AMQP means 1.0 only. Clients written for RabbitMQ’s AMQP 0-9-1 will not connect.
• Metadata mapping is not fully tabulated in one public place. Test it.
• Standard Edition limits apply to all protocols: 1,000 connections and 10,000 messages per second ingress, and the docs mark it not production deployable (editions). See Standard vs Enterprise.

How to evaluate Solace protocols

• List every application and device that will connect, with the protocol and client library each one uses today.
• For each MQTT client, confirm it never relies on QoS 2, QoS 1 shared subscriptions or retained messages in production.
• For each JMS application, confirm it uses only JMS 1.1 features, or plan for Qpid JMS over AMQP.
• For Kafka, confirm which broker form factor you will run and which of the three integration mechanisms it supports.
• Test header, property and correlation ID mapping between the protocol pairs you actually use.
• Load-test REST publishers at peak rate; HTTP adds a round trip per message.
• Agree a topic hierarchy that every protocol publishes into, and enforce it with access control lists.
• Ask Solace which protocol features are Controlled Availability or Beta in your target release.

Deeper

• Solace MQTT: versions, QoS behaviour, shared subscriptions, retained messages, and when to keep a plant MQTT broker in front
• JMS, AMQP and REST: the enterprise protocols, REST messaging and microgateway modes, and migrating from other JMS brokers
• Kafka Integration: in-broker bridging, the Kafka wireline proxy and connectors, and when each fits
• Solace SDKs: the messaging APIs by language, the Spring and Quarkus integrations, and how to choose

Protocol choice is half of the story; the other half is how brokers link across sites, covered on the event mesh page. Back to the Solace hub.