Let’s Talk Message Queuing Products

In the current technological environment, many systems and/or applications are built on cloud architecture. For better operations, these applications are developed as smaller blocks with a dedicated function and then brought into sync with the help of message queuing architecture. Niche applications are becoming more and more available, however at the same time they are heavily relied upon, often support critical business functions, real time or near real time capabilities, and solve major problems. They are also expected to integrate extensively with third-party applications.

Message queuing products help with this.  

These products are essentially a communication link between these decoupled applications. Acting as temporary message storage, these products bring in coordination and performance enhancement with all the messages being handled in a sequential order. The messages transferred over the Messaging Queue products are actually a work order for the next application that keeps on propagating the tasks further in a more reliable fashion. Message Queuing functions are continuing to evolve and progress, so it’s worth a quick review of their architecture, and then taking a step back to evaluate some of them based on their merits.

Message Queue Architecture

Message queue product architecture begins with the part of the application that generates the messages, called producers. The subsequent applications the receive the messages are known as consumers, which take the “work order” and act upon it. The message queues are capable of storing the message temporarily if the sequential application is busy or not connected. Message queue architecture makes the components independent and simplifies the coding of decoupled applications. 

Message queuing as a service

If you are already working in the cloud, and looking to implement a messaging capability, most cloud providers provide some sort of messaging as a service.  This can be helpful if you don’t want to roll your own, and it’s all managed for you. That said, this can lead to provider lock-in, depending on what they have implemented, so make sure to proceed with caution.  If that is not a concern for you, then also consider capacity, throttling, throughput, etc. Messaging as a service can be a great option, but each situation has conditions that should be evaluated for proper fit.

Running your own solution – Leading Message Queuing Products

Let’s take a look at a list of some of the leading, successful message queuing products available right now.

1)    RabbitMQ

RabbitMQ has been widely accepted, largely due to its open-source status. The code is minimalistic and serves as a perfect message queuing product for both small and large-scale implementations. It comes across with multiple messaging protocols that are asynchronous. RabbitMQ runs smoothly across multiple operating systems and offers support to cloud environments.

What protocol does RabbitMQ Support?

RabbitMQ supports a wide range of messaging protocols. Either the code directly supports all these protocols or offers plugins. The core of RabbitMQ was coded to support AMQP a binary protocol. With the newer versions of AMQP, RabbitMQ has extended its support. STOMP is a messaging protocol based on text and is the only protocol that can be used by over telnet, a client-server protocol. RabbitMQ plugin supports all versions of STOMP. MQTT protocol receives support for lightweight subscription messaging and messaging semantics from RabbitMQ. AMQP 1.0 is one of the complex protocols supported by RabbitMQ plugins. For HTTP, RabbitMQ can transmit messages even when it is not a messaging protocol.

What standards do they conform to?

RabbitMQ conforms to AMQP (Advanced Message Queuing Protocol).

Synchronous vs. asynchronous support

RabbitMQ supports asynchronous messaging, which means the applications do not have to wait for a real-time response.

Configuration Considerations for High Availability clusters

While RabbitMQ can be deployed in distributed and federated configurations, it can handle complex message queuing needs very well.

What types of plugins/connectors are supported?

RabbitMQ supports the following plugins and connectors: rabbitmq_amqp1_0, rabbitmq_auth_backend_ldap, rabbitmq_auth_mechanism_ssl, rabbitmq_consistent_hash_exchange, rabbitmq_federation, rabbitmq_federation_management, rabbitmq_management, rabbitmq_management_agent, rabbitmq_mqtt, rabbitmq_shovel, rabbitmq_shovel_management, rabbitmq_stomp, rabbitmq_tracing, rabbitmq_trust_store, rabbitmq_web_stomp, rabbitmq_web_mqtt, rabbitmq_web_stomp_examples, rabbitmq_web_mqtt_examples

2)    Apache ActiveMQ

Apache ActiveMQ is an open source message queuing product developed in Java and integrated with JMS client. Along with enterprise features, it supports multiple cross language clients or servers.

What protocols do they support?

Apache ActiveMQ supports 10 protocols for multiple wire levels offering extensive interoperability. The core code of Apache ActiveMQ was coded to support the OASIS standard for AMQP binary protocol, although the newer versions of Apache ActiveMQ 5.13.0 support wire format protocol detection for the Auto protocol. MQTT protocol is an M2M publish messaging transport that is supported by Apache ActiveMQ and helps in the automatic mapping of JMS and MQTT client. OpenWire is a cross-language wire protocol supported by Apache ActiveMQ. The OpenWire protocol facilitates access to ActiveMQ from a set of varied languages and multiple platforms. Apache ActiveMQ maps REST protocol to JMS. Apart from these, it supports RSS, Atom, Stomp, WSIF, WS notification and XMPP.

