JMS Binding
The JMS binding provides integration with JMS 1.1 message brokers using JNDI-based configuration for Rumi microservices.
Overview
The JMS binding works with JMS 1.1 level JMS clients and is configured using JNDI lookup. In addition to the generic JNDI-based configuration, the platform provides provider-specific implementations optimized for:
ActiveMQ - Uses
INDIVIDUAL_ACKNOWLEDGE_MODEfor Guaranteed deliveryTibco EMS - Uses
EXPLICIT_CLIENT_ACKNOWLEDGEfor Guaranteed delivery
Both provider-specific implementations normalize topic delimiters from / to . for consistency with other Rumi bindings.
For configuration details, see JMS Binding Configuration.
JMS Topic Format
JMS topics are JMS provider-specific. The platform treats channel key levels as being delimited by / and leaves it up to the binding implementation to normalize topic levels to the format native to the JMS provider.
For example, the ActiveMQ and Tibco EMS providers both normalize the channel key separator to . when sending or joining a channel.
Wildcard Topics
Support for topic wildcards is specific to the JMS provider, if supported at all. The generic JMS binding does not perform any special handling for wildcard characters. When nv.sma.cleanchannelfilter=true, all non-alphanumeric characters are replaced with an _ character (as they are during message sends when nv.sma.cleanmessagekey=true).
The platform's ActiveMQ and Tibco EMS specific binding implementations are sensitive to the following wildcards when nv.sma.cleanchannelfilter=true and preserve these characters rather than replace them with _:
*
Matches 0 or more characters within a topic level. Must be the only character in that level.
orders/* matches:
- orders/gin
- orders/begin
- orders/ginseng
- orders/beginning
Does not match:
- orders
- orders/in
...
Matches multiple topic levels. May only be used as the last level in a topic filter string.
orders/... matches:
- orders/events/MSFT
- orders/updates/APPL
- orders/cancels/US/IBM
Does not match:
- orders
- order-updates
Sending and Receiving from External Applications
This section describes integration with non-Rumi applications over JMS. This is an uncommon use case - see Sending Messages for Rumi-to-Rumi messaging.
These examples use ADM-generated messages for convenience, but this is not required. Messages can be encoded in any format (e.g., Protobuf, Xbuf) and encoded/decoded manually.
Sending Messages to Rumi
The platform's JMS binding encodes a serialized message payload in a bytes message and sets metadata fields in its JMS headers.
Example using JMS client:
Receiving Messages from Rumi
Example using JMS client:
See Also
JMS Binding Configuration - Configuration reference
Messaging Model - Overview of Rumi messaging
Configuring Bus Connections - General bus configuration
Last updated

