What design decisions would favour Scala's Actors instead of JMS?

Solution 1:

JMS and Scala actors share a theoretical similarity but don't think of them as necessarily solving the same problems architecturally. Actors are meant to be a lightweight alternative to shared-memory concurrency where races and deadlocks are generally harder to accidentally create. JMS is a sophisticated API that's meant to span direct messaging, publish/subscribe, transactions, EJB integration, etc.

The closest JMS equivalent to an actor would be a message driven bean that is backed by a non-persistent, non-transactional, non-pub/sub queue. I'll call that a "simple JMS bean".

Now, to your questions.

Performance is a hard thing to talk about since JMS is a specification rather than an implementation. None-the-less when using simple JMS bean I'd expect performance to be roughly similar with perhaps a bit of an edge to the actor in time and memory. As you add capabilities to JMS such as pub/sub, transactions, etc performance will naturally degrade even further but then you're trying to compare apples to oranges.

As for scalability, simple JMS beans should scale pretty much exactly the same way as actors. Adding transactions into the JMS mix will naturally hurt scalability by an amount depending on the scope of the transactions.

The broader question of what do actors do that JMS can't. Well, without built-in pub sub or transactions it would seem that actors subtract from JMS - and broadly that's true. But here's the thing: actors require so little code that I can happily use them for very fine grained concurrency. In ordinary Java code I might say "I don't feel like screwing with JMS and its dependencies or the code it requires etc so I'll just spawn a thread, use a lock, and share a data structure." With Scala actors I'm much more likely to say "I'll just whip up an actor and move on."

There's also a philosophical difference in design. Actors have a simple, built in concept of supervisor hierarchies. Actors are usually used in a "let it crash" design. If an actor dies for some reason then another actor is responsible for deciding what to do about it such as restarting that actor, killing a bunch of actors and restarting all of them, or killing a bunch of actors and itself so that some otther actor can deal with the problem. That kind of thing can appended onto JMS, but it's not core to the API and must be managed externally somehow.

By the way, for a Scala actor library that moves more into the realms that JMS covers see Akka. Akka also brings a declarative approach to many common actor hierarchy strategies.