Ich bin ziemlich neu im Programmieren mit dem Play-Framework und Akka, obwohl ich schon eine Weile darüber gelesen habe. Ich starte jetzt eine Proof-of-Concept-Anwendung in der Standard- / Basis-Play-Umgebung. Meine Frage stammt vom Webdienst-Client-API in Play (http://www.playframework.org/documentation/2.0.1/ScalaWS).

Diese Anwendung muss Anrufe an einen Remote-SOAP-Webdienst so skalierbar und performant wie möglich vermitteln. Der Browser führt Ajax-Aufrufe in JSON aus. Die Play-App muss sie in SOAP / XML umwandeln und umgekehrt.

Wenn ich den Play-Webdienst-Client direkt über den Controller verwendet habe, können diese Aufrufe asynchron sein, was viel besser ist als das, was wir jetzt tun (Blockieren). Ich bin mir jedoch nicht sicher, wie sich das genau bei starker Belastung verhalten würde. Wird das Concurrency / Thread-Management weitgehend dem zugrunde liegenden Netty-Server überlassen? Kann ich es irgendwie einstellen?

Eine Alternative wäre die Verwendung eines Akka-Aktorsystems von den Controllern aus, mit dem ich die Routing-Richtlinie, die Poolgröße, die Fehlertoleranz usw. steuern kann. Wenn ich diesen Ansatz verfolge, ist es trotzdem sinnvoll, den asynchronen WS-Client von Play zu verwenden? Wenn ja, wäre dieser Ansatz (zum Komponieren von Futures?) Das empfohlene Muster?

Ein weiterer Faktor, der den Akka-Ansatz attraktiver zu machen scheint, ist, dass diese Anwendung letztendlich mehrere andere Verantwortlichkeiten haben würde, sodass wir die für dieses ActorSystem zulässigen Ressourcen steuern / optimieren und das Risiko verringern könnten, dass die gesamte App vom SOAP-Dienst heruntergezogen wird.