Нужно мнение о дизайне/архитектуре веб-приложения

Question

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

Я планирую изучить рамку scala/lift для этого. Я прочитал несколько статей в Интернете для scala/lift и хочу изучить, подходит ли это для решения этой проблемы, а также если scala/lift - хорошая платформа для выбора. Я работал в Java и C# ранее. Любые мнения, комментарии, предложения приветствуются.

Спасибо, Гэри

Answer 1

гляньте технологию очереди сообщений, как JMS Java. Очереди сообщений позволяют выполнять асинхронно и надежно обрабатывать многолетние фоновые задачи. Это сайты технологий, такие как Flickr и YouTube, используют асинхронную перекодировку мультимедиа. Вы можете использовать Java EE-сервер или JMS-технологию, такую ​​как Apache's ActiveMQ, а затем сложить свой код Scala/Lift поверх него.

Richard Monson-Haefel's book on JMS хорошо его охватывает.

Для получения более общей помощи при масштабировании и построении веб-сайта взгляните на отличный блог Тодда Хоффа, highscalability.com/. Есть несколько хороших указателей на использование очередей сообщений, чтобы таким образом выгрузить длительные задачи.

BTW, Twitter использует Scala для чего-то похожего на то, что вы рассматриваете. Вот interview с некоторыми из их разработчиков; они описывают один способ, которым они используют Scala:

Роби Указатель: Много нашей архитектуры основываются на позволяя Rails делать то, что он делает лучше всего, что является AJAX, веб-интерфейсы, сайт-то, что видит пользователь , Все, что мы можем выгрузить из цикла запроса/ответа, мы делаем. Поэтому мы ставим эти задачи в систему обмена сообщениями и обрабатываем их задним демонам.

Answer 2

Если нелокальные ресурсы исходят из какой-либо другой службы или системы, для вас может работать Event Driven Architecture. Вместо того, чтобы вытаскивать из нелокальных ресурсов, вы можете настроить это веб-приложение как подписчика на события, опубликованные этими службами. Получив сообщение о части своей функциональности, он будет кэшировать локально интересующие данные. Это должно позволить вам избежать проблемы асинхронного обновления частей страницы (все данные будут доступны локально).

Udi Dahan блоги об этом подходе много, а также является автором шины сообщений .NET (NServiceBus), которая может использоваться в таких сценариях. См. Например, http://msdn.microsoft.com/en-us/architecture/aa699424.aspx

Answer 3

Актеры были бы способ пойти. По сути, вы создаете легкую версию JMS. И Лифтинг очень хорошо кометный материал. В дополнение к актерам Scala и актерам подъемника у вас также есть akka actors. Когда Scala Swarm станет готовым к производству, вы тоже будете готовы к этому.

Answer 4

Если отложенная информация отличается от информации, которая должна отображаться немедленно, с помощью Lift вы можете использовать фрагмент LazyLoad, который имеет более длительное вычисление (вызов веб-службы) как часть его логики. Подъемник позаботится о том, чтобы вставить его в страницу, когда он готов.