Solace Binding
The Solace binding provides native integration with Solace PubSub+ message brokers for high-performance, low-latency messaging in Talon microservices.
Overview
The Solace binding uses Solace's native APIs (not JMS) to achieve optimal performance with Solace PubSub+ message brokers. It supports both Solace PubSub+ hardware appliances and software brokers.
For configuration details, see Solace Binding Configuration.
JNI vs Java Implementation
The Solace binding includes both a Java-based and JNI-based implementation:
Java Binding (JCSMP)
Uses Solace's JCSMP (Java Client Software Messaging Protocol) API
Works on all platforms supported by Talon
Not zero-garbage but provides good performance
Fully managed Java implementation
JNI Binding (CCSMP)
Uses Solace's CCSMP (C Client Software Messaging Protocol) API via JNI
Linux only
Supports zero-garbage messaging in steady state
Maximum performance for latency-sensitive applications
Key Differences
Platforms
All
Linux only
Garbage
Non-zero
Zero in steady state
UnhandledMessageEvent topic
Sent topic name
Subscription name
UnhandledMessageEvent sequence
Appliance-wide sequence number
Session-specific sequence number
Pass-through properties
Properties starting with jcsmp
Properties starting with FLOW_ or SESSION_
Solace Topic Format
Solace topics are hierarchical with each level separated by / character. Topics cannot exceed 250 characters in length.
Example topics:
orders/events/MSFTmarket-data/trades/US/APPLalerts/critical/region1
For more details on Solace topics, refer to Solace documentation.
Wildcard Topics
Solace supports wildcard characters for matching multiple topics in channel filters. Wildcards are not applied to sent topics (treated as literals).
The Solace binding preserves these wildcards when nv.sma.cleanchannelfilter=true:
*
Matches 0 or more characters at end of topic level
orders/gin* matches:
- orders/gin
- orders/ginseng
Does not match:
- orders
- orders/in
- orders/gin/foo
>
Matches multiple topic levels. Must be only character in last level.
orders/> matches:
- orders/events/MSFT
- orders/updates/APPL
- orders/cancels/US/IBM
Does not match:
- orders
- order-updates
Topic Routing Example
The following example demonstrates dynamic topic resolution with wildcards:
The order-manager application uses filter Region="US";Symbol=A*|MSFT, creating these subscriptions:
*/US/A*- Any client, US region, symbols starting with A*/US/MSFT- Any client, US region, MSFT symbol
Matching messages:
Non-matching messages:
Message Metadata Version
When messages are sent through the Solace binding, SMA (Simple Messaging API) metadata is included to help receivers deserialize and dispatch messages.
By default, the Solace binding sends messages using V1 metadata to ensure compatibility with older receivers (pre-Talon 1.8.396). The difference:
V1: Receivers must introspect serialized message content to determine type
V2: Message type is encoded in metadata (more efficient)
Sending and Receiving from External Applications
This section describes integration with non-Talon applications over Solace. This is an uncommon use case - see Sending Messages for Talon-to-Talon messaging.
Sending Messages to Talon
The Solace binding transports encoded messages in a BytesMessage with:
Message data: Serialized message payload
x-sma-metadata property: Serialized
MessageMetadata
Example using Solace JCSMP client:
Receiving Messages from Talon
Example using Solace JCSMP client:
See Also
Solace Binding Configuration - Configuration reference
Messaging Model - Overview of Talon messaging
Configuring Bus Connections - General bus configuration
Solace PubSub+ - Solace message broker information
Last updated

