Add Ballerina JMS connector to the cross-language-clients list

[ayeshLK]

Description

Ballerina is an open-source programming language purpose-built for seamless integrations. Its unique design combines a simple syntax with powerful features tailored for distributed systems, making it an excellent choice for integration-centric applications.

The Ballerina JMS Client enables developers to easily interact with JMS brokers like ActiveMQ, offering a modern, developer-friendly alternative for building robust messaging solutions.

Reference for Ballerina JMS connector: https://central.ballerina.io/ballerinax/java.jms/1.0.1

[ayeshLK]

@jbonofre @jbertram highly appreciate your support to get this PR merged.

[jbertram]

I'm not sure this document (i.e. cross-language-clients.md) is really valid anymore. It probably made sense back in 2007 when it was first created. At that point OpenWire and STOMP were relatively new. In the 14 years since then both AMQP and MQTT have been widely adopted across a wide variety of languages and platforms, and none of those clients are linked here. Furthermore, it's relatively easy to find a messaging library using a modern search engine.

In my opinion this page should be removed for the following reasons:

• It's woefully out of date.
• Keeping it up to date is a maintenance burden.
• It could be seen as an endorsement of the linked project when, in reality, it's hard to even know if the project is maintained anymore.
• Better alternatives (e.g. search engines) exist.

[mattrpav]

I think this is a valuable document for users. After all, this is middleware. It’s all about connectivity to all sorts of things, regardless of “modern” or not.

I think adding an “updated date” to the entries would be a simple approach to communicate how recent an entry is

[jbertram]

..this is middleware. It’s all about connectivity to all sorts of things, regardless of “modern” or not.

I think we I agree here.

I think adding an “updated date” to the entries would be a simple approach to communicate how recent an entry is...

I don't see how that addresses the points I raised. Here are some additional questions that correspond to and hopefully clarify my previous points:

• Are we going to augment the list with any of the STOMP clients that have been written since this document saw a meaningful update? What clients for MQTT and AMQP?
• How are we going to maintain the list so that it doesn't fall out of date like the current one? Are we going to rely on folks sending PRs? Are we going to update it ourselves? If so, how will we know what new clients have been written and what clients have been abandoned?
• By what criteria will we judge the clients that we link so that the list is trustworthy? Should we test with each of the linked clients to give users confidence that they work?
• Why not simply advertise the protocols we support and tell users to search for a client for their language and platform?

In my opinion this list is technical debt, and eliminating technical debt is valuable for us and users because it frees our time to do more meaningful things. It's easy for users to search by protocol/language/platform to find suitable client implementations. It's harder for us to maintain a list like this as evidenced by the fact that it hasn't had a meaningful update in almost 9 years now despite the fact that notable new clients have been released (e.g. Paho suite of MQTT clients, Qpid JMS, AMQP.Net Lite, etc.).