Akka TypedActor vs. writing my own static interface to an Actor class

Question

I've been using Akka and Scala for about a month and I'm somewhat bothered by replacing explicit interfaces with messages. Consider the following simple Akka Actor:

case class DoMyHomework()
class Parent extends Actor {
  def receive = {
    case d: DoMyHomework => // do nothing
  }
}

Actor or non-actor code that sends this actor a DoMyHomework message like this:

ActorRef parent = ...
parent.ask(DoMyHomework)

Has no idea what the outcome will be. What's the type of the answer? Will I ever get an answer? Can I get an exception? And so on.

The fix seems to be to document the case class... but what if some other actor also receives that same case class. Then the documentation should for receiving that message should be in the actor itself.

In an effort to clean this up a little I thought of doing the following:

trait SomeoneSmarter {
  def wouldYouDoMyHomework: Future[Boolean] 
}
class Parent extends Actor with SomeoneSmarter {
  case class DoMyHomework()
  def wouldYouDoMyHomework = {
    (self ? DoMyHomework()).mapTo(Boolean)
  }
  def receive = {
    case d: DoMyHomework =>
      // TODO: If I'm busy schedule a false "No way" reply for a few seconds from now.
      // Just to keep their hopes up for a while. Otherwise, say sure right away.
  }
}

So, I chatted with colleagues about this and one of the reactions was "you're not being true to the actor model."

First, I would really appreciate some guidance from folks that have been using Actors for a longer time. Do all the messages become unwieldy? Do you end up hiding message-passing behind interfaces?

The actors I'm proposing still have the option of sending messages among themselves, subscribing to event streams, all the stuff you expect from Akka. And the interface gives you a time-tested way of knowing what you're talking to. And it helps when coding in IDEs, and so on. And why should the user of an actor need to know it's an actor (unless it's also an actor and is very tightly coupled with it)?

The other reaction I got was "it looks like you want a TypedActor". But after reading about TypedActor I'm not convinced. Certainly TypedActor saves me the trouble of creating those internal messages. But, at least from the code sample at http://doc.akka.io/docs/akka/snapshot/scala/typed-actors.html I get the impression that the TypedActor is meant only to work as a proxy around a block of code you want to encapsulate, or make thread-safe, or simply not call directly from your current thread. And what you code is just the implementation and interface. You don't mess with the actor itself (the proxy) - e.g. if you want your implementation to do periodic work or subscribe to an event stream, or do anything else unrelated to the interface.

I've also read http://letitcrash.com/post/19074284309/when-to-use-typedactors and didn't find that example more illuminating. I'm probably just not grokking TypedActor (not that I claim to have really understood Actors yet).

thanks in advance for help.

Pino

There's a post on the Akka mailing list that outlines using a wrapper class to support typing actors although here typing does not cover everything that Pino is discussing: groups.google.com/forum/#!topic/akka-user/THMgHyO21To — Mark Butler
There's an interesting post here that provides a critique of Akka actors failing to provide types: noelwelsh.com/programming/2013/03/04/… — Mark Butler

Roland Kuhn Roland Kuhn · Accepted Answer · 2012-09-30T21:10:39

Actor Encapsulation

Let me first respond to one point which I think is very important. You say:

And why should the user of an actor need to know it's an actor (unless it's also an actor and is very tightly coupled with it)?

Actors are a radically different programming paradigm from conventional OO, the main difference is that everything is asynchronous and hence there never are real “return values”. This means that it is usually a bad idea to hide the fact that it is an actor, for exceptions refer to my TypedActors blog post. The best thing about actors is that they are fully encapsulated—in Akka behind ActorRef—as opposed to the weak encapsulation of OO languages. To get the most out of it, expose ActorRefs wherever possible, which gives client code the opportunity to use them in the most appropriate way (which may be using tell or ask depending on the context).

Structuring your Messages

When writing an actor, you should put everything about this actor in one place, including the interface contract description. It could look a bit like this:

object Parent {
  /**
   * Send this message to make your parent do your homework … yeah, right ;-)
   */
  case object DoHomework
}

/**
 * This actor will do your homework if asked to.
 * 
 * ==Actor Contract==
 * 
 * ===Inbound Messages===
 *  - '''DoHomework''' will ask to do the homework
 * 
 * ===Outbound Messages===
 *  - '''HomeworkResult''' is sent as reply to the '''DoHomework''' request
 * 
 * ===Failure Modes===
 *  - '''BusinessTripException''' if the parent was not home
 *  - '''GrumpyException''' if the parent thinks you should do your own homework
 */
class Parent extends Actor {
  …
}

Differences to TypedActor

Using normal untyped actors lets you make use of the full power of the actor model, including dynamically changing the behavior, and not being tempted to box yourself into the timeout-guarded cage of “synchronous” calls (in short, TypedActors are mostly useful when implementing a traditional synchronous interface using actors behind the scenes). I agree that IDE support for message types would be nice, but that is a tool problem (I have been talking with the ScalaIDE team about adding some magic, but that will have to wait until it can receive priority). Having all properties about the actor defined in one place is the important part.

Akka TypedActor vs. writing my own static interface to an Actor class

3 Answers

Actor Encapsulation

Structuring your Messages

Differences to TypedActor