Удаленный вызов объекта PlayFramework

Я ищу способ отправки сериализованных объектов (или просто строк) в модель PlayFramework или объект контроллера через удаленную JVM.

Я пытаюсь создать веб-приложение на основе выталкиваемых событий, поэтому на данный момент можно получать новые события с помощью длинного вызова ajax с опросом, когда некоторые события добавляются в модель.

Теперь я хотел бы добавить события в свою модель с удаленной JVM, через RMI, сокет или что-то еще, что может работать. Я искал в документации PlayFramework, но не нашел никакого API или фрагмента кода о том, как это сделать.


java sockets playframework rmi
person Alexandre Bourdin    schedule 04.07.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы можете использовать WebSockets, я написал об этом в блоге здесь: http://geeks.aretotally.in/log4play-log4j-ui-mashed-up-with-play-framework-knockout-js-and-websockets

В моем примере только передача данных с сервера на клиент, но вы можете использовать WebSockets для двусторонней связи через JSON: http://www.playframework.org/documentation/1.2.1/asynchronous#UsingWebSockets

Вы также можете использовать Akka Remote Actors (http://akka.io/docs/akka/1.1.3/scala/remote-actors.html).

person Felipe Oliveira    schedule 04.07.2011

arrow_upward
1
arrow_downward

Разве передача данных на сервер не является легкой частью?

Естественным способом было бы вызвать некоторое действие контроллера (читай: HTTP POST), принимающее объект JsonData (если данные структурированы) или простые параметры, если данные неструктурированы.

Навскидку, в игровой речи это выглядело бы так:

WSRequest request = new WSUrlFetch().newRequest("http://<url of your 'vm'>");
// request.setParameter("param", value);
// ...
request.post();

Вам не нужны WebSockets для этого.

person André Pareis    schedule 04.07.2011
comment
Да, это простая часть, и вам вообще не нужны WebSockets, просто дайте ему знать о некоторых вариантах, на которые он, возможно, еще не наткнулся; WebSockets, если поддержка браузера не является проблемой, также позволит избежать длительного опроса, его бесполезных вызовов и повторного использования соединения для выполнения push-уведомлений. - person Felipe Oliveira; 05.07.2011
comment
Да, вы правы, WebSockets имеет смысл для потребителя HTTP. Он определенно мог бы переключиться с длинного опроса на WS, если бы все компоненты инфраструктуры работали совместно. Но внешний производитель событий (его удаленная виртуальная машина), независимо от того, воспроизводится он или нет, может просто сделать традиционный запрос на создание событий для канала WS. - person André Pareis; 06.07.2011
comment
Я не хочу (и мне сказали не делать этого) использовать некоторые незрелые технологии, такие как WebSockets, поскольку они еще не поддерживаются почти всеми веб-браузерами, а стандарт все еще должен быть установлен W3C. Но вопрос связи между фронтендом и бэкендом с использованием длинных опросов — решаемая проблема, сейчас я сосредоточился на общении WS и бэкенде. Чтобы возобновить мою архитектуру, у меня есть веб-сервер, который отправляет события на мой интерфейс посредством длительного опроса. Отправленные события поступают из независимого веб-сервиса и должны быть помещены в своего рода буфер в моем бэкэнде, прежде чем они будут отправлены во внешний интерфейс. - person Alexandre Bourdin; 06.07.2011