反向AJAX(Comet)和Spring MVC与Scala/LIFT? [英] Reverse AJAX (Comet) and Spring MVC vs. Scala/LIFT?

问题描述

IBM的 demo 显示逆向AJAX与DWR 2一起使用的难易程度.另一方面，Scala/LIFT具有内置的逆向AJAX功能.

1. 问题:是否可以在Spring MVC上正常工作?

2. 问题:如果您从头开始，那么优先于Scala/LIFT而不是DWR/Spring MVC的利弊是什么

3. 问题:在Scala/LIFT中，安全处理是否像Spring Security一样复杂?

解决方案

在评估了许多不同的技术之后，Novell选择了Lift的Comet体系结构为他们的Pulse产品提供动力.

Lift的Comet实现使用单个HTTP连接来轮询页面上任意数量组件的更改.每个组件都有一个版本号.长轮询包含版本号和组件GUID.在服务器端，侦听器连接到长轮询请求中列出的所有GUID.如果任何组件的版本号更高(或在长时间轮询期间版本号增加)，则将增量(一组JavaScript来描述每个版本的更改)发送给客户端.将应用增量，并将客户端上的版本号设置为更改集的最高版本号.

Lift将长轮询与会话管理集成在一起，因此，如果长轮询期间某个请求进入同一URL，这会导致连接饥饿，则长轮询将终止，以避免连接饥饿(某些浏览器每个HTTP最多有2个HTTP连接命名服务器，其他服务器最多为6个). Lift还支持针对长期轮询请求的DNS通配符服务器，以便浏览器中的每个选项卡都可以针对不同的DNS通配符服务器进行长期轮询.这样可以避免连接不足的问题.

Lift动态检测Servlet正在Jetty 6& amp;上运行的容器. 7和(很快)Glassfish，Lift将使用平台的"continuations"实现，以避免在长时间轮询期间使用线程.

Lift的JavaScript可以位于jQuery和YUI之上(也可以位于Prototype/Scriptaculous之上.)实际的轮询代码包括对连接失败的退避以及其他处理过渡连接失败的优美"方式

我研究了Atkka，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)，而不必从应用程序中独立配置(whoops ...移动了页面，但是忘记了确保Spring Security XML文件已更新.)

哦...，如果您不想使用模板语言，那么这里有一个完整的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"/>

There is a demo by IBM that shows how easy Reverse AJAX can be used with DWR 2. On the other hand, Scala/LIFT comes with built-in Reverse AJAX capability.

1. Question: Any experience if this works fine with Spring MVC?

2. Question: If you'd start from scratch, what are the pros and cons for preferring Scala/LIFT over DWR/Spring MVC

3. Question: In Scala/LIFT, is the security handling as sophisticated as in Spring Security?

解决方案

Lift's Comet Architecture which was selected by Novell to power their Pulse product after they evaluated a number of different technologies.

Lift's Comet implementation uses a single HTTP connection to poll for changes to an arbitrary number of components on the page. Each component has a version number. The long poll includes the version number and the component GUID. On the server side, a listener is attached to all of the GUIDs listed in the long poll requests. If any of the components has a higher version number (or the version number increases during the period of the long poll), the deltas (a set of JavaScript describing the change from each version) is sent to the client. The deltas are applied and the version number on the client is set to the highest version number for the change set.

Lift integrates long polling with session management so that if a request comes into the same URL during a long poll that would cause connection starvation, the long poll is terminated to avoid connection starvation (some browsers have a maximum of 2 HTTP connections per named server, others have a max of 6). Lift also supports DNS wild-carded servers for long poll requests such that each tab in the browser can do long polling against a different DNS wildcarded server. This avoids the connection starvation issues.

Lift dynamically detects the container the Servlet is running in and on Jetty 6 & 7 and (soon) Glassfish, Lift will use the platform's "continuations" implementation to avoid using a thread during the long poll.

Lift's JavaScript can sit on top of jQuery and YUI (and could sit on top of Prototype/Scriptaculous as well.) The actual polling code includes back-off on connection failures and other "graceful" ways of dealing with transient connection failures.

I've looked at Atmosphere, CometD, Akka (all JVM-oriented Comet technologies). None had (at the time I evaluated them) support for multiple components per page or connection starvation avoidance.

Novell started from scratch and chose Lift to power Pulse for some very good reasons.

In terms of security, Lift beats Spring + Spring Security hands down. See http://www.mail-archive.com/[e-mail]/msg13020.html

Basically, Lift's security is baked into your application. Lift apps are resistant to common problems (cross site scripting, replay attacks, cross site request forgeries) by default. Lift apps are resistant to parameter tampering by default. Lift's sitemap defines site navigation and access control rules. This means you never have a link that someone can't click on. You don't need to have an external filter (e.g., Spring Security) that you have to configure independently from you app (whoops... moved a page, but forgot to make sure the Spring Security XML file was updated.)

Oh... and if you don't want to use a templating language, here's a complete Lift Comet chat component:

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

And to insert this into a page: <lift:comet type="Chat"/>

这篇关于反向AJAX(Comet)和Spring MVC与Scala/LIFT?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！