Обратный AJAX (комета) и Spring MVC против Scala/LIFT?

Ответ 1

Поднимите Comet Architecture, которая была выбрана Novell для питания своего продукта Pulse после оценки ряда различных технологий.

Реализация Lift Comet использует одно HTTP-соединение для опроса для изменения произвольного количества компонентов на странице. Каждый компонент имеет номер версии. Длительный опрос включает номер версии и GUID компонента. На стороне сервера слушатель подключен ко всем GUID, указанным в запросах длительного опроса. Если какой-либо из компонентов имеет более высокий номер версии (или номер версии увеличивается в течение периода длительного опроса), дельта (набор JavaScript, описывающий изменение от каждой версии) отправляется клиенту. Дельты применяются, а номер версии на клиенте устанавливается на самый высокий номер версии для набора изменений.

Подъем включает в себя длительный опрос с управлением сеансом, так что если запрос попадает в один и тот же URL-адрес во время длительного опроса, который вызвал бы голод в связи с подключением, длительный опрос прекращается, чтобы избежать голода в сети (некоторые браузеры имеют не более двух HTTP-соединений в названный сервер, другие - не более 6). Lift также поддерживает DNS-серверы с DNS-серверами для длительных запросов опроса, так что каждая вкладка в браузере может выполнять длительный опрос против другого сервера подстановочных DNS-серверов. Это позволяет избежать проблем, связанных с голоданием.

Подъем динамически обнаруживает контейнер, в котором работает сервлет, и на Jetty 6 и 7 и (скоро) Glassfish, Lift будет использовать реализацию "продолжения" платформы, чтобы избежать использования нити во время длительного опроса.

Лифт JavaScript может сидеть на вершине jQuery и YUI (и мог также сидеть поверх Prototype/Scriptaculous.) Фактический код опроса включает в себя откат при сбоях соединения и другие "изящные" способы борьбы с неудачными отказами подключения.

Я посмотрел на Atmosphere, CometD, Akka (все технологии Comet, ориентированные на JVM). Ни один из них (в то время, когда я их оценивал) поддерживал несколько компонентов на страницу или предотвращение голода в связи.

Novell начал с нуля и выбрал Lift to power Pulse по очень веским причинам.

С точки зрения безопасности, Lift beats Spring + Spring Безопасность снижается. См. http://www.mail-archive.com/[email protected]/msg13020.html

В принципе, безопасность безопасности выпекается в вашем приложении. Приложения по умолчанию устойчивы к распространенным проблемам (межсайтовый скриптинг, повторные атаки, подделки с запросами на кросс-сайт). Приложения по умолчанию устойчивы к параметрированию. Карта sitemap определяет правила навигации по сайту и правила доступа. Это означает, что у вас никогда не было ссылки, на которую никто не может щелкнуть. Вам не нужно иметь внешний фильтр (например, Spring Security), который вам нужно настроить независимо от вашего приложения (whoops... переместил страницу, но забыл убедиться, что файл безопасности w760 > был обновлен.)

Ох... и если вы не хотите использовать язык шаблонов, вот полный компонент чата в разделе "Подвижная комета":

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>
  }
}

И чтобы вставить это на страницу: <lift:comet type="Chat"/>

Ответ 2

• С моей точки зрения, Spring MVC - очень плохой вариант для сборки AJAXed/COMETed RIA. Компонент ModelAndView, предназначенный для работы с формами HTML и отображения всей страницы сразу, библиотек тегов, процедур проверки правильности, лучше всего подходит для старомодной разработки на основе JSP и шаблонов. Для меня подключение AJAX/COMET в Spring MVC всегда будет своего рода взломом. Однако, если вы собираетесь создавать сервисы RESTful, используя @MVC (меняя JSON с вашим пользовательским интерфейсом javascript), это может сработать (хотя я бы предпочел Джерси /JAXB для этих вопросов).
• LIFT изначально был разработан для работы с COMET, поэтому это будет лучший выбор. Хотя я бы выбрал что-то гораздо более легкое и без шаблонов, чем LIFT (как для меня, он страдает от той же болезни Spring MVC).

• Обе системы безопасности охватывают только основные сценарии и требуют большой настройки, которые будут использоваться в реальных проектах.
  
  Это то, что я хотел бы использовать для создания COMETed RIA в Scala:

  • Jersey (облегченные сервисы RESTful для связи с JS UI через HTTP/JSON) + Atmosphere (масштабируемое решение для создания COMETed-приложений) + любая инфраструктура JS (jquery, YUI, ext js,...). Вы также должны взглянуть на Akka Framework, который интегрирован с Джерси и атмосферой, и позволяет создавать веб-приложения RIA в идиоматических Scala. Здесь pub-sub COMET пример в Akka.
  • Vaadin + ICEPush, Это будет очень удобная комбинация для вас, если вы не хотите, чтобы ваша рука была грязной с JS (хотя ICEpush еще не является решением для предприятий).

Ответ 3

Еще одна альтернатива, чистая Java (или любой другой JVM-язык, включая Scala), - это ItsNat Comet.