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.
Tom works in Solace's systems architecture team helping customers define their architectures to address challenges such as the increasing digitisation of business across a wide range of industries including retail, financial services and smart city initiatives. He joined Solace in 2013 as part of the Singapore Technical Support team, then moved to London in 2014.
If you own a smart phone or tablet, the chances are you already use Tom’s work, as prior to Solace Tom was an IC designer responsible for implementing the low-power hardware in the processors present in over 90% of these devices.[position] => [url] => https://solace.com/blog/author/tom-fairbairn/ ) )