Использование Akka для звонков через веб-сервис из приложения Play

Я довольно новичок в программировании на платформе Play, а также на Akka, хотя я читал о них некоторое время. Сейчас я запускаю приложение для проверки концепции в стандартной / базовой среде Play. Мой вопрос проистекает из API клиента веб-сервиса в Play (http://www.playframework.org/documentation/2.0.1/ScalaWS).

Это приложение в основном нуждается в передаче вызовов удаленной веб-службе SOAP как можно более масштабируемым и производительным способом. Браузер выполняет вызовы AJAX в JSON, приложение Play должно преобразовывать их в SOAP / XML и наоборот в ответ.

Если бы я использовал клиент веб-службы воспроизведения напрямую через контроллер, эти вызовы могут быть асинхронными, что намного лучше, чем то, что мы делаем сейчас (блокирование). Однако я не совсем понимаю, как именно это будет вести себя при большой нагрузке. Будет ли параллелизм / управление потоками в основном предоставлен серверу Netty? У меня есть какой-нибудь способ настроить это?

Альтернативой может быть использование системы акторов Akka с контроллеров, где я могу управлять политикой маршрутизации, размером пула, отказоустойчивостью и т. Д. Если бы я использовал этот подход, все же имеет ли смысл использовать асинхронный WS-клиент Play? Если да, то будет ли этот подход (составление фьючерсов?) Рекомендуемым шаблоном?

Другой фактор, который, по-видимому, делает подход Akka более привлекательным, заключается в том, что это приложение в конечном итоге будет выполнять несколько других функций, поэтому мы можем контролировать / настраивать ресурсы, разрешенные для этой системы ActorSystem, и снижать риск того, что все приложение будет перетаскиваться службой SOAP.

Ответы на вопрос(1)

Решение Вопроса

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

Во-первых, нет правильного или неправильного решения.

Игра! Решение WS API выглядит самым простым в реализации и тестировании. Многие люди в сообществе полагаются на это (я делаю).

С другой стороны, даже если решение Akka требует больших усилий (не так много) для настройки, оно обеспечит вам большую гибкость в будущем. Вы можете просто использоватьАсинхронная игра! блоки и работать с обещаниями асинхронных вычислений. Существует такженеявные преобразования между игровыми обещаниями и будущим акка, Наконец, для наблюдения за вашими актерами вы можете взглянуть наТипичная безопасная консоль.

Если важна производительность, преждевременная оптимизация часто приводит к большей (и ненужной) сложности. Что касается меня, то я бы начал с API WS и, если потребуется, в будущем перейду к решению Akka.

 anchormath27 июн. 2012 г., 14:58
На самом деле, второй вариант, который меня интересовал, был своего рода двойной асинхронностью. Могут ли актеры по-прежнему использовать WS API (или базовый ning async httpclient)?
 27 июн. 2012 г., 15:41
Вы получаете обещание с запросами WS. Актеры все еще могут использовать это.

Ваш ответ на вопрос