Обратный Ajax (комета) и Spring MVC по сравнению с Scala/LIFT?
Существует демонстрация IBM, которая показывает, как легкий Обратный Ajax может использоваться с DWR 2. С другой стороны, Scala/LIFT идет со встроенной Обратной возможностью Ajax.
Вопрос: опыт, если это хорошо работает с Spring MVC?
Вопрос: Если Вы запустили бы с нуля, каковы за и против для предпочтения Scala/LIFT по DWR/Spring MVC
Вопрос: В Scala/LIFT безопасность обрабатывает столь же сложный как в безопасности Spring?
2 ответа
Архитектура Comet компании Lift, которая была выбрана компанией Novell для своего продукта Pulse после оценки ряда различных технологий.
Реализация Comet от Lift использует одно HTTP-соединение для опроса изменений произвольного количества компонентов на странице. Каждый компонент имеет номер версии. Длинный опрос включает номер версии и GUID компонента. На стороне сервера ко всем GUID, перечисленным в запросах длинного опроса, подключается слушатель. Если какой-либо из компонентов имеет более высокий номер версии (или номер версии увеличивается в течение периода длинного опроса), дельты (набор JavaScript, описывающий изменения от каждой версии) отправляются клиенту. Дельты применяются, и номер версии на клиенте устанавливается на самый высокий номер версии для набора изменений.
Lift интегрирует длинный опрос с управлением сессиями, так что если во время длинного опроса на один и тот же URL приходит запрос, который может привести к разрыву соединения, длинный опрос прекращается, чтобы избежать разрыва соединения (некоторые браузеры имеют максимум 2 HTTP-соединения на один именованный сервер, другие - максимум 6). Lift также поддерживает DNS-серверы с "дикими" адресами для длинных запросов, так что каждая вкладка браузера может выполнять длинный опрос на разных DNS-серверах с "дикими" адресами. Это позволяет избежать проблемы "голодания" соединения.
Lift динамически определяет контейнер, в котором запущен сервлет, и на Jetty 6 и 7 и (скоро) Glassfish, Lift будет использовать реализацию "продолжения" платформы, чтобы избежать использования потока во время длинного опроса.
JavaScript в Lift может располагаться поверх jQuery и YUI (и может располагаться поверх Prototype/Scriptaculous также.) Фактический код опроса включает в себя откат при сбоях соединения и другие "изящные" способы работы с преходящими сбоями соединения.
Я рассматривал Atmosphere, CometD, Akka (все JVM-ориентированные технологии Comet). Ни одна из них не имела (в то время, когда я их оценивал) поддержки нескольких компонентов на страницу или предотвращения обрыва соединения.
Novell начала с нуля и выбрала Lift для работы с Pulse по некоторым очень веским причинам.
С точки зрения безопасности Lift выигрывает у Spring + Spring Security. См. http://www.mail-archive.com/liftweb@googlegroups.com/msg13020.html
По сути, безопасность Lift встроена в ваше приложение. Приложения Lift по умолчанию устойчивы к распространенным проблемам (межсайтовый скриптинг, атаки повторного воспроизведения, подделка межсайтовых запросов). Приложения Lift по умолчанию устойчивы к подделке параметров. Карта сайта Lift определяет навигацию по сайту и правила управления доступом. Это означает, что у вас никогда не будет ссылки, на которую кто-то не сможет нажать. Вам не нужен внешний фильтр (например, Spring Security), который нужно настраивать независимо от вашего приложения (упс... переместил страницу, но забыл убедиться, что XML-файл Spring Security был обновлен)
О... и если вы не хотите использовать язык шаблонов, вот полный компонент чата Lift Comet:
class Chat extends CometActor with CometListener {
private var msgs: List[String] = Nil
def registerWith = ChatServer
override def lowPriority = {
case m: List[String] => msgs = m; reRender(false)
}
def render = {
<div>
<ul>
{
msgs.reverse.map(m => <li>{m}</li>)
}
</ul>
<lift:form>
{
SHtml.text("", s => ChatServer ! s)
}
<input type="submit" value="Chat"/>
</lift:form>
</div>
}
}
И чтобы вставить это на страницу:
- С моей точки зрения, Spring MVC - очень плохой выбор для создания AJAXed/COMETed RIA. Компонент ModelAndView, предназначенный для работы с HTML формами и рендеринга всей страницы сразу, библиотеки тегов, процедуры валидации - все это лучше подходит для старомодной разработки, основанной на JSP и шаблонах. Для меня подключение AJAX/COMET к Spring MVC всегда будет своего рода хаком. Однако, если вы собираетесь строить RESTful сервисы с использованием @MVC (обмен JSON с вашим javascript UI), это может сработать (хотя я бы предпочел Jersey/JAXB для этих вопросов).
- LIFT изначально был разработан для работы с COMET, поэтому он будет лучшим выбором. Хотя я бы выбрал что-то более легковесное и безшаблонное, чем LIFT (как по мне, он страдает от той же болезни, что и Spring MVC).
Обе системы безопасности охватывают только базовые сценарии и требуют большой настройки для использования в реальных проектах.
Вот что я бы использовал для создания COMETed RIA на Scala:- Jersey (легкие RESTful сервисы для взаимодействия с JS UI по HTTP/JSON) + Atmosphere (масштабируемое решение для создания COMETed приложений) + любой JS фреймворк (jquery, YUI, ext js, ...). Вам также стоит взглянуть на Akka Framework, который интегрирован с Jersey и Atmosphere и позволяет создавать RIA веб-приложения на идиоматическом Scala. Вот пример pub-sub COMET на Akka.
- Vaadin + ICEPush. Это будет гораздо более удобная комбинация для вас, если вы не хотите пачкать руки в JS (хотя ICEpush пока не является решением для предприятий).