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.
Here are some of the things you’ll gain by using Solace’s messaging APIs:
There are others, but that’s enough to give you a good idea for now.
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.
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.
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.
Using the Solace Native APIs is pretty easy:
These are the steps that the codelab will walk you through:
We also have a live coding session that you can check out.
Subscribe to Our Blog
Get the latest trends, solutions, and insights into the event-driven future every week.
By submitting this form, you agree to Solace’s privacy policy: solace.com/privacy-policy/
