Try our new open source stack builder and get a free, customized report >> Get Started
ActiveMQ is a popular messaging service. Here, we break down:
ActiveMQ is a popular open source messaging service that is built on top of Java. It works as a message-oriented middleware (MoM).
ActiveMQ is designed to send messages between two or more applications, just like all message-oriented middleware.
Like any other message broker, this tool is used as a communication bridge between multiple components that can be hosted on separate servers or can be written in different programming languages.
Message brokers like this one are often found in enterprise systems — or any systems that have a complex architecture. The goal of implementation is to create reliable communication between components of that system.
A good example is the financial and banking industry, where a high availability system is essential. Speed is important in this industry, but more important than that is the reliability of the entire system.
Even though we all want 100% uptime for everything, there will still be rare moments when a service is offline. What do you do in this case?
Putting your message into a message queue will usually work in this scenario. The message doesn't get delivered and processed immediately. Instead, it will be processed when the other side of the service comes back online.
The example above is a niche case. But the overall use case of messaging is the ability to asynchronously shape traffic. There might be cases when the service is still online, but it may just not be able to process messages as quickly as they are produced into the system. Or it might not be able to handle a burst without some padding.
So, if you have a system — and it is a must for a message to be sent no matter what and no matter the time frame, now or later — then a message broker like ActiveMQ is what you need.
Apache ActiveMQ brokers are implementations of the Java Messaging Service, or JMS. JMS is a Java specification which allows applications to send data back and forth between one another in an easy and standard way.
Before messaging systems like ActiveMQ, it was difficult — if not impossible — to “federate” applications that:
An early goal of Java was to present a language with the power of C which was not hindered by its cross-platform issues. JMS arose out of a growing need to federate very different systems with each other.
Before ActiveMQ, that meant building the source code against native tooling and libraries. Alternatives were outright porting or rewriting the application on separate operating systems.
ActiveMQ is a JMS provider. A JMS provider forms the software framework for facilitating the use of JMS concepts inside an application. A single node of ActiveMQ which allows clients to connect to it and use these messaging concepts is called an “ActiveMQ Broker.”
So, ActiveMQ is a message broker that implements JMS. Using ActiveMQ is important for many businesses — especially enterprises.
Enterprises feel this disparity with business actions such as mergers and acquisitions. This creates the need to maintain an increasingly heterogeneous collection of business applications. As your enterprise grows, so does the need to allow all of these platforms to share data. A number of architectural patterns exist today which help to solve this problem.
Some other examples of JMS providers are:
ActiveMQ Is Just One Part of Your StackActiveMQ is just one part of your open source stack. You're likely leveraging other technologies. And there are still more open source technologies you can benefit from. Build your organization's ideal open source stack. Use the OpenLogic Stack Builder to get a custom report from our experts of your stack.Stack Builder
ActiveMQ is just one part of your open source stack. You're likely leveraging other technologies. And there are still more open source technologies you can benefit from. Build your organization's ideal open source stack. Use the OpenLogic Stack Builder to get a custom report from our experts of your stack.
ActiveMQ's anatomy consists of data patterns called messages, queues, and topics.
Messages are just what they sound like, payloads of data that can be shipped between various systems. These payloads can have headers and properties associated with them that can:
Here's a basic JMS structure, such as ActiveMQ:
The payload itself can be any Java object in a pure-Java implementation. But it is typically some form of text message. Note that the text could be a markup format such as XML or JSON as well. The purpose of a messaging system is to move these payloads between heterogeneous systems in a standard way.
An enterprise-class messaging solution can do this while also maintaining data integrity, guaranteeing no data loss, considering high availability, security, recoverability, and other common enterprise concerns.
The applications themselves within our network are thought of as endpoints. And there are two categories of them. Inbound endpoints which are used to read or receive messages are called consumers, and outbound ones meant to send data into the messaging system are called producers.
This is handled programmatically. The endpoint is defined in the context of the program that is interacting with the messaging system.
Once messages make their way into the system, they are arranged into two patterns: queues and topics. Queues areFIFO (first-in, first out) pipelines of messages produced and consumed by brokers and clients. Producers create messages and push them onto these queues. Then those messages are polled and collected by consumer applications, one message at a time.
Topics are subscription-based message broadcast channels. When a producing application sends a message, multiple recipients who are ‘subscribed’ to that topic receive a broadcast of the message. This producing application is sometimes called a ‘publisher’ in the context of topic messaging,
All of these components are just parts of the JMS specification, but aren’t any one piece of software in particular. To realize the specification in real life, we can create a vendor-specific implementation of the JMS spec, known as a JMS provider.
To sum up, the main difference between aqueue and a topic is:
Over and above JMS, ActiveMQ provides additional functionality such as:
Apache ActiveMQ 5 implements the JMS 1.1 spec. ActiveMQ 6 (Artemis) will implement JMS 2.0.
In addition to the JMS concepts described above, ActiveMQ also providers persistence. This allows messages to be “replayed” should a broker crash. Along with that, durability allows topic subscribers to receive broadcast messages when connectivity to the broker has been interrupted.
ActiveMQ is a mature and well-adopted platform. 1,000s of companies use it. It's by far the most flexible OSS message broker available.
As if that’s not enough, it also ships with Apache Camel and shares developers and committers with the Apache Camel product. This gives it a tremendous level of sophistication in terms of designing complex messaging patterns.
Apache ActiveMQ is free and open source under the permissive Apache 2.0 ASF license. It is backed by a prolific and responsive developer community and was envisioned by some of the early creators of the now ubiquitous Enterprise Integration Pattern (EIP) architecture.
Putting together these patterns with JMS makes it easy to understand how ActiveMQ works. ActiveMQ brokers themselves support a number of connection protocols, allowing them to provide highly normalized connection points between applications coded in different languages, such as Java, C++, .NET, PHP, and others.
This makes ActiveMQ an ideal free messaging solution for enterprises. Users commonly migrate to ActiveMQ from commercial middleware such as WebSphereMQ, Oracle AQ, TIBCO EMS, and/or MSMQ.
ActiveMQ can be tuned for massive scale, supporting large data sets, such as those generated by the CERN large hadron collider. Its configuration can support numerous traffic and implementation models and has a powerful statistics and metrics engine, exposing crucial details about the health of the broker and the amount and size of message traffic and client status. These metrics can be consumed by popular monitoring frameworks, making ActiveMQ a highly observable solution.
Though not the only free messaging solution available, Apache ActiveMQ stands out for balancing its versatility with enterprise-readiness. You can adopt ActiveMQ quickly. It will be accessible to anyone comfortable with JMS. ActiveMQ’s prolific community will ensure the products continued viability. And ActiveMQ 6 promises to extend this usefulness into the next generation of enterprise messaging solutions.
Looking to get started with Apache ActiveMQ? Connect with one of our open source architects to get answers to your questions and to learn more about migration, innovation, cost-savings, and much more. Connect with an expert today to learn how we can help you get the most out of ActiveMQ.
TALK TO AN ACTIVEMQ EXPERT
Chief Evangelist - OSS & API Management, Perforce Software
Justin has over 20 years of experience working in various software roles. He is an outspoken free software evangelist, delivering enterprise solutions, technical leadership, and community education on databases, architectures, and integration projects.