At Gawker Tech, we're currently exploring transitioning some of the features that power Kinja from the monolithic Play applications to service-oriented architecture. Luckily, the most promising avenue for us to pursue is right underneath Play itself - Akka Remoting. Akka enables you to use actors as endpoints that can communicate with actors on others hosts - including local JVMs or other remote machines.
It's even better if you're already using them internally - enabling remoting is as simple as including akka-remote as a dependency and adding some configuration settings. Let's get started with a simple example - we'll consider it as a client-server relationship to keep things familiar.
First, make sure to have the appropriate dependencies in your build.sbt or Build.scala:
Then, add these settings to your application.conf (or appropriate equivalent) for your 'client' and 'server':
Now, let's implement the 'client' code:
Key thing to note here: The ClientActor uses its context ActorSystem and `actorSelection` to obtain the ActorRef of the remote ServerActor - you'll want to use this as actorFor is deprecated. However, actorSelection doesn't necessarily guarantee that you will be sending messages to a valid location - we'll cover a more failsafe approach in a future post.
And finally, the very simple 'server' code that just knows how to receive and reply to String messages:
Also note that in the 'server' code we can reply back to the sender of the last received message by sending a message to `sender` - even to remotes in this case (!!), which opens the door for easier 2-way communication.
That's all for now - check out the full source code for runnable sbt projects to see for yourself. In a future post, we'll go over how we can also expand this concept and take advantage of typesafe messages and message serialization.
[Akka, image via Wikimedia]