23

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; and
  • Message delivery guarantee, included persistence, retries and fallbacks

But doesn't Akka provide this, without all the required infrastructure and operational overhead?

  • In Akka, all Actor communication is asynchronous and non-blocking; and
  • In 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?

smeeb
  • 4,820
  • 10
  • 30
  • 49
  • 3
    Isn't your last paragraph a reason why Akka doesn't make message brokers obsolete? For example, I'm working on a Java application that interacts with remote C++ applications via a JMS-compliant message broker. I could write my Java application using Akka-Camel, but I would still need the broker because of the C++ application. – Thomas Owens Jul 24 '15 at 13:31
  • Ahhh thanks @ThomasOwens (+1) but you have (rightfully so) misunderstood my question. I'll change the wording in a few minutes so that its more obvious. What I'm really asking is: if I am building an Akka app, would I ever need to *also* introduce a *new* JMS/AMQP broker? I think the answer is "no", because Akka + Camel (again I *think*) solve all the problems typically solved by a broker. In your example, the JMS broker *already exists* as the way to communicate with the C++ app; I'm not adding it along with my new Akka app. And so the Akka-Camel module will take care of messaging for me. – smeeb Jul 24 '15 at 13:58
  • 2
    Maybe I'm misunderstanding, but Camel doesn't replace JMS (for example), but it provides an interface that can be used to send messages via JMS. You can replace JMS with AMQP, RabbitMQ, or XMPP. In my example, even if my Java+Akka and C++ applications were brand new, in order for them to communicate over JMS, I'd still need to introduce some kind of JMS-compliant message queue and then I could use Akka-Camel to communicate with it. Camel doesn't provide a broker, just means for communicating within a number of protocols. Akka-Camel provides a more familiar interface over Camel's interface. – Thomas Owens Jul 24 '15 at 14:23
  • Thanks again @ThomasOwens (+1) - I think you're just overthinking this :-). In your example there is an *existing C++* app - perhaps some legacy system, and there is an *existing JMS-compliant broker* that the C++ app *already* uses for integrating with the outside world. In this case, my new Akka app would - just like you said - use the Akka-Camel module to produce/consume messages to/from this broker. **But this is not what I'm askin here!** I'm wondering if there is ever a reason that I would need to build **2 things**: (1) my new Akka app, and (2) a JMS/AMQP broker, *at the same time*... – smeeb Jul 24 '15 at 14:39
  • ...in your example above, if we changed things such that the C++ app did not already allow integration via JMS-compliant broker, then either: (a) there is no way to integrate the Akka app with the C++ app without refactoring the C++ app, or (b) perhaps the C++ app also communicates over TCP, in which case the Akka-Camel module is again the solution. **Any way you cut it, I don't see any reason why a new Akka app would have to introduce a new JMS/AMQP broker as part of a distributed solution, because Akka + Camel gives us just about anything we need.** – smeeb Jul 24 '15 at 14:41
  • 3
    You mention Camel's infinite integration capabilities but it can't integrate with Nothing. There needs to be something for it to integrate with, otherwise you're just enjoying the support for a bunch of services that you aren't running. Kick up JMS, or an HTTP or FTP server or something if you want to use Camel to integrate with something. Otherwise it's just blissfully providing infinite integration capabilities while integrating with nothing. – Jimmy Hoffa Jul 24 '15 at 15:49
  • Thanks @JimmyHoffa (+1) and this exact point was mentioned in my last comment above where I say "*...if we change things such that the C++ app did not already integrate via JMS-compliant broker...then there is no way to itegrate [with it].*" I understand this point, however I can't just "kick up" a JMS broker and gain immediate integration in this case; I would need to make changes to the C++ app to make it integrate-able. And so my original claim stands: there does not seem to be any reason why Akka + JMS/AMQP would ever be preferable over Akka + Camel. – smeeb Jul 24 '15 at 16:55
  • Again, because: (a) if the C++ app already integrates with JMS, then the integration solution is Akka + Camel, but (b) if the C++ app does not allow integrations (with JMS or anything else), then we must make changes to it to make it integrate-able. We *could* choose to make it work with JMS, and then go with an Akka + Camel + JMS broker solution, but in this case, we would just make things simple and have the C++ app integrate with REST or the likes, and then the integration solution is just Akka + Camel. – smeeb Jul 24 '15 at 17:02

1 Answers1

18

Actor Model

The actor model is computer science strategy for building applications that handle lots of concurrent computation and stateful processing. It's not the only strategy but it's a very well tested, simple, and reliable approach that moves computation into actors, which communicate through messages that they process one-at-a-time and in order.

Akka is a framework that implements the actor model and allows you to build actor systems with all the infrastructure and features already built (like using JQuery instead of javascript).

Messaging

Message systems are applications that can send and retrieve messages. There are many varieties from basic queues to big enterprise software with topics, pub/sub, persistence and other features but the end goal is the same. Save some bytes somewhere and retrieve them again later, with some kind of ordering. The primary use case today is to decouple systems and allow for asynchronous processing at different schedules or speed. RabbitMQ, NATS, Kafka, etc are all examples of message systems.

Comparison

The Actor model and the Akka framework are low-level tools that are a great way to build applications, like message queues.

Can you use Akka instead of a message queue? Sure. If you're building software that already uses the actor model then you probably don't need an external message queue, especially for sending messages within the same thread or application. You can use Akka Remoting capabilities to even send messages to other actor systems running on other machines.

However, does this make messaging systems obsolete? Absolutely not. Just because you can code all this stuff yourself doesn't mean you need to, especially when an actor model isn't a good for your problem or you need different languages, applications, external APIs, operating systems, databases, etc. to communicate with each other (whether they are actor systems or not).

If you just need to pass some messages between two systems, use a message queue. If you need scalable stateful processing and low-latency messaging within the same application, then use the actor model. They both exist at completely different levels and how you use them depends on the solution you're building.

There's a great answer on SO about this same actor model vs messaging: https://stackoverflow.com/questions/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq-or-tibco

Mani Gandham
  • 280
  • 2
  • 8