Solace consumers and producers connecting with diferent protocol

subhoatg
subhoatg Member Posts: 17 ✭
in PubSub+ Event Broker #1

We have multiple microservices connecting to Solace for different message publish and subscribe requirements. There are some java runtime-based microservices connecting using JMS APIs (using sol-jms library or apache qpid JMS 2.0 library), whereas there are golang and nodejs based runtimes connecting to solace based on runtime specific native Solace libraries.

While technically we tried that a non-java client using native solace APIs connect to solace and publishes the message in the topic and the subscribers use JMS durable subscriber to receive the message from the same topic or vice versa, Are there any difficulties or anomalies that can be expected or can we assume that Solace would do the protocol conversion and there are no issues with such usecases?

Tagged:

Best Answer

  • Ragnar
    Ragnar Member, Employee Posts: 67 Solace Employee
    #2 Answer ✓

    Here is detailed discussion of JMS and Solace Solace JMS Overview.

    The section on 'Extensions' discusses how to access features of SMF that are not available in JMS. Be aware that if you use these extension your application will not be portable to other JMS provides, such as Apache QPID.

    Ragnar

Answers

  • Ragnar
    Ragnar Member, Employee Posts: 67 Solace Employee
    edited April 2022 #3

    Hello,

    First I want to be clear that JMS is not a protocol. JMS is a standard messaging API that is used to send messages over many different protocols.

    Solace JMS uses SMF (the Solace Messaging Format) protocol. So do all of the native Solace APIs you mention. So there is in effect no protocol translation occurring. The native APIs expose some features of the SMF protocol that are not available in JMS, or only available through Solace extensions, which are non-standard by definition. In general these are not commonly used and there is no issue interoperating between APIs.

    Apache QPID JMS uses AMQP as the protocol. In this case there is protocol translation occurring in the broker to/from SMF. A great deal of work has gone into making this translation seamless in both directions, especially for JMS APIs which do not have access to all the features of either AMQP or SMF.

    Regards,

    Ragnar

  • subhoatg
    subhoatg Member Posts: 17 ✭
    #4

    Thanks @Ragnar for this detailed explanation. This really helped.

    is there a documentation on which features are not supported by JMS but supported in native protocols?

  • Ragnar
    Ragnar Member, Employee Posts: 67 Solace Employee
    #5 Answer ✓

    Here is detailed discussion of JMS and Solace Solace JMS Overview.

    The section on 'Extensions' discusses how to access features of SMF that are not available in JMS. Be aware that if you use these extension your application will not be portable to other JMS provides, such as Apache QPID.

    Ragnar

  • Tamimi
    Tamimi Member, Administrator, Employee Posts: 541 admin
    #6

    Hey @subhoatg - a good starting point I would recommend is the Solace documentation under the "Messaging APIs and Protocols > Open APIs and Protocols > JMS" particularly the "Developer Guide for Solace JMS API" section. It lists details on the the Solace JMS implementation

Categories

This Month's Leaders

This Week's Leaders