Use Solace Messaging APIs for Advanced Event Mesh Features and the Best Performance

One of the advantages of Solace PubSub+ Event Broker is the ability to connect to and interoperate over a wide variety of open standard protocols without any bridging or translation. So why would you use Solace’s native messaging APIs for languages like C, Java, and .NET?

Sometimes you need or want to make use of features the event broker offers that just can’t be expressed in an open standard. For example, there are no request/reply semantics in MQTT 3.1. And JMS 1.x lacks streaming publishing, as JMS 1.x publishers are synchronous. Or, you might want to use an advanced feature such as marking a message as being eligible for a Dead Message Queue for poison message handling.

Solace’s messaging APIs give you access to the full range of Solace PubSub+ Event Broker features, the best performance, and a single point of support.

Super Useful Features

Here are some of the things you’ll gain by using Solace’s messaging APIs:

• Per-message control over Topic, Queue, and Delivery Mode
• Built-in Message VPN support for multi-tenancy (we emulate this by using different port numbers for different message VPNs when using the open protocols) enabling multiple users across lines of business or even organisations to share brokers
• Full request/reply semantics, including an auditable reply-to topic
• Use of PubSub+ Cache, Solace’s pluggable last value cache for reliable events that gives full support for “late joiner clients”
• Use of transactions
• Full Dead Message queue (DMQ) handling – Time To Live, DMQ eligible at the event level. Very useful for time critical messages and poison message handling
• Use of Solace structured data types (if you’re not using a serialization package) and user properties for easy packaging of data across distributed environments
• The ability to perform eliding, a way of rate limiting a message stream
• API send timestamps for audit and logging
• Fine-grained control over persistent delivery, such as requesting immediate acknowledgement

There are others, but that’s enough to give you a good idea for now.

APIs, Languages, Wirelines…

You may ask why specific features might be available in a native API but not an open standard. You may even suspect we’re hiding stuff from you in a Machiavellian plot to tie you in to Solace. We’re not! By supporting open standards, we expose ourselves to direct comparison with other brokers.

We think this is good for you, because it gives you a direct comparison. It’s good for the open standard, because it drives adoption. And it’s good for us, because if our product isn’t the best, we’ll soon find out.

So why don’t we support all the features of all the open standards in our broker? I could give you an answer around how long it takes to get adoption of a standard update, and while that’s true, it’s a little corporate. Let’s look at the technical details.

Wireline vs API

First of all, it’s important to understand the difference between the concepts of API and wireline. JMS is an API level standard. It dictates what the API calls look like and deals with how those API calls interact with the broker.

JMS doesn’t describe any details about how the event should look on the wire. For instance, what information should be sent to the broker to initiate a client connection?  JMS says the API should gather parameters about username and password, but it doesn’t say how they will be sent to the broker.

Wireline standards such as MQTT and AMQP do precisely this. They say what call should be used to log in to the broker and how that call is translated to bytes inside a TCP frame. For instance, the MQTT specification says how a client connection request should be formatted, handled by the broker, and what API call will cause the client to send it.

Why is the wireline important to feature coverage?

Looking at the definition of the wireline, we can see that it offers a big advantage: interoperability. A wireline client can connect to any broker that supports that wireline. But there’s a problem: if we want to add support for a feature that isn’t in the specification, there’s no room on the wire to put the necessary control.

With an API specification such as JMS, we can at least extend the specification with new API calls to access new features – at the cost of the extended API being non-standard and sacrificing interoperability. A JMS client from one vendor cannot connect to a JMS broker from a different vendor, which is why you have to have a JMS Provider to implement the specific vendor wireline.

So How Do I Get Started?

Using the Solace Native APIs is pretty easy:

1. Get the API in the language of your choice from the downloads page of our web site
2. Learn about the basic eventing patterns by browsing the SolaceSamples GitHub organization or tutorials
3. Get to grips with the Solace Messaging APIs documentation
4. Start coding!

These are the steps that the codelab will walk you through:

1. Introduction
2. Prerequisites & Assumptions
3. Overview
4. Start: connect using Try-Me!
5. Start: find connection in PubSub+ Broker Manager
6. API Initialisation
7. Part A: Get Connected: The Session
8. Part B: Receiving Messages & Callbacks
9. Part C: Sending Messages
10. Wrap up, and Things We Didn't Cover

Follow our step-by-step Codelab tutorial accompanied with this blog

Open this codelab

We also have a live coding session that you can check out.