The platform's solace binding includes both a java based and jni based implementation and allows connectivity to a solace message router.

JNI vs JAVA Binding

The Java binding uses solace's JCSMP api while the JNI binding uses solace's CCSMP api. The JNI binding supports zero garbage messaging while in steady state, but only works on linux platforms. The Java binding is not zero garbage but works on all platform supported by X. Other differences between the two bindings are:

• UnhandledMesssageEvents issued by the JNI binding return the subscription name rather than the sent topic name.
• UnhandledMesssageEvents issued by the JNI binding return a session specific sequence number rather than the appliance wide sequence number in the transport specific message id. 
• The provider properties passed through to the underlying property differ depending on the underlying solace library used. 
   The binding rationalizes some of the common properties between the two implementations, but if properties are used that are specific to JCSMP or JNI and are not rationalized, it is important to consider whether JNI is enabled or not. 

The JNI binding is currently only available on Linux platforms. Usage of the JNI binding is controlled by the following properties:

Bus Descriptor Format

A solace message bus can be configured via a descriptor string as follows which takes the connection information followed by a list of provider properties. 

solace://<address>:<port>&prop1=val1&propN=valN

An example bus descriptor for solace would like like:

solace://<address>:<port>&usejni=true&vpn_name=default&username=test& /
password=test&usejni=true&vpn_name=default&username=test&password=test

DDL

In a DDL config file a solace bus can equivalently be configured in one two ways

The descriptor form is useful in cases where the descriptor name may be supplied as an external configuration property that is substituted for example:

Solace Provider Properties

Passed Through Properties

The solace JCSMP and JNI apis on which the platform's solace binding is built allow configuration of the connection by specifying properties.  The provider properties specified in the bus descriptor for the binding are passed through to the solace connection as follows:

• Properties that are not described as in the SolaceBindingProperties javadoc are stripped out. 

• General Bus properties defined in  MessageBusDescriptor javadoc are also stripped out.

• Properties listed as 'Rationalized Properties' below are translated according to whether the jni or java binding implementation will be used these.
• If "usejni" is true, then any remaining properties that don't start with "FLOW_" or "SESSION_" are are stripped, the rest are passed through opaquely.
• If "usejni" is false, then any remaining properties that don't start with "jcsmp" are are stripped, the rest are passed through opaquely.

See the solace documentation for more information on JCSMP and CCSMP. Neeve, does not test properties not explicitly called out on this page or in the javadoc. End users should therefore do their own due diligence in testing any passed through properties. 

Rationalized Pass Through Properties

To make is easier for applications to switch between using the jni (c) and jcsmp (java) binding implementations, several commonly used pass through binding properties are automatically translated by the binding. These are summarized in the table below. If your application doesn't use any additional solace configuration properties then switching between the java a c

Additional Properties

See the SolaceBindingProperties javadoc for the full of binding properties that can be used to configure the solace binding, those not called out as rationalized properties control the binding itself. 

Auto Tuning

When not explicitly as binding property, the following properties are automatically set on the binding based on the global optimization value.

Working with the Solace Binding

Solace Topic Format

Solace topics can be specified hierarchically with each level in the topic separated by a '/' character. Solace topics cannot exceed 250 characters in length. For more details on Solace topics refer to solace documentation.

Wildcard Topics

Solace supports 2 wildcard character sequences that can be used in Channel Filters to match multiple sending topics. Wildcard characters are not applied to sent topics and are treated as character literals. The solace binding implementation is sensitive to the following wildcards when nv.sma.cleanchannelfilter=true and will preserve these characters rather than replace them with an '_':

Example

In the following example Solace messaging is configured with a dynamic channel key to resolve topics for new orders in a trading application. The variable portions of the dynamic key are used to allow receiving applications to select which traffic they shall receive: 

In the above example, the order-manager application uses a channel filter of  <filter>Region="US";Symbol=A*|MSFT</filter> which results in it creating the following subscriptions:

• */US/A*
• */US/MSFT*

In other words, it selects messages from any InitiatingClient in the 'US' region for the symbol MSFT or any Symbol starting with an 'A'. The order-manager app would receive the following message sent from a client with the following content:

But the order-manager would not receive messages sent from a client with the following content:

Message Metadata Version

When a message is sent through the solace binding SMA metadata is sent with the message to assist receivers in determining how to deserialize and dispatch the message. By default the solace binding sends messages using the V1 version of metadata to ensure that older receivers (pre Talon 1.8.396) can deserialize messages. The difference between the V1 and V2 metadata is that the V2 encodes the message type (prior to the introduction of V2 metadata receivers needed to introspect the serialized message content and use the xRogType field encoded in the message).

Orphan Subscription Checks

When a solace message bus binding has a queue name specified it is capable of issue guaranteed subscriptions against that queue. When a binding is started it is possible that there may already be existing subscriptions on the queue that don't match those that the application is issuing. Such subscriptions are considered to be 'orphan' subscriptions - presumably those left over from an early session that were not removed.

The following policy can be configured to check for orphan subscriptions

Configuration

To check for existing subscription SEMP must be enabled for the binding to retrieve the list of subscriptions over the messaging connection. The following provider properties must be specified on the bus descriptor to perform subscription checks:

Enforcing Max Queue Bind Count

Sending and Receiving from External Applications

This section describes how to send to Talon applications from non Talon applications and from Talon application to non Talon applications over solace. This is an uncommon usecase ... see Sending and Receiving Messages for information on sending from within a Talon application. The sections below utilize the ADM generated messages for convenience, but this is not required. For example, if you your messages are encoded in protobuf (or Xbuf) you could encode/decode the message yourself without using ADM. One such example of this might be if you were using C and generated protobuf message from the IDL generated by ADM. 

Sending Messages

The platform's Solace binding transports encoded messages in a BytesMessage. The encoded messages is set as the message data, and the metadata is stored as serialized MessageMetadata in the "x-sma-metadata" property. The example below shows how an external application can send a message natively using the solace JCSMP client:

Receiving Messages

The following code sample shows how an external application using the Solace JCSMP api directly can unpack a message sent over the platform's built in Solace binding and materialize it into a message view.