What standards do they conform to?

All JAVA standards are supported by Apache ActiveMQ. J2EE, JMS 1.0 and JMS 2.0 are all offered along with extensive support.

Synchronous vs. asynchronous support

By default, Apache ActiveMQ supports synchronous message sending for all persistent messages. It is possible to enable asynchronous message sending, however, by following these steps:

  • Set up useAsyncSend property on the ActiveMQConnectionFactory.
  • Set up the property via the URI.

Configuration Considerations for High Availability clusters

Apache ActiveMQ can be deployed in distributed and federated configurations.

What types of plugins/connectors are supported by Apache ActiveMQ?

Maven2 plugin to easily start up a JMS broker., Destination Plugin, TimeStamp Plugin, Statistics Plugin

3)    JORAM

JORAM, which stands for “Java Open Reliable Asynchronous Messaging,” is an open source Java implementation of JMS and offers high availability for clusters. JORAM stands for Java open reliable Asynchronous Messaging and offers high availability for clusters.

JORAM offers full support for JMS 1.1, JMS 2.0 and Java EE as an open source software support component. It is perfect for a heterogeneous system and various Java platform. Programs can easily serve as mature messaging solutions without being dependent upon third-party plugins. JORAM also features atomic storage for a long queue. For remote clients and servers, it offers TCP based implementation.

What protocols do they support? 

JORAM supports asynchronous messaging and offers plugin support like AMQP, MQTT, STOMP and more. Beyond that, JORAM supports the following web protocols: TCP/IP, HTTP, SOAP-XML, SSL.

What types of plugins/connectors are supported by JORAM?

JORAM supports the following plugins and connectors: TxLog, Batch engine, Batch network

Synchronous vs. asynchronous support

Due in large part to its commitment to atomic transactions, JORAM offers optimized messaging, allowing quick transactions on persistent messages. Transaction logs are handled by asynchronous sync. JORAM offers queuing, subscription matching, message routing, and high runtime performance because it handles transactions in batches. The communication over JORAM is secure and reliable so transmission latency is never increased. Few plugins facilitate bi-directional communication over a single connection, which is a major pull factor for JORAM.

What standards do they conform to?

JORAM is extremely compliant with JMS 1.1, JMS 2.0 and Java EE. JMS plug-in applications are seamlessly integrated with the extensive supports. When it comes to protocols, JORAM supports basic internet and web-based protocols.

Configuration Considerations for High Availability clusters

High availability clusters’ configuration provider is a3servers.xml. The XML file is required only when starting a server – if you wish to start a new server, it will be necessary to stop the current server and send a new a3servers.xml to be read.

JORAM supports transient, persistent, transactional and XA messaging, and sessions can be listed down in a JTA transaction, which is easily registered as per JTA semantics. JORAM offers complete specification support to JMS 1.1 and JMS 2.0.

JORAM is an open-source software component supporting asynchronous messaging and supports heterogeneous systems from J2EETM to J2METM. It comes across successfully as a new- age, mature messaging solution with high capability. The messaging queue does not need a high degree of third-party support, as it has inherent atomic storage and a distributed JNDI server.

Comparison

Having reviewed these messaging Queue Products individually, it may be helpful to compare them side by side to gain a view of their real capabilities – along with a few other prominent players. Here, we lay out their various advantages and disadvantages in terms of Durability, Security Policies, Message Purging Policies, and Message Filtering.

The Benefits of Message Queuing Tools

There is a wide variety of benefits associated with message queueing tools, as we’ve examined in technical detail above. Here is a quick overview of some of their more general benefits that may end up informing your decisions:

  • Programs do not need direct connections.
  • Communication channels are not time-dependent with an asynchronous mode.
  • Small programs work well with a decoupled mode.
  • Events drive the communication propagation.
  • They allow prioritization and filtering of messages.
  • They allow secure message propagation.
  • They maintain data integrity.
  • They support the recovery of messages.

 Message queuing often offers improved performance, increased reliability, granular scalability and simplified decoupling. Beyond that, message queuing reduces the need for direct program communication. High scale data integrity is also provided, as the work is divided into smaller units of work.

While there are many different options that are available, make sure you take the time to examine the options and take careful stock of what each messaging queue product does or does not offer. I hope this guide has provided some insightful information that helps you determine your approach to choosing the product that best serves your needs.

Leave a Reply

Your email address will not be published. Required fields are marked *