使用Akka从Play应用程序拨打网络服务电话 [英] Using Akka to make Web service calls from Play app

问题描述

我对使用Play框架以及Akka进行编程还是相当陌生的，尽管我已经阅读了一段时间.我现在正在默认/基本Play环境上启动概念验证应用程序.我的问题来自Play(http://www.playframework.org/documentation/2.0.1/ScalaWS)中的Web服务客户端api.

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).

该应用程序基本上需要以尽可能可扩展和高效的方式来调解对远程SOAP Web服务的调用.浏览器以JSON进行ajax调用，Play应用需要将其转换为SOAP/XML，反之亦然.

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.

如果我直接通过控制器使用play web service客户端，则这些调用可以是异步的，这比我们现在做的(阻塞)要好得多.但是，我不清楚在重负载下这到底会如何表现.并发/线程管理是否将大部分留给底层的Netty服务器?我有什么方法可以调音吗?

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?

一种替代方法是使用控制器中的Akka actor系统，在这里我可以控制路由策略，池大小，容错等.如果采用这种方法，使用Play的异步WS客户端还是有意义的?如果是这样，这种方法(组成期货吗?)会成为推荐的模式吗?

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?

另一个使Akka方法更具吸引力的因素是该应用程序最终还将承担其他职责，因此我们可以控制/调整允许该ActorSystem使用的资源，并降低整个应用程序被SOAP拖累的风险.服务.

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.

推荐答案

您要详细说明的两个选项都可以使用:

The two options you are detailing would work :

• 使用适用于WS的play API异步处理请求/响应
• 使用Akka做同样的事情，并在actor中同步管理您的WS调用

首先，没有对与错的解决方案.

First, there is no right or wrong solution.

戏剧！ WS API解决方案最容易实现和测试.社区中有很多人(我愿意).

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

另一方面，即使Akka解决方案的接缝设置起来较重(不是很多)，也为您带来了更大的灵活性.您可以简单地使用异步播放！块，并与用于异步计算的Promise一起使用.还有在游戏承诺和akka未来之间的隐式转换.最后，要监视演员，您可以查看类型安全控制台.

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.

如果最重要的是性能，那么过早的优化通常会导致更多(和不必要)的复杂性.就我而言，我将从API WS开始，如果将来需要的话，请移至Akka解决方案.

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.

这篇关于使用Akka从Play应用程序拨打网络服务电话的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！