Идеи для веб-приложения с внешним вводом и уведомлением в реальном времени - PullRequest
3 голосов
/ 16 июля 2009

Я собираюсь создать веб-приложение, которое будет принимать различные события из внешних источников и быстро представлять их пользователю для дальнейших действий. Я хочу использовать Ruby on Rails для веб-приложения. Этот проект является внутренним проектом развития. Я бы предпочел простые и простые в использовании решения для быстрой разработки по сравнению с высоконадежными и сложными системами.

Что он должен делать

Пользователь открыл веб-приложение в своем браузере. Теперь приходит телефонный звонок. Телефонный звонок регистрируется демоном мониторинга УАТС. В этом случае через интерфейс Asterisk Manager. Демон каким-либо образом отправляет доступную информацию (удаленный добавочный номер, локальный добавочный номер, направление вызова, состояние канала, время начала, время окончания) в веб-приложение. Далее пользователь получает уведомление о событии телефонного звонка. Пользователь теперь может работать с этим. Например, введя сводку или сопоставив вызов с профилем клиента.

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

Монитор УАТС - это всего лишь один источник данных. Там будет больше мониторов, таких как электронная почта или запрос через веб-форму. Демоны мониторинга не обязательно будут работать на том же хосте, что и база данных или веб-сервер. Я не представляю, что приложение будет обслуживать тысячи зарегистрированных пользователей или параллельные запросы в ближайшее время. Но при проектировании 200 пользователей с примерно одинаковым количеством событий в минуту проблема масштабируемости не должна быть.

Как мне поступить?

Мне интересно знать, как бы вы разработали такое приложение. Какие технологии вы бы предложили? Как демоны передают свою информацию? Когда и кем хранятся данные о событии в основной базе данных? Как пользователь получает уведомление? Должен ли браузер получать полный набор данных от имени демона или просто краткую заметку о том, что доступны новые данные? Какую библиотеку JS использовать и как создать необходимый код на стороне сервера?

В своих исследованиях я обнаружил множество возможностей: брокеры сообщений, службы очередей, некоторые решения фоновых задач для рельсов, службы HTTP Push, XMPP и так далее. Некоторые продукты, которые я собираюсь изучить: ActiveMQ, Starling and Workling, Джаггернаут и Бош.

Может быть, я стремлюсь слишком высоко? Если есть более простой или более простой способ, например, использование интерфейса Rails для XML или JSON, я хотел бы прочитать это еще больше.

Надеюсь, текст не слишком длинный:)

Спасибо.

Ответы [ 3 ]

1 голос
/ 23 июля 2009

Если вы хотите пропустить Java и Flash, возможно, имеет смысл использовать технологию семейства Comet для передачи с сервера в браузер?

http://en.wikipedia.org/wiki/Comet_%28programming%29

Для простоты, для уведомлений от демонов в веб-браузер, я бы оставил Rails посередине, создал бы интерфейс RESTful для этого приложения Rails и сделал так, чтобы все демоны сообщали ему. Затем в ваших демонах вы можете сделать что-то простое, например, использовать curl или libcurl для публикации уведомлений. Тогда приложение Rails будет отвечать за сбор входящих уведомлений из различных источников и отправлять их в браузер либо через JavaScript, используя решение Comet, либо через какой-то более толстый клиент, реализованный с использованием Flash или Java.

1 голос
/ 16 июля 2009

Вы могли бы подойти к этому несколькими способами, но мой единственный комментарий был бы: толкай, не тяни. Для низкой задержки это не только быстрее, но и более эффективно, поскольку вашему серверу теперь не нужно обрабатывать n * клиентов один раз в секунду, опрашивая db / очередь. ActiveMQ в порядке, но Starling, вероятно, будет вам лучше, если вы не ищете безумный уровень настойчивости.

Вы почти наверняка в конечном итоге будете использовать Flash на стороне клиента (Джаггернаут использует его в прошлый раз, когда я проверял) или Java. Это может быть проблемой для ваших клиентов (если у них не установлена ​​Flash / Java), но для большинства людей это не проблема; тем не менее, разумно было бы использовать запасной механизм для системы извещения.

0 голосов
/ 13 января 2010

Возможно, http://goldfishserver.com может вам пригодиться. Он предоставляет простой API, позволяющий отправлять push-уведомления на ваши веб-страницы. Короче говоря, когда ваши данные обновляются, отправьте их (некоторые полезные данные) на серверы Goldfish, и ваши клиентские браузеры получат уведомление с теми же данными.

Отказ от ответственности: я разработчик, работающий над золотой рыбкой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...