You are using an older browser that might negatively affect how this site is displayed. Please update to a modern browser to have a better experience. Sorry for the inconvenience!

Apache ActiveMQ

By: Santhosh

This is a brief introduction to application integration and ActiveMQ. Before we see how ActiveMQ helps in integration, let us see why we need integration and what some of the challenges of integration are.

With the enormous growth of technology, the range of applications within an enterprise has also grown, and this growth has led the new applications to communicate with legacy applications and databases. Besides, an application may require data from other applications within the enterprise or from outside.

The solution to the above scenarios is achieved by integrating disparate applications. In general, the main purpose of enterprise integration is to build effective communication among applications irrespective of their platform.

Before Messaging Services came in handy for integration purposes, there were many other services in place, as explained below:

1. File Transfer: In this service, the data to be shared between the two applications were stored in a file with a specific format, and placed at a common location agreed by both sides. This required locking of files, complete knowledge of applications involved, and translation at one end–which were all the draw backs.
2. Shared Database: Applications can communicate when they have a common database; hence, the required data can be accessed by all the applications. The drawback of this solution is designing a common schema to meet the needs of all applications. In addition, when multiple applications try to access same data, they might suffer from network delays and deadlocks—these together may cause the applications to crash at times.
3. Remote Method Invocation or Call: Here, when an application needs data from a remote application, it makes a remote call to the other application, leading to poor response times and making the application slow and unreliable.

The above solutions are either tightly coupled or support only synchronous communication, and this paved a way for the Messaging Services or Message Oriented Middleware (MOM).

When using a MOM, client applications send the messages to a destination managed by the messaging provider, and the receiving applications subscribe to the same destination and fetch the messages. This communication model makes the applications to be loosely coupled and allows asynchronous communication. Thus, the MOM acts as an agent between the applications. When applications are loosely coupled, they are easy to maintain and changes in one application have no impact on other applications. Hence, MOM is an ideal solution for integrating applications.

ActiveMQ is an MOM from Apache that is built completely based on Java Messaging Services (JMS) 1.1. In ActiveMQ implementation, the application that sends messages is called the Message Producer, and the receiving application becomes the Message Consumer. Here, the destination may be a queue or topic depending on the communication type. The ActiveMQ instance is known as Broker.

Types of ActiveMQ Messaging
Point-to-Point Messaging: In this type of messaging, the producer sends the messages to the Queues on the ActiveMQ. Each message received by the queue is delivered to only to one consumer. The messages are retained on the queue until they are consumed by the consumer or expire. A queue can have any number of consumers and producers. When multiple consumers are present, the messages are delivered to consumers in a round robin fashion. In other words, each message is consumed by only one consumer.


Publish/Subscribe Messaging: Publishers are message producers that send their messages to a topic. Consumers are subscribers that subscribe to the topic to receive the messages. Any message that is sent to a topic is delivered to all subscribers of the topic. There are two types of subscription: durable and non-durable. In a durable subscription, when a subscriber is disconnected, the messages sent during that period are retained, so that the subscriber can reconnect and receive unexpired messages later. Whereas, in the non-durable subscription, the messages are not retained when subscriber is disconnected.


Features of ActiveMQ
ActiveMQ has abundant features which make them a good fit for integration. Some of the important features:

1. Connectivity: ActiveMQ supports a wide range of protocols such as HTTP/S, IP multicast, SSL, STOMP, TCP, UDP, XMPP and more. It makes ActiveMQ to be easily adopted.
2. Client API: ActiveMQ provides client APIs for several languages like C/C++, .NET, Perl, PHP, Python, Ruby and more. Though ActiveMQ is written in Java, these APIs allow them to have clients from various platform.
3. Broker Clustering: Multiple instance of ActiveMQ can combine to form a network of Brokers, and it is efficient in supporting different topologies
4. Simplified Administration & Integration with Servers: ActiveMQ is designed in such a way that it doesn’t require a separate administrator for maintenance. Since it was developed in Java, it can be easily integrated with other Java containers such as Apache Tomcat, Jetty, Apache Geronimo and JBoss.

ActiveMQ is an open-source messaging system written in Java, and it allows effective, reliable, and asynchronous communication among disparate applications.