Поменять AJAX (Comet) и Spring MVC против Scala/LIFT?

IBM демонстрирует, как легко использовать Reverse AJAX с DWR 2. С другой стороны, Scala/LIFT поставляется со встроенной возможностью Reverse AJAX.

  1. Вопрос: Есть ли опыт, если это нормально работает с Spring MVC?

  2. Вопрос: Если вы начнете с нуля, каковы плюсы и минусы для предпочтения Scala / LIFT перед DWR/Spring MVC

  3. Вопрос: В Scala / LIFT управление безопасностью такое же сложное, как в Spring Security?

Источник

3 ответа

Решение

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

Реализация кометы 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). Фактический код опроса включает в себя откат при сбоях соединения и другие "изящные" способы борьбы с временными сбоями соединения.

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

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

С точки зрения безопасности, Lift превосходит Spring + Spring Security. См. http://www.mail-archive.com/liftweb@googlegroups.com/msg13020.html

По сути, безопасность 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>
  }
}

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

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

  3. Обе системы безопасности охватывают только основные сценарии и требуют большой настройки для использования в реальных проектах.

    Вот что я бы использовал для построения COMETed RIA в Scala:

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

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

Источник
Другие вопросы по тегам