Adding Scala Actors to your Spring application

So this morning I came up with a solution to something that has been bugging me about Scala actors recently. This fix solves two issues:

• Type-safe interfaces for actors
• wiring up actors (decoupling them)

The basic idea follows this pattern. Say, for instance, I have the rather unhelpful "EmailService" interface defined in my spring application:

public interface EmailService {
   public void sendEmail(String address, String subject, String message);
   public boolean isValid(String address);
}

Let's say (initially) I want to migrate all my service calls to scala actors. The goal here is to start pipelining my business logic and because I read a white paper about Erlang/OTP and wanted to "get some" into my J2EE application. Well, since I already have a java interface, and I already have a spring configuration file (or many), then I should be able to swap out implementations of the EmailService. This is the whole reason for dependency injection right?

Here's our first cut at a implementation using scala actors:

import scala.actors.Actor._

class ScalaActorEmailService extends EmailService {
     //Here we define the actor API (based on the interface)
     case class IsValid(address : String)
     case class SendEmail(address : String, subject : String, message : String)

     //Here we define the actor that actually performs service calls
     private val worker = actor {
       loop {
           react {
               case IsValid(address) => reply(false) //TODO Implement
               case SendEmail(address, subject, message) => Console.println("TODO -Implement send");
           }
       }
     }


     //Now we implement the API
     override def isValid(address : String) : Boolean = {
          val response = Some(worker !? IsValid(address))
          response.getOrElse(false) match {
              case b : Boolean => return b
              case _ => return false
          }
     }
     override def sendEmail(address : String, subject : String, message : String) : Boolean = {
        worker ! SendEmail(address, subject, message)
     }
}

Notice how all API calls are actually being sent as messages over actors. If we can ensure immutable arguments to our services... (which may be hard after the fact), you can see how we can add rich concurrent behavior in a piecemeal fashion. Another good part about this technique is that you can NOT pass messages to an actor in the case of "simple" operations.

Let's pretend we profiled and found that the isValid API call was slowing our application down significantly due to the return value. We want to inline in it to see what kind of performance gain we might make. Here's what our service would change into.

import scala.actors.Actor._

class ScalaActorEmailService extends EmailService {
     //Here we define the actor API (based on the interface)     
     case class SendEmail(address : String, subject : String, message : String)

     //Here we define the actor that actually performs service calls
     private val worker = actor {
       loop {
           react {
               case SendEmail(address, subject, message) => Console.println("TODO -Implement send");
           }
       }
     }


     //We inline this method for performance
     override def isValid(address : String) : Boolean = {
          //TODO - Implement
          return false
     }
     //This method calls out to the actor to make sure we don't block on send
     override def sendEmail(address : String, subject : String, message : String) : Boolean = {
        worker ! SendEmail(address, subject, message)
     }
}

Now we're starting to have some power in how we can architect our system. Not only that, we're dealing with type safe interfaces, so we don't have to search through documentation to figure out what messages can be sent to what actors. We can also remove/add actor calls as necessary for our app.

Another thing I'd like to say, and this is totally my preference. When in Java land and initially learning spring, a *lot* of examples show dependency injection using setters. I actually am starting to think this is a bad idea, as it makes mis-constructing an object (or mis-configuring it within the spring container) *much* easier. It seems to be a safer (and perhaps more functional?) way of doing things to inject everything in the constructor. In this manner we can inject type-safe interfaces for other actor-based-services into our actor-based service! Instantly we start talking pipelines and scalability based on hardware (i.e. # of CPUs).

The last thing to do, of course would be to attempt to unify choice of languages into scala by creating a trait instead of an interface that can be used.

trait EmailService {
   //Perfectly abstract method
   def sendEmail(address : String, subject : String, message : String) : Unit
   def isValid(String address) : Boolean = {
     //We could implement the "basic" version here and override it later if desired
     false
   }
}