Reverse AJAX (Comet) and Spring MVC vs. Scala/LIFT?

Question

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?

Answer 1

1. From my point of view, Spring MVC is a very bad choice to build AJAXed/COMETed RIA. ModelAndView component aimed to work with HTML forms and render the entire page at once, tag libraries, validation routines are all better suited for old-fashioned development, based on JSPs and templates. For me, plugging AJAX/COMET into Spring MVC will always be a kind of a hack. However, if you're going to build RESTful services using @MVC (interchanging JSON with your javascript UI), it may work (though I would prefer Jersey/JAXB for those matters).
2. LIFT was originally designed to work with COMET, so it will be a better choice. Though I would choose something much more lightweight and template-less, than LIFT (as for me, it suffers from the same disease Spring MVC does).

3. The both security systems cover just basic scenarios, and require a lot of customization to be used in real-world projects.
   
   That's what I would use for building COMETed RIA in Scala:

   • Jersey (lightweight RESTful services to communicate with JS UI over HTTP/JSON) + Atmosphere (scalable solution for building COMETed applications) + any JS framework (jquery, YUI, ext js, ...). You should also have a look at Akka Framework, which is integrated with the both Jersey and Atmosphere, and allows you building RIA web-apps in idiomatic Scala. Here's a pub-sub COMET example in Akka.
   • Vaadin + ICEPush. It will be much comfortable combination for you, if you don't want to get your hand dirty with JS (though ICEpush is not an enterprise-ready solution yet).

Answer 2

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/[email protected]/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"/>