We Can Have More… EnMasse!
We Can Have More… EnMasse!
This overview of the open source EnMasse compares it to other messaging platforms and covers the basics of its use in messaging or IoT apps.
Join the DZone community and get the full member experience.Join For Free
This morning, my working day started in a different way with interesting news from AWS re:Invent 2017, the annual Amazon conference.
The news was about Amazon MQ, a new managed message broker service based on ActiveMQ 5.x with all the goodies that it provides in terms of supported protocols like MQTT, JMS, STOMP, and yes, AMQP 1.0!
It seems that this news made Clemens Vaster (from Microsoft) happy as well
Finally, even Amazon added support for a “real” messaging protocol which is enterprise-ready and from my point of view… even IoT ready
With this news, another project came to my mind. EnMasse !
We Can Have More: EnMasse
What AmazonMQ provides is the possibility to create a new broker instance, then accessing the console, creating queues, topics and so on. It’s great but… we can have more !
EnMasse is an open source “messaging as a service” platform that simplifies the deployment of a messaging infrastructure both “on-premise” and in the cloud. It provides scalability and elasticity in order to address all the problems we can have when the number of connected clients increases (and decreases), even reaching big numbers like in an IoT scenario.
It supports all the well-known messaging patterns (request/reply, publish/subscribe, and competing consumers) and, for now, two main protocols, AMQP 1.0 and MQTT (but HTTP support is on the roadmap).
It provides multi-tenancy, having different tenants sharing the same infrastructure but being isolated from each other. Finally, it provides security in terms of using the TLS protocol to establish connections (with clients and between internal components) aside from authentication using Keycloak as the identity management system.
Store and Forward or Direct?
One of the main features it provides is the support for two different messaging mechanisms, “store and forward” and “direct messaging”.
The “store and forward” mechanism is exactly what the messaging brokers provide today. The broker takes the ownership of the message sent by a producer before forwarding this message to a consumer asking for it (connecting to a queue or a topic on the broker itself). It means that “storing” the message is the first step executed by the broker and “forwarding” is the next one, which can happen later, only when a consumer is online to get the message: It allows asynchronous communication between clients and time decoupling. There is always a double contract between producer-broker and broker-consumer so that the producer knows that the messages have reached the broker but not the consumer (a new message exchange in the opposite direction is needed to have something like an “acknowledgment” from the consumer).
The “direct messaging” mechanism is not something new because it means having a sort of “direct” communication between clients so that the producer is able to send the message only when the consumer is online with a single contract between the parties: When the producer receives the “acknowledgement”, it means that the consumer has got the message. Of course, EnMasse provides this mechanism in a reliable way: It uses an AMQP 1.0 router network (connected in a mesh) so that clients aren’t really connected in a direct way — but through this mesh.
Every router, unlike a broker, doesn’t take ownership of the message, but just forwards it to the next hop in the network in order to reach the destination. When a router crashes, the network is automatically re-configured in order to determine a new path to reach the consumer; it means that high availability is provided in terms of “path redundancy”. Furthermore, thanks to the AMQP 1.0 protocol, a producer doesn’t receive “credits” from a router to send messages if the consumer isn’t online or can’t process more messages.
EnMasse provides these messaging mechanisms using two open source projects: Apache Qpid Dispatch Router (for the router network) and ActiveMQ Artemis (so ActiveMQ 6.x and not 5.x like in AmazonMQ) for the broker side.
I Only Want to Know About “Addresses”!
Comparing EnMasse to the new AmazonMQ service, from a developer point of view, the interesting part is the abstraction layer that EnMasse adds to the underlying messaging infrastructure. You can create a new “address” using the console and specify a type, which can be:
- queue: backed by a broker for “store and forward”, providing a competing consumer pattern, asynchronous communication, and so on.
- topic: backed by a broker for “store and forward” as well but for providing a publish/subscribe pattern.
- anycast: something like a queue, but in terms of “direct messaging”. A producer can send messages to such an address only when one or more consumers are listening to it, and the router network will deliver them in a competing consumer fashion.
- multicast: something like a topic ,but in terms of “direct messaging”. This is for having a producer publish messages to more consumers listening to the same address so that all of them receive the same message.
The developer doesn’t have to worry about creating the broker, configuring the routers, and so on; using the console and a few simple steps in the wizard, you will have a usable “address” for exchanging messages between clients.
Good for Microservices
The interesting part of supporting a “direct messaging” mechanism is the microservices world. EnMasse can be used as a messaging infrastructure for handling requests/replies and publish/subscribe between microservices using an enterprise protocol like AMQP 1.0.
Orchestration: OpenShift and Kubernetes
Another aspect that makes EnMasse more appealing than other solutions is that it’s totally containerized and runs on the main container orchestration platforms like Kubernetes and the enterprise OpenShift (using the OpenShift Origin project as well). It means that your messaging-based (or IoT) solution can be deployed on-premise and then easily moved to the cloud without any changes to your applications (maybe just the addresses for establishing the connections from clients).
Of course, this blog post didn’t mean to be an exhaustive guide on what EnMasse is, but just a brief introduction that I've wanted to write for a long time. The Amazon news gave me this opportunity to show you that you can really have more than just a broker in the cloud.
Published at DZone with permission of Paolo Patierno , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.