Which Java client API to use ?
So I am a bit confused on which Java client API to use for connecting to a solace appliance from an application.
My understanding is that we have the option of using JCSMP , RTO , JMS , Spring JMS vs Spring JCSMP ?
Could some one please summarize at a high level what are the pros and cons of each approach in terms of latency, ease of use, portability etc. And if there are any recommended patterns.
- We use kerberos for authentication so any API's that are not compatible will be out of the window for us.
Many Thanks,
Best Answer
-
Generally, JCSMP is the most flexible Java client API to use against Solace appliances (or the software or Cloud versions of the PS+ broker). It is full featured and supports all Solace broker/API capabilities. It is also a pure Java JVM implementation so it should meet the Java, "write once run anywhere" mantra. If you are developing using J2E, JCSMP is also you API of choice against Solace brokers.
Solace JCSMP also works very well in Cloud Native deployments. For example using JCSMP with Spring Boot allows deployment from source in GitHub to deploy and immediately run in applications environments like OpenShift using the OpenShift S2I deployment configuration templates.
If you need a more deterministic low latency capability you would consider Java RTO. In this case your business logic is written in Java, but the API makes use of the Solace C library via JNI to performance the actually messaging functionality. As a result the messaging API is not subject to the unpredictable JVM memory management. However, it will require the inclusion of the appropriate Solace library for the specific OS when your Java Application is deployed. You will also only be allowed to use a binary payload since the other Solace serializations (Map message, Stream message, etc.) are not supported. However, the RTO applications are still SMF format in the Broker, so you will still have interoperability will all the other support APIs and transports supported against the Solace broker (for example a RTO producers messages can be consumed by a REST Consumer or JavaScript consumer and conversely a C or IOS application producer's messages can be consumed by a JavaRTO application).
Java RTO also supports the use of WebSockets as the message wire protocol over TCP. RTO is a more specialized Java implementation for ultra low latency and low jitter applications.
You would choose JMS if you require migration of the application to or from another system that is already using JMS or is expected to use JMS. The JMS specification only defines a subset of Solace broker and API capabilities, however, the Connection Factory administered object that is part of the Solace JMS library provides many of the Solace capabilities without requiring any non-compliant JMS code. JMS allows developers to create applications without requiring the need to learn the Solace-specific APIs. If the developers are already comfortable with JMS, they might consider using JMS rather than learning JCSMP.
Solace support JMS over the Solace wireline format or AMQP. If you want to write AMQP applications, but do not want to use the AMQP API you can use JMS over AMQP against the Solace Broker as well.
The Spring implementation of Spring Cloud Streams (SCS) with theSolace-Supported JCSMP binder is another very practical mechanism for writing/deploying Solace Java Code. The binder shields the developer from writing any messaging code and can instead focus on purely business logic. Using the Spring Framework allows any messaging-specific code to be implemented as metadata driven configuration files. Many of the Solace clients are now opting to use SCS to develop their messaging code.
SCS allows developers to use a declarative model rather than a procedural model for creating Sources, Sinks or Processors. Very little code is required.
SCS also allows Solace Java applications to also make use of reactive programming and stream processing using the FLUX libraries (part of the Reactor Project). If your Java application requires stream processing to provide capabilities that you might use Storm, Spark or Kafka, this is a an excellent alternative that is also based on Open Source Libraries and operates against the Solace brokers.
SCS is also a great option of your are deploying your applications in Cloud Foundry, OpenShift or Kubernetes. If you are looking at using stream processing capabilities or reactive programming without any concern for messaging and transport than Spring JCSMP is your best alternative.
Spring JMS helps hide the JMS messaging code for developers that want to use the JMS libraries to a JMS broker (such as Solace) without having to spend time writing the JMS "plumbing" code. If you require interoperability with potentially non-JMS consumers and producers through the Solace broker and still want native Solace payload serialization support for payloads that are Map or Stream, for example, the Spring JMS libraries and framework would possibly be your choice for development.
Kerberos should not be an issue with any of the above, however, I have only "personally" specifically used Kerberos using JCSMP and JMS.
8
![[Deleted User]](https://wd.vanillicon.com/v2/d5f8e95492bc9423c5e1f4f53fb1d6cf.svg)
Answers
-
Generally, JCSMP is the most flexible Java client API to use against Solace appliances (or the software or Cloud versions of the PS+ broker). It is full featured and supports all Solace broker/API capabilities. It is also a pure Java JVM implementation so it should meet the Java, "write once run anywhere" mantra. If you are developing using J2E, JCSMP is also you API of choice against Solace brokers.
Solace JCSMP also works very well in Cloud Native deployments. For example using JCSMP with Spring Boot allows deployment from source in GitHub to deploy and immediately run in applications environments like OpenShift using the OpenShift S2I deployment configuration templates.
If you need a more deterministic low latency capability you would consider Java RTO. In this case your business logic is written in Java, but the API makes use of the Solace C library via JNI to performance the actually messaging functionality. As a result the messaging API is not subject to the unpredictable JVM memory management. However, it will require the inclusion of the appropriate Solace library for the specific OS when your Java Application is deployed. You will also only be allowed to use a binary payload since the other Solace serializations (Map message, Stream message, etc.) are not supported. However, the RTO applications are still SMF format in the Broker, so you will still have interoperability will all the other support APIs and transports supported against the Solace broker (for example a RTO producers messages can be consumed by a REST Consumer or JavaScript consumer and conversely a C or IOS application producer's messages can be consumed by a JavaRTO application).
Java RTO also supports the use of WebSockets as the message wire protocol over TCP. RTO is a more specialized Java implementation for ultra low latency and low jitter applications.
You would choose JMS if you require migration of the application to or from another system that is already using JMS or is expected to use JMS. The JMS specification only defines a subset of Solace broker and API capabilities, however, the Connection Factory administered object that is part of the Solace JMS library provides many of the Solace capabilities without requiring any non-compliant JMS code. JMS allows developers to create applications without requiring the need to learn the Solace-specific APIs. If the developers are already comfortable with JMS, they might consider using JMS rather than learning JCSMP.
Solace support JMS over the Solace wireline format or AMQP. If you want to write AMQP applications, but do not want to use the AMQP API you can use JMS over AMQP against the Solace Broker as well.
The Spring implementation of Spring Cloud Streams (SCS) with theSolace-Supported JCSMP binder is another very practical mechanism for writing/deploying Solace Java Code. The binder shields the developer from writing any messaging code and can instead focus on purely business logic. Using the Spring Framework allows any messaging-specific code to be implemented as metadata driven configuration files. Many of the Solace clients are now opting to use SCS to develop their messaging code.
SCS allows developers to use a declarative model rather than a procedural model for creating Sources, Sinks or Processors. Very little code is required.
SCS also allows Solace Java applications to also make use of reactive programming and stream processing using the FLUX libraries (part of the Reactor Project). If your Java application requires stream processing to provide capabilities that you might use Storm, Spark or Kafka, this is a an excellent alternative that is also based on Open Source Libraries and operates against the Solace brokers.
SCS is also a great option of your are deploying your applications in Cloud Foundry, OpenShift or Kubernetes. If you are looking at using stream processing capabilities or reactive programming without any concern for messaging and transport than Spring JCSMP is your best alternative.
Spring JMS helps hide the JMS messaging code for developers that want to use the JMS libraries to a JMS broker (such as Solace) without having to spend time writing the JMS "plumbing" code. If you require interoperability with potentially non-JMS consumers and producers through the Solace broker and still want native Solace payload serialization support for payloads that are Map or Stream, for example, the Spring JMS libraries and framework would possibly be your choice for development.
Kerberos should not be an issue with any of the above, however, I have only "personally" specifically used Kerberos using JCSMP and JMS.
8 -
is this still the most up to date in terms of features for which java api to use for Solace? I found this and was great item that i'd like to put forward on my Solace Best practices page, but wanted to check if its the latest info in 2023 (as answer is from 2019).
0
