Feature Support in Solace Messaging APIs

All the Solace Messaging APIs support common functionality that is essential for messaging. These APIs evolve over time to meet use-case requirements for client applications, therefore there are slight differences in feature support.

The Solace Messaging API for iOS is a mobile API. For the list of features supported for the iOS API, see iOS API.

Here's a summary of the current support for features; you can use this summary as a comparison to select the Solace Messaging API that's right for your requirements. API- or platform-specific features are described on the individual Solace Messaging API pages. The following table shows the Solace Messaging API support for various features:

A minimum event broker version where required, otherwise the feature is available in all supported event broker versions.
A minimum API version where required, otherwise feature support for each API is indicated using the following symbols:
- —A green check with no version number beneath it indicates that the feature is available in all supported API versions.
- —A gray cross indicates that this feature is not currently supported.
- —A gray dash indicates that this feature cannot be supported due to technical limitations in the API.

Feature	C	.NET	Java RTO	JCSMP	Java	JMS	JavaScript	Node.js	Python	Go
Direct and Guaranteed Messaging Support
Request and Reply Messaging					1.1+
Structured Data Types (SDTs) that Don't Rely on a Specific Architecture or Programming Language
Logging and Customizing through Property Parameters
Local Transactions									1.4+
XA Transactions
Solace Cache Client Support									1.6+	1.9+
Durable Endpoint Provisioning							10.17+	10.17+		1.7+
Durable Endpoint Deprovisioning							10.17+	10.17+		1.7+
On-Behalf-Of Topic Subscription Manager
Use Selectors
Streaming Compressed Connection Support
End-to-End Payload Compression Support	7.30+	10.26+	10.8+	10.24+	1.7+	10.25+	10.17+	10.17+	1.8+	1.7+
Support for Proxy Server Connections (HTTP and SOCKS5)
OAuth 2.0 Authentication	7.21+	10.16+	7.21+	10.13+	1.1+	10.13+	10.9+	10.9+	1.3+
OAuth Token Refresh	7.24+	10.19+	10.3+	10.16+	1.1+		10.10+	10.10+	1.5+	1.2+
Kerberos Authentication									1.2+
Distributed Tracing (Context Propagation) Manual Instrumentation event broker version 10.2+		10.21+		10.17+	1.7+	JMS: 10.17+ Jakarta: 10.28+		10.15+	1.7+	1.5+
Distributed Tracing (Context Propagation) Auto-Instrumentation event broker version 10.2+				10.26+		JMS: 10.17+ Jakarta: 10.28+
Replay	7.18+	10.12+	7.18+	10.11+			10.7+	10.7+	1.2+
Delayed Redelivery event broker version 10.3+				10.18+		10.18+
Topic Dispatch
Negative Acknowledgments (NACKs) event broker version 10.2+	7.26+	10.21+	10.5+	10.17+	1.4+		10.15+	10.15+	1.9+	1.8+
Queue Browsing					1.2+				1.11+
Partitioned Queues event broker version 10.4+	7.25+	10.20+	10.4+	10.19+	1.3+	10.19+	10.13+	10.13+	1.5+	1.3+
SERDES with Solace Schema Registry				10.28+

For Java, Go, and Python, the durable endpoint provisioning feature is implemented using the missing resource strategy. On receiver start, the missing resource strategy defines the action to take when an endpoint does not exist. The use of the missing resource strategy also means that you cannot deprovision the endpoints.

Support for Durable Endpoint Provisioning and Deprovisioning

Durable endpoint provisioning allows Solace Messaging APIs to provision endpoints on the Solace event broker even if they do not exist ahead of time. For the C, Go, JCSMP, Java RTO, JavaScript, Node.js, and .NET Solace Messaging APIs, you can also deprovision these endpoints from the API. For more information about provisioning and deprovisioning endpoints for:

For Java, Go, and Python APIs, the durable endpoint provisioning feature is implemented using the missing resource creation strategy. When you start a message receiver, the missing resource creation strategy defines the action to take when an endpoint does not exist. You cannot use the Solace Messaging APIs to deprovision endpoints created with the missing resource creation strategy. For more information about the missing resource creation strategy for:

