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

spring-mvc spring-security

Question

Hay una demostración de IBM que muestra lo fácil que puede usarse Reverse AJAX con DWR 2. Por otro lado, Scala / LIFT viene con la capacidad Reverse AJAX incorporada.

1. Pregunta: ¿Alguna experiencia si esto funciona bien con Spring MVC?

2. Pregunta: Si comenzara de cero, ¿cuáles son las ventajas y desventajas de preferir Scala / LIFT sobre DWR / Spring MVC?

3. Pregunta: En Scala / LIFT, ¿el manejo de seguridad es tan sofisticado como en Spring Security?

Answer 1

1. Desde mi punto de vista, Spring MVC es una muy mala elección para construir AJAXed / COMETed RIA. El componente ModelAndView tenía como objetivo trabajar con formularios HTML y representar toda la página a la vez, las bibliotecas de etiquetas y las rutinas de validación se adaptan mejor al desarrollo tradicional, basado en plantillas y JSP. Para mí, conectar AJAX / COMET en Spring MVC siempre será una especie de pirateo. Sin embargo, si va a crear servicios RESTful usando @MVC (intercambiando JSON con su javascript UI), puede funcionar (aunque prefiero Jersey / JAXB para esos asuntos).
2. LIFT fue diseñado originalmente para funcionar con COMET, por lo que será una mejor opción. Aunque elegiría algo mucho más ligero y sin plantilla, que LIFT (como para mí, sufre la misma enfermedad que Spring MVC).

3. Ambos sistemas de seguridad cubren solo escenarios básicos, y requieren mucha personalización para ser usados ​​en proyectos del mundo real.
   
   Eso es lo que usaría para construir COMETed RIA en Scala:

   • Jersey (servicios RESTful ligeros para comunicarse con JS UI a través de HTTP / JSON) + Atmosphere (solución escalable para crear aplicaciones COMETed) + cualquier marco JS (jquery, YUI, ext js, ...). También deberías echar un vistazo a Akka Framework , que está integrado tanto en Jersey como en Atmosphere, y te permite crear aplicaciones web RIA en Scala idiomático. Aquí hay un ejemplo de pub-sub COMET en Akka.
   • Vaadin + ICEPush . Será una combinación mucho más cómoda para usted, si no quiere ensuciarse la mano con JS (aunque ICEpush no es una solución lista para la empresa todavía).

Answer 2

La arquitectura de cometas de Lift, que fue seleccionada por Novell para impulsar su producto Pulse después de evaluar varias tecnologías diferentes.

La implementación de Lift Comet utiliza una sola conexión HTTP para sondear los cambios en un número arbitrario de componentes en la página. Cada componente tiene un número de versión. La encuesta larga incluye el número de versión y el componente GUID. En el lado del servidor, se adjunta un oyente a todos los GUID listados en las solicitudes de encuestas largas. Si alguno de los componentes tiene un número de versión más alto (o el número de versión aumenta durante el período de la encuesta larga), los deltas (un conjunto de JavaScript que describe el cambio de cada versión) se envían al cliente. Los deltas se aplican y el número de versión en el cliente se establece en el número de versión más alto para el conjunto de cambios.

Lift integra el sondeo largo con la administración de la sesión, de modo que si una solicitud entra en la misma URL durante un sondeo largo que causaría la inanición de la conexión, se termina el sondeo largo para evitarlo (algunos navegadores tienen un máximo de 2 conexiones HTTP por servidor nombrado). otros tienen un máximo de 6). Lift también admite servidores DNS con comodines para solicitudes de sondeo largas, de modo que cada pestaña en el navegador puede realizar sondeos largos en un servidor DNS con comodines DNS diferente. Esto evita los problemas de hambre de conexión.

Lift detecta dinámicamente el contenedor en el que se está ejecutando Servlet y en Jetty 6 y 7 y (pronto) Glassfish, Lift utilizará la implementación de "continuación" de la plataforma para evitar el uso de un hilo durante la encuesta larga.

El JavaScript de Lift puede ubicarse encima de jQuery y YUI (y también puede estarlo encima de Prototype / Scriptaculous). El código de sondeo real incluye el retroceso en fallas de conexión y otras formas "elegantes" de lidiar con fallas de conexión transitorias.

He analizado Atmosphere, CometD, Akka (todas las tecnologías Comet orientadas a JVM). Ninguno tenía (en el momento en que los evalué) soporte para múltiples componentes por página o para evitar el hambre de conexión.

Novell comenzó desde cero y eligió Lift para dar energía a Pulse por muy buenas razones.

En términos de seguridad, Lift supera a Spring + Spring Security incuestionablemente. Consulte http://www.mail-archive.com/[email protected]/msg13020.html

Básicamente, la seguridad de Lift está incorporada en su aplicación. Las aplicaciones de Lift son resistentes a los problemas comunes (secuencias de comandos entre sitios, ataques de reproducción, falsificaciones de solicitudes entre sitios) de forma predeterminada. Las aplicaciones de elevación son resistentes a la manipulación de parámetros por defecto. El mapa del sitio de Lift define la navegación del sitio y las reglas de control de acceso. Esto significa que nunca tienes un enlace en el que alguien no pueda hacer clic. No necesita tener un filtro externo (por ejemplo, Spring Security) que debe configurar independientemente de su aplicación (whoops ... movió una página, pero se olvidó de asegurarse de que el archivo XML de Spring Security se haya actualizado).

Ah ... y si no quieres usar un lenguaje de creación de plantillas, aquí tienes un completo componente de chat de 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>
}
}

Y para insertar esto en una página: <lift:comet type="Chat"/>

Answer 3

Otra alternativa, Java puro (o con cualquier otro lenguaje JVM incluido Scala) es ItsNat Comet .