Looking to get some more clarity on the solace api for Solace PubSub+

mabourahal2

Hi Solace community,

I am currently looking into Solace PubSub+ tutorial and documentation and I noticed that there was ~4 different java implementations. I was wondering what is the main difference of each implementation is all these different option available for convenience or is there a fundamental difference in what feature they provide?

Additionally, in the company different teams use different technologies like Go and C# I was wondering if the list of features available is the same across languages. For example, do they all support "consume persistent message with auto acknowledgement" or is there some limitation depending on the implementation that I should be aware of.

As of right now I was able to set up a basic java app using the native java tutorial and I am just hoping to learn more about it.

Thanks,

Michael Abourahal

amackenzie

Hi.

On the Java front, yes, it can be a bit confusing if you are new to it.

• The Java API is the newest Java API and, unless it is missing features you need, should be the one to try 1st. It is a modern API with its underpinnings being JCSMP (see next).
• JCSMP is our oldest Java API and has seen many, many applications built on it. In terms of Java language support, it's a little "old school" and we wrote the new Java API (above) to better support modern Java. JCSMP is the base for the new Java API and may include some features/functionality not (yet) supported in the new Java API. Therefore JCSMP might be something you look at if you need these features.
• Solace JMS is the JMS 1.1 standard messaging API built on top of Solace's SMF protocol/transport layer (again, JCSMP under the covers). With JMS, you can write an application once (as the API is fixed) and simply swap out the underlying provider JARs, supply different connection factory settings and it should just work. But, being a standard, JMS is fixed in its feature set.
• Java RTO is a specialized API that wraps our C API with a Java API calling native C code over JNI. Its sole purpose is to provide the lowest latency and performance in Java applications. It works great if you have the right use cases, but for general purpose applications, it's not recommended. You need to write your Java in non-standard ways (like a C app style) and should be avoided unless absolutely needed. The other Java APIs are plenty fast and low latency for most needs.

As for which APIs support which features, there is a table here that shows this at a high-ish level. Some of the APIs (like Java, Go, Python) are fairly new and will be getting features over time that will change some of these rows to checkmarks as they are released. So this table is really a point-in-time comparison.

amackenzie

The broker and all the Solace APIs are using SMF to communicate. You can publish messages using any API/language and consume using any other API/language.

amackenzie

Hi.

On the Java front, yes, it can be a bit confusing if you are new to it.

• The Java API is the newest Java API and, unless it is missing features you need, should be the one to try 1st. It is a modern API with its underpinnings being JCSMP (see next).
• JCSMP is our oldest Java API and has seen many, many applications built on it. In terms of Java language support, it's a little "old school" and we wrote the new Java API (above) to better support modern Java. JCSMP is the base for the new Java API and may include some features/functionality not (yet) supported in the new Java API. Therefore JCSMP might be something you look at if you need these features.
• Solace JMS is the JMS 1.1 standard messaging API built on top of Solace's SMF protocol/transport layer (again, JCSMP under the covers). With JMS, you can write an application once (as the API is fixed) and simply swap out the underlying provider JARs, supply different connection factory settings and it should just work. But, being a standard, JMS is fixed in its feature set.
• Java RTO is a specialized API that wraps our C API with a Java API calling native C code over JNI. Its sole purpose is to provide the lowest latency and performance in Java applications. It works great if you have the right use cases, but for general purpose applications, it's not recommended. You need to write your Java in non-standard ways (like a C app style) and should be avoided unless absolutely needed. The other Java APIs are plenty fast and low latency for most needs.

As for which APIs support which features, there is a table here that shows this at a high-ish level. Some of the APIs (like Java, Go, Python) are fairly new and will be getting features over time that will change some of these rows to checkmarks as they are released. So this table is really a point-in-time comparison.

amackenzie

Also worth looking at is our integration with Spring Boot and Spring Cloud Stream.

Writing a Java application using the Solace Spring Cloud Stream binder is another "API" (framework) that abstracts most of the Solace specifics from your app code (and does the Spring thing by moving it to configuration instead).

You can look here if you want to find out more about our overall Spring integration.

mabourahal2

Thanks @amackenzie ,

I will definitly explore the Spring Boot and the java implementation then. Right now we are replacing a different eventing system with Solace PubSub+ so depending on what makes sense based on what we have already I will choose accordingly.

Is there anything I should know for java apps communicating with lets say Go apps or no matter the format of the message every language should be able to handle all events?

amackenzie

The broker and all the Solace APIs are using SMF to communicate. You can publish messages using any API/language and consume using any other API/language.

Tamimi

And to add to what Andrew has mentioned, I really like this diagram as it visually shows the protocol translation and interoperability feature between different languages using the Solace PubSub+ Event Broker (which you can also see on solace.dev)

All Solace APIs use SMF (Solace Message Format) to communicate with the broker which is a wireline protocol used by PubSub+ and Solace messaging APIs