Support for Distributed Tracing (Context Propagation)

Context propagation with Solace Messaging APIs is supported by the OpenTelemetry Integration API libraries. These libraries allow you to inject context into or extract context from Solace event messages.

You deploy the OpenTelemetry Integration API Libraries alongside the Solace Messaging API for the programming language you are using to develop your application. These libraries have dependencies on the OpenTelemetry API (which must also be deployed with your application). For information about the compatibility of the OpenTelemetry Integration API, Solace Messaging APIs and required dependencies, see Distributed Tracing Version Compatibility.

The OpenTelemetry Integration API libraries support only W3C propagators.

For information about specific libraries and where to get them, see:

Support for Queue Browsing

Client applications can use the Solace Messaging API to look at Guaranteed messages spooled for a queue in the order of oldest to newest without consuming them. For more information about using queue browsing for:

Support for Partitioned Queues

Partitioned queues allow you to easily scale the number of consumer applications in your event mesh. Solace event brokers ensure that all related events are delivered to the same consumer in the correct sequence and can re-balance the event stream when you add or remove consumers.

For a general overview of partitioned queues, see Partitioned Queues.
For details about setting the partition key, see Publishing to and Consuming from Partitioned Queues and Partitioned Queue Feature Interactions.
For examples for using partitioned queues with:

Support for Negative Acknowledgments

Consumer applications can send an acknowledgment (ACK) or a negative acknowledgment (NACK) based on the settlement outcome of processing a guaranteed message. Rather than send an explicit acknowledgment (ACK), you can signal a settlement outcome to the event broker with a settle method or function. For more information about using NACKs for:

Support for Request-Reply Messaging

Request-reply messaging is a method of data transmission where applications simulate separate point-to-point channels: one for requests, and another for replies. In request-reply messaging, each request sent from a message requestor requires a reply from a message replier. When a message replier consumes a request message, it sends a reply back to the requestor. For more information about request-reply messaging for:

Support for On-Behalf-Of Topic Subscription Managers

On-Behalf-Of subscriptions allow certain clients, called OBO subscription managers, to subscribe and unsubscribe to topics on behalf of other clients. OBO subscription managers allow your applications to use a single interface for subscription management, which simplifies how you can add and remove subscriptions for multiple clients. For more information about OBO subscription managers for:

Support for End-to-End Payload Compression

End-to-end payload compression, done by the Solace Messaging APIs, allows for reduced bandwidth usage and improved performance in your applications. For more information about using message payload compression for:

Support for Proxy Server Connections (HTTP and SOCKS5)

You can establish a connection to an event broker within your private network via an HTTP or SOCKS5 proxy server. This allows you to make one firewall exception for the external proxy server, so any clients who authenticate with the proxy server can access your event broker. For more information about using proxy server connections see:

Support for Solace Cache

If you have Solace Cache, you can use the Solace Messaging APIs to make cache requests for topics. The cache requests must include the name of the Distributed Cache, Cache Cluster, or Solace Cache instance to issue the request to and the topics requested. For more information about making cache requests, see:

Support for Replay

Message replay allows client applications to retrieve and reprocess previously published messages from a replay log. Client applications can initiate replay from a specific point in time, from the beginning of the log, or after a specific message ID. The event broker can also initiate replay automatically in certain scenarios. For more information about using replay for:

Replaying from the Replay Log in the C, JavaScript, and Node.js Solace APIs
Replaying from the Replay Log in the Solace Java RTO API
Replaying from the Replay Log in the Solace JCSMP API
Replaying from the Replay Log in the Solace .NET API
Go, see the Solace Go API reference for more information.
Java, see the Solace Java API reference for more information.
Python, see the Solace Python API reference for more information.

Support for SERDES with Solace Schema Registry

SERDES (Serialization/Deserialization) with Solace Schema Registry provides automatic serialization and deserialization of messages using schemas stored in Solace Schema Registry. This feature enables type-safe message handling and schema evolution capabilities for your messaging applications. For more information about Solace Schema Registry, see Solace Schema Registry, and for more information about using SERDES, see:

Serializing and Deserializing Messages in the Solace JCSMP API

Provide feedback