10

I am fairly new to programming with the Play framework as well as Akka, although I've been reading about them for a while. I am now starting a proof-of-concept application on the default/basic Play environment. My question stems from the web service client api in Play (http://www.playframework.org/documentation/2.0.1/ScalaWS).

This application basically needs to mediate calls to a remote SOAP web service in as scalable and performant a way as possible. Browser makes ajax calls in JSON, Play app needs to transform them to SOAP/XML and vice versa on the response.

If I used the play web service client directly through the controller, these calls can be asynchronous, which is way better than what we do now (blocking). However, I'm not clear on how this exactly this would behave under heavy load. Will the concurrency/thread-management be largely left to the underlying Netty server? Do I have any way to tune it?

An alternative would be to use an Akka actor system from the controllers, where I can control the routing policy, pool size, fault-tolerance etc. If I take this approach, would it still make sense to use Play's async WS client? If so, would this approach ( of composing Futures?) be the recommended pattern?

Another factor that seems to make the Akka approach more attractive is that this application would eventually have several other responsibilities, so we could control/tune the resources allowed to this ActorSystem and reduce risk of the entire app getting dragged down by the SOAP service.

anchormath
  • 145
  • 1
  • 8

1 Answers1

5

The two options you are detailing would work :

  • Use the play API for WS to handle requests/responses asynchronously
  • Use Akka to do the same thing and manage your WS call synchronously in your actor

First, there is no right or wrong solution.

The Play! WS API solution seams the easiest to implement and test. Many people in the community rely on it (I do).

On the other hand, even if the Akka solution seams heavier (not that much) to set up, it brings you more flexibility in the future. You can simply use Async play! blocks and work with promises for async computation. There is also implicit conversions between play promises and akka future. Finally, to monitor your actors you can have a look at Typesafe console.

If the big thing is performances, premature optimisation often leads to more (and unnecessary) complexity. As far as I am concern, I would begin with the API WS and if required in the future move to the Akka solution.

kheraud
  • 5,048
  • 7
  • 46
  • 75
  • 2
    Actually the second option I was wondering about was a sort of double-async. Could the Actors still use the WS API (or the underlying ning async httpclient)? – anchormath Jun 27 '12 at 12:58
  • You get back a promise with WS requests. The actors can still use it. – kheraud Jun 27 '12 at 13:41