I spent the last week deep diving into the Akka docs and finally understand what actor systems are, and the problems that they solve.My understanding (and experience with) traditional JMS/AMQP message brokers is that they exist to provide the following:Asynchronous processing between producer and consumer; andMessage delivery guarantee, included persistence, retries and fallbacksBut doesn't Akka provide this, without all the required infrastructure and operational overhead?In Akka, all Actor communication is asynchronous and non-blocking; andIn Akka, SupervisorStrategies exist to accomplish retry, fallback and escalation. Actors can be configured to persist to virtually any type of store, if this is a requirement too.So this has me wondering: if my app uses Akka, do I ever have a need to bring JMS/AMQP brokers (e.g. ActiveMQ, RabbitMQ, Kafka) into the picture? In other words, is there ever a use case where a new Akka-based app would then also warrant the introduction of a new JMS/AMQP broker cluster? Why or why not?The only argument would be that perhaps my Akka app has to integrate with another system. But in that case, the Akka-Camel module allows Akka to tap into Camel's exhaustive, almost infinite list of integration capabilities (TCP, FTP, ZeroMQ, the list goes on and on...).Thoughts?
Does Akka obsolesce JMS/AMQP message brokers?
asynchronous programming;message queue;messaging;akka