ActiveMQ Training Shorts - Fundamentals
Matt Pavlovich discusses the capabilities of Apache ActiveMQ, a mature, open-source, standards-based message broker that supports JMS, MQTT, STOMP, and AMPQ protocols, with updates to JMS 3.1 and 2.0 in versions 6.x and 5.18. ActiveMQ is multi-protocol and multi-language, supporting various programming languages and offering a REST API for command-line messaging. It is highly scalable, embeddable, and can run on diverse platforms. Deployment options include standalone, clustered, and primary failover brokers, with DevOps benefits for app dev teams. ActiveMQ facilitates end-to-end integration testing within application code, providing isolated environments for reliable messaging assurance. It uses JMS terminology for internal objects and follows a standard address format for destinations, including queues, topics, and their temporary counterparts.
Video Contents (3:55)
So Apache ActiveMQ is open source, standards based Message Broker is designed to support the JMS standard. It's very mature and stable. The protocols it supports are JMS 1.1, MQTT, STOMP and AMQP. This slide should be updated. It now supports JMS V 3.1 as well as JMS 2.0 with the ActiveMQ 6.x and 5.18, releases. HYTE's proud and happy to have been a key contributor and moving those protocols and capabilities forward. From a language perspective, there's lots of language bindings that you can use to talk to ActiveMQ, including Java, C#, Ruby, Python, PHP, Perl. The availability of a REST API also ensures that you can use command line to send messages into ActiveMQ brokers and then stomp really enables things like web sockets and JavaScript in any language. So while ActiveMQ itself is written in Java in JMS, you're not by any means restricting your, the applications that you can service to only Java or JMS, It's a what they call a polyglot broker, so it supports multi-protocol and multi-language is quite well.
It's very scalable. It can run it can be embedded. So it can run on something smaller, embed as a Raspberry Pi. It can be embedded in different run times, which creates really unique architecture capabilities from a compute perspective, running in bare metal virtual machine or containers are all widely used, widely adopted and very stable.
Deployments. When we talk about deployments, we have topology building blocks. So we'll have a standalone broker, we'll have clustered brokers, and then we'll use Primary-Failover. Primary-Failover is the term that we use for what was formerly known as master slave. So Primary-Failover share a data store. Where clustering our single or pairs of primary failover brokers clustered together. So we'll use these different topology building blocks that talk about all the possible architectures. So these three kind of key building blocks, and you can build any architecture that you need for messaging.
From a DevOps perspective, this is a really, really, really powerful and I feel like underused capability in ActiveMQ, especially for your app dev teams. Something to keep in mind is ActiveMQ is essentially a library. This means it's really easy and straightforward to write end-to-end integration tests within application code. So what this means is an app dev can fire up an ActiveMQ broker, write a unit test that sends and receives messages to validate their code. So they can run an integration test against a real broker, and it can be dynamic and set up, and so it could build up the broker and tear it down for the test suite. This provides just a high, high value assurance to the application that the messaging communications working end to end without doing mocks. And so we really encourage application teams to explore this capability as it makes it a lot easier to automate and verify application testing without having to hit like a dev environment, which can be tricky to coordinate, because hitting development environments can have coordination issues, where if you have multiple copies of the test running, they may get unexpected results, whereas if they run an embedded unit test within just their test suite, they kind of get an isolated broker just for the run of that test suite. So very powerful, great capability.
ActiveMQ objects, or the internal objects, follow the JMS terminology, and those are mapped to other protocols to their JMS equivalent. From a destination perspective, there's four, what we call primitive destinations, or core destination types. So you have a queue, a topic, a temporary queue or a temporary topic, and they have an address format that follows the JMS standard, where you have queue or topic or temp topic, and temp queue with a colon and a pair of slashes and then the name of the queue or the name of the topic.
