Apache Cocoon 2 es un framework opensource de publicación basado en XML/XLS y enfocado a la separación entre contenido, presentación y lógica de la aplicación, basándose en los principios de separación de responsabilidades.

La especialidad de Cocoon es la presentación, pudiendo generar vistas con muy diferentes formatos a partir de una sola representación interna.

Está diseñado en distintos bloques y cada uno de ellos tiene una responsabilidad determinada. las aplicaciones desarrolladas con Cocoon son consideradas como bloques del propio framework.

La arquitectura general del framework encontramos las siguientes capas:

• Core Cocoon: Es el corazón de Cocoon. Encontramos un entorno para el control de sesiones, ficheros para configuración de Cocoon, para hacer manejo de contextos, aplicar mecanismos de caché, Pipeline, generación, compilación, carga y ejecución de programas.

• Cocoon Components: En esta capa encontramos los generadores de XML, transformadores de XML, matchers de ficheros y serializadores para formatear los ficheros.

• Built-in Logicsheets: Son hojas lógicas que necesita Cocoon para ficheros como sitemap, xsp, esql, request, response.

• Site specific configuration, components, logicsheets and content: Es el nivel más externo en el cual un desarrollador puede hacer configuración, creación de componentes, creación de hojas lógicas y contenido definido por el usuario de Cocoon para su aplicación

• Modelo de programación

El funcionamiento de Cocoon está basado en el concepto de tubería (pipeline). Cada componente de la tubería acepta una entrada, realiza una operación y devuelve una salida, que es aceptada por otro componente.

La unidad básica de trabajo de Cocoon es el XML procedente de las páginas XSP (eXtensible Server Pages). La Las XSPs manejan la misma idea de las JSPs, es decir, páginas de servidor, con lo cual se tiene dinamismo con posibilidad de conectividad a bases de datos y con las ventajas del XML. Una XSP es simplemente un documento XML en donde se puede incluir contenido tanto estático como dinámico para generar XML de forma dinámica.

El desarrollo consiste prácticamente en escribir los archivos XSP, y solo se emplea Java para cosas puntuales, como el control del flujo del programa.

El framework define una serie de componentes, que pueden ser personalizados por el desarrollador de la aplicación. Los componentes son los siguientes:

• Productores: Son los ficheros fuentes de donde proviene el XML. Estos pueden ser estáticos o dinámicos (es decir creados mediante XSP). La operación de un productor se basa en transformar los datos del fichero en eventos SAX.

• Procesadores: Atrapan el XML de los productores para aplicarle diversos procesos, como por ejemplo hacer conectividad a una base de datos, aplicar transformaciones XSL a los documentos XML, convertir los XSP en clases Java, etc. Son el proceso principal del Pipeline. El más común es el transformador XSLT.

• Formateadores: Son el punto final en un Pipeline. Recogen la representación interna del XML resultante (que está dada en eventos SAX) y la preparan para enviar como respuesta al cliente en el formato adecuado.

El formateador o serializador más común es el serializador XML que simplemente obtiene los eventos SAX y los lleva a un documento XML.

A nivel de usuario, el funcionamiento sería así:

1. El usuario solicita un documento de cualquier tipo al servidor.

2. La solicitud se analiza para concluir si se puede atender o no. Si no se puede atender se produce un mensaje de error.

3. Si se puede atender se analiza a qué productor XML corresponde se genera un documento XML con el cual se trabajará.

4. Se extraen las instrucciones del XML generado en el paso anterior y éstas se le pasan al procesador apropiado para que se le apliquen al XML. Al procesar el XML podría salir un XML con más instrucciones que serán tratadas en algún otro ciclo.

5. El XML procesado se le pasa al elemento que aplica el formato. Si el documento es un documento final,XML aplica el formato y le envía el documento formateado al cliente. En el caso que el documento XML procesado, sea código que deba ejecutarse (como en el caso de una XSP ya compilada), éste se pasa como productor de XML y se vuelve a procesar hasta que se llega a un documento XML final.

• Capas afectadas

Presentación, negocio e integración. Además de estar especializado en la presentación, Cocoon permite el acceso a bases de datos desde las XSPs.

• MVC push/pull

Podría decirse que utiliza un sistema pull ya que cada página XSP puede acceder todas las variables que declare, pero al no existir objetos que modelen los datos de la aplicación tampoco tendría mucho sentido.

• Internacionalizacion (i18n) y localización (L10n)

La internacionalización en Cocoon está basada en un transformador que usa dicccionarios XML predefinidos en distintos idiomas. El diccionario a usar se selecciona en base al Locale del usuario. Estos transformadores pueden agregarse a la tubería y actuar así sobre el XSP.

• Sistema de seguridad

Provee de un sistema de autenticación y autorización basado en la especificación Servlet.

También proporciona un sistema de manejo de errores.

• Sistema de plantillas (templates)

Permite incluir en una página XSP fragmentos de otras páginas, creando la vista general juntando diferentes trozos reutilizables, según dicta el patrón de diseño Composite View .

• Sistema de validación

Proporciona una serie de validadores estándar y permite escribir tus propios validadores en java o javascript.

• Sistema de navegación (pageflow)

Dispone de un sistema de navegación basado el concepto de continuations. Un continuation es un objeto que almacena el estado de la aplicación (variables, pila, contador de programa…). A partir de ese objeto se puede restaurar la aplicación exactamente en el mismo estado en el que se guardó.

• Sistema de caché

En un sistema basado en el parseo y transformación de páginas XML necesita imperiosamente un mecanismo de caché. El bloque Core Cocoon proporciona ese mecanismo y almacena en memoria las páginas creadas.

• Testeabilidad

Como el desarrollo se centra en archivos XML asociados a un DTD, es imposible tener errores de sintaxis. Esto compensa el hecho de que es muy dificil testear la aplicación en tiempo de ejecución debido a su naturaleza.

• Mapeo Objeto-Relacional (ORM)

No proporciona un mecanismo de mapeo O/R.

• Programación Orientada a Aspectos (AOP)

No permite AOP.

• Inyección de dependencias (DI)

No existe la DI.

• Ajax

Cocoon dispone de un bloque para dar soporte a la tecnología Ajax de forma transparente, centrada principalmente en el manejo de formularios (envío, validación, etc).

• Configuración

La configuración está basada, obviamente, en archivos XML.

Cocoon cuenta con varios ficheros para hacer la configuración y personalización del mismo. Entre éstos, el más importante a nivel de usuario es el sitemap.xml. En este fichero se declaran los componentes y las pipelines.

• Extensibilidad

Cocoon 2.2 está diseñado para integrarse con Spring a través del bloque Spring Configurator. Esto le permitiría usar las ventajas de Spring como IoC o integración con sistemas ORM.

• Madurez

Cocoon 2 es la nueva versión de Cocoon, totalmente reescrita con un mejor diseño. Podría considerarse el sistema de publicación de contenidos basado en XML/XLS más sólido.

• Última versión

La última versión estable liberada es Apache Cocoon 2.2

• Curva de aprendizaje

El tiempo de aprendizaje se ve modificada por el hecho de que el desarrollo consiste básicamente en escribir los XSP, para lo que hay que estar familiarizado con el lenguaje XSLT (XSL Transformations).

• Documentación

La documentación oficial proporciona tutorial, FAQ, How-Tos, wiki, guía de usuario y desarrollador, y más. Sin embargo no profundiza demasiado y se encuentra incompleta para las últimas versiones.

• Modelo de programación

Sigue un modelo basado en el patrón de diseño FrontController y el patrón Command¹ . Las clases-acción son usadas para manejar cualquier petición del usuario que requiera interacción con el modelo. Pueden asociarse diferentes acciones para cada elemento de entrada de un formulario html. Las acciones no son asociadas con una única página, si no que puedes reutilizar una acción con varias páginas distintas.

Los módulos que componen Turbine son los siguientes:

• Action: Pemite realizar acciones en respuesta a peticiones HTTP del usuario.

• Page: Es el primer módulo en la cadena de ejecución de la generación de páginas. Se le considera como una caja que contiene al resto de módulos. Se encarga de comprobar si hay una Action definida en la petición y ejecutarla.

• Screen: Es considerado el cuerpo de la página web. En este módulo es donde se genera el HTML. Desde este módulo se puede ejecutar código externo para hacer uso de frameworks de presentación como Cocoon, o importar datos de la capa de integración.

• Navigation: Representa los menús de navegación y se encarga de controlar el flujo de páginas.

• Layout: Define la estructura física de la página. Define la posición del menú Navigation y del cuerpo (Screen) de la página.

• Capas afectadas

El núcleo del framework es capaz de manejar la capa de presentación y negocio.

• MVC push/pull

Es capaz de usar ambos sistemas, Push y Pull.

Puedes asociar una clase-acción con una página y hacer uso de sus variables, pero también puedes invocar una serie de componentes definidos en el API.

• Internacionalización (i18n) y localización (L10n)

Turbine cuanta con un sistema de Internacionalización y localización llamado Fulcrum, que se está migrando para ser un servicio independiente. Permite accceder a mensajes multiidioma desde los motores de plantillas.

• Sistema de seguridad

Dispone de un servicio para manejar Usuarios, Grupos, Roles y Permisos en el sistema, permitiendo que a estos objetos interactuar con bases de datos o LDAP. El servicio además permite que la seguridad sea manejada sin ningún backend.

• Sistema de plantillas (templates)

Turbine viene integrado con velocity como sistema de plantillas. De hecho, originalmente velocity fue diseñado como parte de Turbine. También tiene servicios para integrarse con FreeMarker.

• Sistema de validación

El subsistema Intake se encarga de la validación de las entradas de formularios basándose en las restricciones definidas en un archivo XML.

• Sistema de navegación (pageflow)

El módulo Navigation es el encargado de controlar el fujo de navegación de la aplicación.

• Sistema de caché

A través de los servicios cargados al inicio proporciona un mecanismo de almacenamiento de objetos en memoria.

• Testeabilidad

Para las pruebas de unidad no hay problema ya que las calses-acción son POJOs. Para las pruebas de integración se necesita hacer uso de un contenedor de servicios avalon como Phoenix o Excalibur.

• Mapeo Objeto-Relacional (ORM)

Turbine viene integrado con Torque. Torque es un paquete que se encarga de manejar la relación de la aplicación web con la base de datos. Representa la base de datos a través de un esquema XML y genera una serie de objetos que se comunican con la aplicación y el esquema.

Originalmente Torque se desarrolló como parte del framework Turbine en la versión 2.1, pero después pasó a ser una aplicación independiente.

También permite la integración con otros sistemas ORM como OJB o Hibernate.

• Programación Orientada a Aspectos (AOP)

No soporta Programación Orientada a Aspectos.

• Inyección de dependencias (DI)

No soporta Inyección de dependencias.

• Ajax

El soporte para Ajax depende del motor de visualización que se emplee.

• Configuración

Se puede especificar la configuración de dos formas, a través de una archivo properties o a través de un archivo XML.

• Extensibilidad

Turbine está diseñado de forma modular con el fin de ser fácilmente extensible y poder hacer uso de tecnologías externas como sistemas ORM o motores de plantillas.

• Madurez

Turbine es un framework maduro y estable con mas de 6 años de experiencia y ha sido usado como base de otros proyectos como Jetspeed.

Páginas como www.netbeans.org o www.openoffice.org hacen uso de Turbine.

• Última versión

La versión recomendada desde la página oficial es Apache Turbine 2.3.2

• Curva de aprendizaje

El núcleo del framework se basa en un modelo popularmente conocido, y el resto de funcionalidades se ofrecen como servicios, por lo que la curva de aprendizaje es relativamente pequeña para desarrolladores con experiencia.

• Documentación

Ofrece una buena visión general del framework pero el tutorial y la guía de usuario apenas están esbozados.

1Ver Anexo A

Tapestry es un framework MVC opensource mantenido por la comunidad apache basado en el Java Servlet API 2.2 y pensado para realizar aplicaciones web en Java que sean dinámicas, robustas y altamente escalables, que funciona en todo contenedor de servlets o servidor de aplicaciones. Su filosofía se basa en lo siguiente:

• Simplicidad en la creación de aplicaciones web.

• Consistencia a la hora de que distintos desarrolladores pueden encontrar soluciones similares a problemas similares.

• Eficiencia, las aplicaciones deben ser escalables

• Reacción ante los errores, aportando modos de diagnósticos.

• Modelo de programación

Sigue un modelo basado en componentes y en el patrón de diseño FrontController¹ .

Un componente es un objeto reusable que puede ser considerado como una ”caja negra”, que tiene sus responsabilidades definidas por el diseño y la estructura del framework en el cual se encuentra, y sigue una serie de convenciones (nomenclatura, implementación de ciertas interfaces, etc) que le exige el framework. En tapestry todo son componentes. Cada componente tiene tres partes: Una plantilla HTML, una o varias clases java y un archivo XML para unirlos, en el que se especifican las relaciones entre los parámetros formales en la plantilla y los reales en la clase java. La arquitectura sería la siguiente:

1. Application Engine: Por cada cliente que se conecta a la aplicación se crea una instancia del âœApplication Engineâ que es usado para seguir la actividad del cliente en la aplicación

2. Application Servlet: Sirve de puente entre el âœApplication Engineâ y el contenedor de servlet. Su única función es crear el âœApplication Engineâ tras la primera petición de un cliente a la aplicación y de localizarlo en peticiones futuras.

3. Applicacion Specification: El fichero de especificación de la aplicación es usado para darle a Tapestry una descripción de la aplicación. En él se especifica el nombre de la aplicación, la clase del âœApplication Engineâ, la lista de páginas y nombre de la clase que implementa el Visit Object (si es necesario)

4. Visit Object:Será creado uno por cada una de las conexiones de una cliente a la aplicación. Sirve para almacenar información compartida entre varias páginas de la aplicación.

5. Page Specification: Cada página posee un fichero de especificación en el que se especifica el nombre de la clase que implementa la página y la lista de componentes.

6. Page Template: Este será el fichero html que dará lugar a la representación visual de la página

7. Page implementation: En ella, para cada una los nombres de los parámetros reales, que aparecen en las ligaduras de los parámetros formales a reales en la especificación de los componentes que forman la página, se implementarán métodos get y set

Cada página contiene HTML puro Los componentes son clases abstractas instanciadas por el contenedor.

• Capas afectadas

Se centra principalmente en la capa de presentación. Ha sido concebido para generar e interactuar con la interfaz de usuario

• MVC push/pull

Pull. Cualquier componente puede ser referenciado desde una página HTML a través del lenguaje OGNL.

• Internacionalizacion (i18n) y localización (L10n)

Para la internacionalización Tapestry utiliza lo que denomina catálogos de mensajes que vendrían a ser algo similar a los ResourceBoundles de java donde se guardan pares de cadenas con el formato clave=valor. Cada componente puede tener un set de catálogos de mensajes. Estos catálogos se nombran con el mismo nombre que el componente pero su extensión es .properties. Si una clave no se encuentra en ninguno de los catálogos Tapestry no informa ningún error sino que genera un valor propio.

• Sistema de seguridad

No proporciona un sistema de seguridad que contemple login, autentificación ni autorización, pero sí uno de manejo de errores

Su seguridad contra ataques se basa en la del Servlet API y en que todas las peticiones pasan por determinadas clases y métodos, punto en el cual es posoble acoplar mecanismos de seguridad externos.

• Sistema de plantillas (templates)

No dispone de un sistema de plantillas global que permita crear vistas por composición con un formato reusable para todas las páginas.

• Sistema de validación

La validación la realizan los componentes que reciben los datos de entrada del usuario. No permite métodos propios de validación a no ser que desarrolles tu propio componente de validación.

• Sistema de navegación (pageflow)

No proporciona un mecanismo de navegación

• Sistema de caché

No proporciona un sistema de caché.

• Testeabilidad

Las pruebas de unidad son muy laboriosas de realizar, ya que las clases de los componentes son abstractas.

• Mapeo Objeto-Relacional (ORM)

No. Tapestry se centra en la capa de presentación.

• Programación Orientada a Aspectos (AOP)

No, pero es posible obtenerla integrando el microkernel Hivemind² , tambien de la Apache Software Foundation.

• Inyección de dependencias (DI)

No, pero es posible obtenerla integrando el microkernel Hivemind.

• Ajax

Es posible obtenr funcionalidades Ajax con la biblioteca de componentes Tacos

• Configuración

La configuración se realiza a través de archivos xml, uno para cada componente.

• Extensibilidad

Tapestry está diseñado para ser un framework de presentación, permitiendo acoplar otro framework por debajo para gestionar la lógica de negocio y la capa de integración.

• Madurez

El producto es maduro y la solución parece correcta y robusta. Más allá de esto es menos maduro que otros productos, como por ejemplo struts y está evolucionando hacia Java 5.

• Última versión

La última versión liberada de Tapestry es la 4.1.3, que es sobre la que hemos hecho la comparaciones

También existe una muy interesante preview de la version 5.0 que incluye, entre otras cosas, anotaciones en detrimento de los archivos xml

• Curva de aprendizaje

La curva de aprendizaje podría considerarse relativamente suave, ya que el modelo de programación basado en componentes es simple.

• Documentación

Dispone de documentación oficial con tutorial, FAQ, guía de usuario y códigos de ejemplo.

Stripes es un framework de presentación opensource cuyo principal objetivo es la creación de aplicaciones web reduciendo la configuración al mínimo. Intenta que el desarrollo sea simple y rápido para los desarrlladores.

• Modelo de programación

Stipes sigue un modelo de programación basado en acciones. La espina dorsal del framework es el interface ActionBean que deben implementar todas las clases que respondan a eventos de la interfaz de usuario.

Cada ActionBean está asociado a una URL que será invocada desde un formulario y en él se encuentra la lógica de negocio, las reglas de validación y las variable que sirven de backend a las del formulario. Los ActionBean también pueden ser configurados como EventListeners.

A grandes rasgos, su funcionamiento sería el siguiente:

1. En base a la URL de la petición se selecciona un ActionBean y se establece su ActionBeanContext

2. Se determina el método a ejecutar para el evento recibido en la petición

3. Se pone el valor de los elementos del formulario de la petición en las variables del ActionBean, ejecutando la validación si es necesario

4. Se invocan los métodos de validación personalizados

5. Se invoca el método correspondiente en el ActionBean

6. Si el ActionBean devuelve una Resolution no nula, se ejecuta para determinar la vista a mostrar.

• Capas afectadas

Se centra en el manejo de las capas de presentación y negocio.

• MVC push/pull

Sigue un modelo push. Asocia a cada formulario un ActionBean usando anotaciones.

• Internacionalizacion (i18n) y localización (L10n)

Stripes proveé de un objeto LocalePicker capaz de reconocer el Locale del cliente y la codificación de caracteres en cada petición y escoger el adecuado de entre los soportados por la aplicación. Permite definir archivos de mensajes propios siguiendo las convenciones de nombrado de los ResourceBundles.

• Sistema de seguridad

Se proporciona un sistema de seguridad llamado stripes-security como extensión al núcleo del framework que proporciona un sistema de autorización basado en roles.

• Sistema de plantillas (templates)

Proporciona etiquetas para crear de una manera simple vistas compuestas a partir de fragmentos reutilizables

• Sistema de validación

Proporciona una serie de reglas de validación que son establecidas mediante anotaciones desde los ActionBean y se encargan de validar los campos de entrada de los formularios. También permite añadir métodos propios de validación y manejar los errores de validación generados.

• Sistema de navegación (pageflow)

No proporciona un sistema de navegación.

• Sistema de caché

No proporciona un sistema de caché.

• Testeabilidad

Los test de unidad son sencillos usando frameworks de test como JUnit o TestNG, ya que los ActionBeans son POJOs que pueden ser instanciados directamente. además, Stripes proporciona un conjunto de MockObjects que implementan interfaces de la especificación Servlet y pueden ser usados para recrear el entorno en el que se ejecutarán los ActionBean.

• Mapeo Objeto-Relacional (ORM)

No tiene un sistema ORM propio pero se integra con hibernate. Para una integración sencilla conviene el uso de la librería Stripernate.

• Programación Orientada a Aspectos (AOP)

No dispone de AOP pero puede conseguirse mediante su integración con Spring.

• Inyección de dependencias (DI)

No soporta inyección de dependencias, pero puede conseguirse mediante su integración con Spring.

• Ajax

No proporciona soporte nativo para usar Ajax en el lado del cliente y sugiere la utilización de librerías como Prototype o Dojo.

Para elaborar las respuestas Ajax en el lado del servidor, proporciona utilidades para transformar objetos java en objetos javascript.

• Configuración

Este es uno de los puntos fuertes de Stripes. Para su puesta en funcionamiento solo requiere configurar el Stripes Filter y el Stripes Dispatcher Servlet en el web.xml.

El resto de configuración se realiza mediante anotaciones y en el caso de no existir estas, se recurre a la configuración por omisión.

• Extensibilidad

Stripes ha sido diseñado para ser facilmente extensible sin necesidad de tener que configurar cada detalle. En la documentación se encuentra cómo hacer que coopere con Spring, Hibernate y FreeMaker entre otros.

• Madurez

A pesar de ser un framework relativamente nuevo, su sencillez lo hace estable y la retroalimentación por parte de la comunidad lo ha ido perfeccionando desde su primera versión.

• Última versión

La última versión de Stripes es la 1.4.3, liberada el 15 de Mayo del 2007

• Curva de aprendizaje

La curva de aprendizaje es extremadamente corta. El principal objetivo de Stripes es la simplicidad, y según su documentación oficial, un desarrollador puede poner Stripes en funcionamiento en menos de 30 minutos.

• Documentación

La página del proyecto proporciona una documentación bien estructurada con ejemplos, FAQ, How-Tos, una serie de artículos propios y otros añadidos por los usuarios. Es simple, clara y pensada para el usuario.

Intenta reducir al mínimo la cantidad de código necesario para trabajar con el framework, permitiendo a los desarrolladores centrarse en la lógica de negocio y el modelado. En su versión 2.2 (año 2006), WebWork se fusionó con la comunidad Struts dando lugar a Struts Action Framework 2.0. Este framework maniene la filosofía de WebWork y se aprovecha de la gran comunidad de usuarios de Struts y de estar bajo el nombre de la fundación apache.

• Modelo de programación

En el núcleo de WebWork se encuentra el API XWork. XWork es un framework basado en acciones y en los patrones de diseño Front Controller y Comman, centralizado entorno al interface Action, el cual deben implementar en forma de POJO las clases-acción que queramos que respondan a peticiones de la interfaz de usuario y devuelvan un resultado. El framework se encarga de manejar el ciclo de vida de las Actions y de proporcionar un contexto de acción en cada petición, a través del cual acceder a propiedades de la aplicación.

WebWork posee un fichero en el se mapean vistas y clases-acción. Los campos de las vistas son rellenados desde y hacia los campos de la acción (definidos como propiedades JavaBean) automáticamente. La clase-acción tiene además un método de validación que valida los datos introducidos y devuelve mensajes de error en caso de que los datos no sean correctos. Cuando la acción se ejecuta, devuelve un string indicando si la acción ha tenido éxito y así saber qué vista hay que mostrar. Además, las acciones se pueden encadenar unas detrás de otras, de forma que la primera recoge los valores de entrada, las de la cadena realizan procesamiento y la última decide qué vista mostrar, como una tubería.

• Capas afectadas

Se centra en la capa de presentación y negocio

• MVC push/pull

Permite usar ambos, Push y Pull.

Por un lado permite asociar páginas con clases-acción, pero también proporciona una serie de componentes reusables que pueden ser invocados desde cualquier página.

• Internacionalizacion (i18n) y localización (L10n)

WebWork soporta internacionalización en dos lugares: Las etiquetas de la interfaz de usuario y los mensajes de validación, a través de ficheros de recursos (resource bundles). El interceptor i18n de WebWork se encarga de determinar el locale del cliente y elegir el archivo correspondiente.

• Sistema de seguridad

No proporciona un sistema de seguridad.

• Sistema de plantillas (templates)

A través de las librerías de etiquetas se pueden construir vistas según el patrón Composite View² .

También puede configurarse para usar en la capa de presentación tecnologías como FreeMarker o JasperReports.

• Sistema de validación

Proporciona un sistema de validación basado en XWork y dispone de una serie de validadores predefinidos y permite agregar validadores creados por el desarrollador.

Permite la validación en el servidor y/o en cliente usando Ajax o javascript simple.

• Sistema de navegación (pageflow)

En el archivo de configuración principal se definen para cada acción una vista de entrada y una vista de salida a la que redirigir en caso de ejecutarse con éxito.

• Sistema de caché

No proporciona un sistema de caché.

• Testeabilidad

Al tener un diseño basado en POJOs los test de unidad son muy simples. Para testear interceptores proporciona una serie de Mocks que emulan el entorno.

También ofrece una serie de TestSuites por defecto que pueden ser un buen punto de partida para empezar.

• Mapeo Objeto-Relacional (ORM)

No. Se centra en la capa de persentación-negocio. Sin embargo, se puede acoplar sin problemas con cualquier solución ORM.

• Programación Orientada a Aspectos (AOP)

No proporciona las ventajas de la AOP por sí mismo, pero se detalla como configurar el framework para hacer uso de Spring.

• Inyección de dependencias (DI)

WebWork viene con un contenedor de Inversion of Control integrado, sin embargo está en vías de desaparecer en futuras versiones y desde la documentación oficial se recomienda usar otros contenedores como Spring.

• Ajax

WebWork ofrece características Ajax usando las librerías Dojo y DWR. Permite la validación en el cliente, formularios y links remotos entre otros.

• Configuración

La configuración se centra en el archivo xwork.xml. Ahí se definen namespaces, interceptores, y el mapeo de nombre de acciones-clases.

Para aplicaciones grandes este archivo puede volverse inmanejable.

• Extensibilidad

Sigue un diseño basado en POJOs que le permite acoplar en la capa de negocio casi cualquier otro framework.

• Madurez

WebWork sigue el mismo diseño base que Struts, pero con una API mucho más simplificada. Este diseño ha sido más que probado y ha demostrado ser robusto y fiable.

• Última versión

La última versión disponible es WebWork 2.2.6 y Struts 2.0.6

• Curva de aprendizaje

Uno de los objetivos del diseño de WebWork es que su uso sea fácil e intuitivo para el desarrollador. Presenta una curva de aprendizaje muy suave.

• Documentación

La documentación es muy completa y se encuentra bien organizada, cubriendo los tópicos y con ejemplos. También proporciona guía, referencia, FAQ, artículos, varios tutoriales, trozos de código, aportes de usuario….

• Modelo de programación

Tiene un diseño 100% basado en componentes.

• Capas afectadas

JBoss Seam ofrece una solución completa para el desarrollo web que abarca todas las capas, desde la de presentación hasta la de integración.

• MVC push/pull

Sigue un modelo Pull en el que desde una página puede referenciarse cualquier componente que esté asociado a un contexto accesible.

• Internacionalizacion (i18n) y localización (L10n)

Proporciona varios componentes para manejar los mensajes multidioma.

Determina automática el Locale de cada petición y lo usa si está disponible en la aplicación. También permite sobreescribir el Locale detectado y/o establecer uno por defecto. Se pueden configurar los mensajes en archivos de recursos tipo bundle.

Para los mensajes de error o éxito se puede hacer uso de la clase de FacesMessages incluida con JSF.

Dispone de una clase que se encarga de parsear automáticamente los formatos horarios al formato establecido.

• Sistema de seguridad

El Seam Security API es una parte de Seam que proporciona funcionalidades de autenticación y autorización basado en JAAS (Java Authentication and Authorization Service). Puede usarse el modo sencillo por defecto que se basa en roles o usar el framework JBoss Rules, que ofrece un sistema más poderoso basado en reglas. El sistema se encarga del manejo de errores de autorización o autenticación permitiendo redirigir al usuario a una página determinada.

Las restricciones pueden establecerse mediante el uso de anotaciones. Permite restringir tanto acciones como entidades o páginas o componentes de la página.

• Sistema de plantillas (templates)

Seam viene integrado por defecto con Facelets.

Facelets es un sistema de plantillas para JSF. Permite definir la vista mediante xml en forma de árbol de manera que se pueden definir componentes como composición de otros componentes. Entre sus características destacar que soporta el lenguaje EL, composición a partir de diferentes archivos, decorators y reporte de errores indicando la etiqueta/linea precisa.

• Sistema de validación

Las restricciones se definen en los componentes de entidad mediante las anotaciones de la especificación JPA o haciendo uso de las anotaciones de la extensión Hibernate Validator.

Para especificar en la página los componentes que deben ser validados se proporcionan etiquetas para definirlos uno a uno o validar todos los campos del formulario.

La validación puede realizarse en segundo plano mediante Ajax y los mensajes de error pueden leerse de un archivo de recursos tipo bundle o especificarlos en la propia anotación si se usa Hibernate Validator.

• Sistema de navegación (pageflow)

Podemos seguir dos modos de navegación, uno que tiene cuenta el estado de la aplicación (stateful) usando el framework jPDL y otro que no (stateless) usando las reglas de navegación JSF Rules o Seam Rules.

Para aplicaciones sencillas tan solo necesitaremos el modelo stateless, pero las aplicaciones complejas hacen uso de ambos. jPDL (jBPM Process Definition Languaje) define un sistema de navegación basado en un grafo de nodos y transiciones. La elección del siguiente estado dependerá del valor de ciertas variables. La configuración puede hacerse mediante XML o anotaciones

Gracias al contexto de conversación capaz de almacenar el estado de los componentes, Seam funciona perfectamente con el botón de navegación “Atrás” del explorador.

• Sistema de caché

En total podemos encontrar varios sistemas de caché.

En primer lugar podemos encontrar la importantísima caché de la base de datos.

Después existe otra caché en la solución ORM adoptada.

El contexto de persistencia manejado por Seam actúa como caché de los datos leídos en la conversación actual.

También pueden guardarse datos no transaccionales en el contexto de aplicación.

La aplicación puede almacenar datos en memoria utilizando el sistema JBoss Cache, que ofrece una cache estructurada en forma de árbol, con posibilidad de cluster y transaccional.

• Testeabilidad

Al ser POJOs todos los componentes, los test de unidad son triviales. También se proporcionan anotaciones para facilitar la recreación del entorno.

Para los test de integración proporciona un contenedor de EJBs y declaración de objetos mock mediante anotaciones.

La herramienta SeamGen crea automáticamente test de unidad estándar y test TestNG que simulan peticiones y respuestas JSF para cada acción mediante scripting.

• Mapeo Objeto-Relacional (ORM)

Seam proporciona soporte completo para las dos arquitecturas de persistencia más populares: hibernate 3 y el Java Persistence API introducido con EJB 3.0.

A través de el contexto de conversación y los componentes con estado asociados a él, es capaz de manejar eficientemente las operaciones transaccionales e implementar el patrón de carga perezosa (LazyLoad) sin los errores presentes en otras soluciones ORM.

• Programación Orientada a Aspectos (AOP)

JBoss Seam hace uso extensivo de AOP para proporcionar funcionalidades de caché, seguridad, inyección de dependencias, interceptores, pageflow…

• Inyección de dependencias (DI)

No solo soporta Dependency Injection si no que también permite Dependency Outjection, depositando y obteniendo instancias de un componente de los diferentes contextos, cada una de ellas con su propio estado.

• Ajax

El diseño de JBoss Seam ha sido concebido con Ajax en mente. Es capaz de manejar peticiones simultáneas de distintos usuarios preservando las condiciones de aislamiento e integridad de los datos. El sistema de cache evita la sobrecarga de tráfico con la base de datos que afecta a muchas aplicaciones que usan Ajax.

El soporte en la parte del cliente está a cargo de la implementación de JSF que se elija. En cualquier caso, mediante la librería Ajax4jsf de JBoss se pueden añadir funcionalidades Ajax a los componentes ya existentes.

• Configuración

La configuración puede realizarse en su práctica totalidad mediante anotaciones, lo que ayuda a simplificar esta tediosa tarea. Aún así, hay una pequeña cantidad de configuración que debe hacerse con XML (como la relativa a JSF). Afortunadamente, esta configuración es autogenerada por la herramienta SeamGen. En caso de no hacer uso de ella, la configuración puede copiarse de las aplicaciones de ejemplo. Además, el framework sigue la filosofía de “configuración por omisión”: Todos los componentes vienen con un comportamiento por defecto que solo hace falta redefinir si queremos personalizarlos.

También permite la configuración de los componentes internos del framework a través del archivo seam.properties.

• Extensibilidad

El diseño basado en componentes le permite integrarse con numerosas tecnologías tan dispares como Google Web Toolkit, Spring, Groovy… ademas de las propias de JBoss que vienen integradas por defecto.

• Madurez

En el diseño de JBoss Seam han participado pesos pesados del desarrollo de software como Gavi King (creador de Hibernate) y se asienta sobre principios que han popularizado frameworks como RubyOnRails o Spring.

Además, es una de los freameworks que se están tomando como referencia para futuros estándares como WebBeans.

• Última versión

La última versión es JBoss Seam 2.0.0 CR2 y data del 5 de octubre del 2007.

• Curva de aprendizaje

JBoss Seam sigue un modelo de programación muy sencillo y uniforme, basado en componentes y anotaciones en todas las capas de la aplicación. En ningún momento hace falta extender una clase ni implementar un interfaz, no tienes que aprenderte ningún API, simplemente un par de conceptos. Esto hace que la curva de aprendizaje sea muy muy suave.

• Documentación

En la distribución de Seam se incluyen varias aplicaciones de ejemplo que cubren casi todas las funcionalidades del framework. El tutorial oficial es muy extenso. En él se detallan todos los aspectos del framework con códigos de ejemplo. Explica los conceptos, las diferentes configuraciones posibles, las anotaciones, la integración con otras tecnologías, etc…

Spring Framework está diseñado como una serie de módulos que pueden trabajar independientemente uno de otro, lo que quiere decir que puedes únicamente los módulos que necesites. Además intenta mantener un mínimo acoplamiento entre la aplicación y el propio framework de forma que podría ser desvincualda de élsin demasiada dificultad.

El sub-framework SpringMVC es solo una parte del diseño global, que va mucho más allá

• Core: Como su nombre indica, es el núcleo de Spring. Permite técnicas de Inversión del Control (IoC) como la inyección de dependencias.
• Context: Proporciona herramientas para acceder a los beans y da soporte a propagación de eventos, resource bundles, carga de recursos y creación transparente de contextos por parte de los contenedores.
• DAO: Proporciona una capa de abstracción JDBC y una forma de administrar transacciones.
• ORM: Provee capas de integración para APIs de mapeo objeto-relacional.
• AOP: Proporciona una implementación de programación orientada a aspectos, permitiendo definir puntos de corte e interceptores.
• Web: Provee de características de integración orienteadas a la web, como funcionalidad multipartes, inicialización de contextos mediante servlet listeners y un contexto de aplicación orientada a la web. También permite integrar de forma sencilla otros frameworks como Struts, JSF o WebWork.
• Spring MVC: Provee una implementación Modelo-Vista-Controlador que permite el uso del resto de funcionalidades del Spring Framework.

• Modelo de programación
Spring MVC es un framework basado en peticiones (request). Define una serie de interfaces claves para cada una de las responsabilidades que deben ser manejadas durante la petición, que el usuario puede implementar. Los interfaces y su responsabilidad son los siguientes:

• HandlerMapping: Selecciona el manejador adecuado de la petición

• HandlerAdapter: Ejecuta el manejador de la petición.

• Controller: Procesa la petición y redirige a la respuesta correspondiente.

• View Devuelve una vista al cliente.

• ViewResolver Selecciona una vista basada en su nombre lógico.

• HandlerInterceptor Permite interceptar las peticiones, como un filtro.

• LocaleResolver: Determina el locale de el usuario.

• MultipartResolver: Facilita el trabajo con peticiones multipart, usadas para la subida de archivos.

El funcionamiento paso a paso sería así:

1. El usuario realiza una petición de un recurso en la aplicación web.

2. El Spring Front Controller¹ , llamado Dispatcher Servlet, intercepta la petición y busca el Handler Mappings adecuado

3. El Handler Mappping se encarga de buscar al Controller correcto de entre una lista definida en un archivo de configuración.

4. Conla ayuda de Handler Adapters, el Dispatcher Servlet envía la petición al controller.

5. El controller procesa la petición y devuelve el Modelo y la Vista como un objeto ModelAndView al FrontController

6. El Front Controller busca la vista adecuada consultando al ViewResolver.

7. La vista seleccionada es renderizada al usuario.

• Capas afectadas

Se centra en la capa intermedia y proporciona enganches para manejar la solución elegida para la capa de presentación y de integración.

• MVC push/pull

Push.

EL Controller permite asociar un objeto al ModelAndView, que estará disponible en la vista seleccionada.

• Internacionalizacion (i18n) y localización (L10n)

Permite acceder a mensajes multiidioma definidos por el usuario a través de un bean MessageSource

• Sistema de seguridad

Spring viene integrado con un framework de seguridad, acegi security, que gestiona todo el mecanismo de login, autentificación y autorización.

Permite entre otras cosas controlar la seguridad de tu aplicación web de manera declarativa, posee seguridad basada en roles, en listas de control de acceso, Single Sing On. Se integra con JAAS (Java Authentication and Authorization Service) y con LDAPs (Lightweight Directory Access Protocol)

• Sistema de plantillas (templates)

No proporciona un mecanismo de plantillas propio, ya que permite elegir la tecnología a utilizar para la vista (JSP, JSF, velocity, PDF…) integrándola con el resto de la aplicación.

• Sistema de validación

Provee un sistema de validación que no está ligado a una capa concreta, si no que puede ser usado en cualquier capa de la aplicación. Provee de un interfaz para escribir tu lógica de validación y se encarga del manejo de errores.

El sistema de seguridad acegi también ofrece un paquete de validación.

• Sistema de navegación (pageflow)

Ofrece el módulo Spring Web Flow. Proporciona un motor capaz de capturar los flujos de páginas de una aplicación e integrarlo con otros frameworks de presentación como JSF. Utiliza estructuras declarativas basadas en máquinas de estados.

Éste es un módulo autónomo que puede reutilizarse en diferentes aplicaciones que sigan una misma lógica de navegación como por ejemplo, carritos de la compra.

• Sistema de caché

No proporciona un sistema de caché nativo, pero su diseño permite la integración de módulos que se encarguen de ello, como por ejemplo Spring AOP Cache.

Éste utiliza la AOP proporcionada por Spring para interceptar las invocaciones de métodos y almacenar en memoria el resultado de operaciones como una consulta a una base de datos.

• Testeabilidad

Spring proporciona un estupendo marco para el testing. Al estar basado en POJOs, los test de unidad son triviales con su adaptación de JUnit. Para los test de integración provee herramientas basadas en su capacidad de IoC y de transaccionalidad.

• Mapeo Objeto-Relacional (ORM)

Proporciona integración con varias implementaciones ORM. Existen dos formas de integración, a través de plantillas predefinidas del módulo SpringDAO o codificando DAOs directamente contra al API del ORM elegido.

Cualquiera de las dos aproximaciones ofrece los beneficios de Spring, como ser configurados a través de IoC, transaccionalidad, wrapping común para excepciones de acceso a datos y manejo de la configuración independiente de la implementación.

• Programación Orientada a Aspectos (AOP)

Spring permite el uso de aspectos en tiempo de ejecución mediante proxys dinámicos, por que sólo hace falta la JDK para poder implementar los aspectos. La desventaja es sólo pueden pueden usarse aspectos a nivel de método, no a nivel de clase ni de instancia. Aunque en la gran mayoría de los casos es suficiente, permite la integración de AspectJ que ofrece funcionalidad completa.

Spring usa AOP para proporcionar servicios empresariales de manera declarativa, especialmente como reemplazo para los servicios declarativos de EJB. El más importante de dichos servicios es el manejo declarativo de transacciones, que esta construido sobre la abstracción de transacciones de Spring.

• Inyección de dependencias (DI)

Esta es una de las bases de Spring sobre la que se cimienta el resto de la arquitectura. La DI se encuentra en el corazón de Spring.

A través de la BeanFactory, el contenedor de IoC instancia los objetos y maneja las relaciones entre ellos, añadiendo funcionalidades como pooling o swapping (intercambio).

• Ajax

Al permitir la elección de la tecnología de la capa de presentación, el soporte para Ajax dependerá principalmente de la elección.

• Configuración

La configuración de Spring está basada en XML. Al no tener anotaciones no le hace dependiente de Java EE 5, pero resulta en archivos de configuración inflados o una gran cantidad de archivos de configuración distintos.

Ofrece la ventaja de “XML extensible”, que permite a frameworks externos escribir sus propios archivos de configuración que puede ser acoplado a los archivos de configuración de Spring.

• Extensibilidad

El diseño de Spring está pensado para ofrecer un modelo de como debe trabajar la aplicación y cómo se comunican sus partes. Está expresamente concebido para que deba ser extensible y acoplable con otros frameworks, ya que no ofrece una solución completa que abarque desde la presentación al modelo.

• Madurez

A pesar de su juventud (Spring 1.0 fue lanzado en el año 2003), Spring ha demostrado tener una arquitectura sólida y, sobre todo, muy flexible, capaz de adaptarse a los requerimientos de proyectos grandes y pequeños.

• Última versión

La última versión disponible de Spring es la 2.0.7

• Curva de aprendizaje

No puede decirse que la curva de aprendizaje sea suave debido a que Spring introduce conceptos relativamente novedosos como son la AOP o la IoC y a la cantidad de configuración que hay que manejar.

Sin embargo para alguien con experiencia en desarrollo J2EE y familiarizado con dichos conceptos no debería resultar muy dificil. Para facilitar el desarrollo existen IDEs opensource como SpringIDE, que ayudan entre otras cosas a lidiar con los archivos de configuración y diseñar el flujo de la aplicación.

• Documentación

Cuenta con una buena documentación oficial que cubre todos sus módulos y funcionamiento así como su integración con otros frameworks. También tiene una nutrida comunidad de usuarios que aportan artículos y trabajos.

• Modelo de programación

Sigue un modelo de programación basado en acciones

Todas las peticiones HTTP (request) realizadas por el cliente son dirigidas al controlador principal (ActionServlet) y redirigidas según el mapeo especificado (ActionMapping) en un archivo de configuración (struts-config.xml) a clases-accion (ActionForm) que implementan la lógica de la aplicación y tienen asociado un bean-formulario (FormBean) con los datos enviados. Posteriormente el controlador redirige a la vista adecuada.

Paso a paso, su funcionamiento sería así:

1. El cliente solicita una página que contiene datos a completar.

2. El servidor le envía la página.

3. El cliente, con los datos completados envía de regreso la página. El ActionServlet verifica la ruta con la que se lo invocó y extrae el path de esa ruta y busca en los actionMappings cual es la Acción a invocar y que formulario necesita recibir como entrada

4. El controlador crea o reutiliza el Formulario dependiendo el ámbito en que es ejecutada la petición, carga los datos en el formulario, los valida y luego crea la acción y le pasa el formulario como parámetro

5. La acción recibe el formulario y con sus datos invoca a las reglas del negocio (generalmente delegadas en otros objetos)

6. A partir de la respuesta recibida, carga los valores de salida y selecciona la siguiente vista a enviar

Como puede apreciarse, el diseño está basado en el patrón “Service to Worker”. Este consiste en Combinar un controlador y un dispacher con vistas y helper (Front Controller + View Helper¹ ) para manejar peticiones de clientes y preparar una presentación dinámica como respuesta. Los controladores delegan la recuperación de contenido en los helpers, que manejan el relleno del modelo intermedio para la vista. Un dispatcher es el responsable del control de la vista y la navegación y puede encapsularse dentro de un controlador o de un componente separado.

• Capas afectadas

Presentación y Negocio.

• MVC push/pull

Push.

El FormBean definido en el ActionMapping para la acción que se va a ejecutar está disponible en la página a través de la biblioteca de etiquetas (TAGs) de Struts

• Internacionalizacion (i18n) y localización (L10n)

Permite definir archivos de mensajes para diferentes idiomas y seleccionar uno automáticamente dependiendo del idioma por defecto del cliente. No proveé de un mecanismo para elegir el idioma.

Estos archivos tienen una serie de pares clave/valor que son referenciados desde la vista.

• Sistema de seguridad

Se encarga de los mecanismos de control de autenticación y acceso.

• Sistema de plantillas (templates)

Las últimas versiones de Struts vienen con la extensión Struts-Tiles integrada. Este es un sistema de plantillas que sigue el patrón Composite View² . Esto consiste en utilizar vistas compuestas que se componen de varias subvistas atómicas. Cada componente de la plantilla se podría incluir dinámicamente dentro del total y la distribución de la página se maneja independientemente del contenido.

• Sistema de validación

Define las reglas de validación en un archivo llamado validation-rules.xml. El framework lee las restricciones definidas y agrega validadores a las entradas en el lado del cliente y del servidor.

También permite Validar los datos desde el FormBean.

• Sistema de navegación (pageflow)

Cada accion definida en struts-config.xml puede tener asociado uno o varios forwards que indican a qué página debe redirigirse. La elección del forward se realiza desde el ActionForm

• Sistema de caché

No proporciona un sistema de caché.

• Testeabilidad

No proveé de un mecanismo nativo, pero existen numerosas extensiones para realizar los test.

• Mapeo Objeto-Relacional (ORM)

No. Struts se centra en las capas de negocio y presentación, pero debido a su diseño es fácil hacerlo cooperar con soluciones ORM.

• Programación Orientada a Aspectos (AOP)

No.

• Inyección de dependencias (DI)

No

• Ajax

No viene integrado por defecto, cosa lógica ya que Struts es mucho anterior a Ajax.

Sin embargo es posible su integración, pero es laboriosa, ya que requiere reescribir código en la capa de presentación y negocio.

• Configuración

La configuración está basada 100% en archivos XML y prácticamente centralizada en el fichero de configuración principal: struts-config.xml. Para aplicaciones grandes este fichero suele volverse inmanejable.

• Extensibilidad

Este es uno de los puntos sus fuertes. Struts no fue diseñado para ofrecer una solución web completa, si no como un núcleo que define la comunicación entre la capa de presentación y negocio.

Es fácil añadirle extensiones para manejar la seguridad, el flujo de páginas, plantillas de vistas… y hacerle cooperar con otros framewoks como hibernate o Spring.

• Madurez

En cuanto a madurez puede decirse que es el lider indiscutible. Ha sido el estandar de facto durante años, y ha sido usado por grandes y pequeñas empresas en multidud de proyectos.

• Última versión

Hemos trabajado con la versión 1.3.8. También existe un Struts 2.0, pero sus características son tan diferentes que puede considerarse un framework completamente distinto a Struts 1.X

• Curva de aprendizaje

Struts proveé una API con sus métodos y sus clases, las cuales tienes que extender para implementar la lógica de negocio. Esto hace que tengas que tener un conocimiento aceptable de dichas clases, sus responsabilidades y sus interacciones, lo que retrasa la hora de empezar a desarrollar. Sin embargo no presenta un modelo demasiado complicado y gracias a la cantidad de documentación se hace más facil.

• Documentación

Debido a su gran difusión existen inumerables artículos, foros y similar con información sobre su funcionamiento, integración y cualquier problema que pueda surgir durante un desarrollo basado en struts

”Framework” es una palabra que se usa (y de la que se abusa) mucho actualmente en el desarrollo de aplicaciones. Sin embargo puede que alguien no tenga claro el concepto de los que es un framework para el desarrollo de aplicaciones web. Podría definirse como un conjunto de clases que cooperan y forman un diseño reutilizable formando una infraestructura que facilita y agiliza el desarrollo de aplicaciones web.

En este primer artículo, a modo de introducción, voy a describir los puntos en los que basaré la comparativa.

Puntos de comparación

Como funciona

• Modelo de programación

Breve descripción del funcionamiento básico del framework

• Capas afectadas

Consideraremos una arquitectura multicapa

La capa del cliente es donde se consumen y presentan los modelos de datos. Para una aplicación Web, la capa cliente normalmente es un navegador web.

La capa de presentación expone los servicios de la capa de negocio a los usuarios. Sabe cómo procesar una petición de cliente, cómo interactuar con la negocio, y cómo seleccionar la siguiente vista a mostrar.

La capa de negocio contiene los objetos y servicios de la lógica de negocio de la aplicación. Recibe peticiones de la capa de presentación, procesa la lógica de negocio basada en las peticiones, y media en los accesos a los recursos de la capa EIS. Los componenes de la capa de negocio se benefician de la mayoría de lo servicios a nivel de sistema como el control de seguridad, de transaciones y de recursos.

La capa de integración es el puente entre la capa de lógica-de-negocio y la capa EIS. Encapsula la lógica para interactuar con la capa EIS. Algunas veces a la combinación de las capas de integración y de lógica-de-negocio se le conoce como capa central.

La capa EIs almacena los datos de la aplicación. Contiene bases de datos relacionales, bases de datos orientadas a objetos, y/o sistemas antiguos.

• MVC push/pull

Hace referencia a cómo son accesibles los objetos de la capa de negocio desde la capa de presentación.

MVC Push indica que un objeto de la capa de negocio está asociado a una página.

MVC Pull indica que uno o varios objetos están disponibles para todas las páginas.

Qué ofrece

• Internacionalizacion (i18n) y localización (L10n)

El sistema de internacionalización asegura que una aplicación sea capaz de adaptarse a los requerimientos locales del cliente, por ejemplo asegurar que los caracteres de su idioma puedan ser mostrados.

El sistema Locacalización intenta que la aplicación se adapte a la cultura del cliente, mostrando las fechas en un determinado formato, usando determinados sistemas de medida, etc.

• Sistema de seguridad

Se encarga de los mecanismos de control de autenticación y acceso.

• Sistema de plantillas (templates)

Facilita y agiliza el desarrollo de los componentes de la vista a través de esquemas, siguiendo los principios de separación de capas, flexibilidad, reusabilidad.

• Sistema de validación

El sistema de validación se encarga de comprobar que los datos que el cliente introduce a través de la capa de presentación sean válidos.

Podemos realizar la validación de los datos en el cliente, en el servidor o en ambos.

• Sistema de navegación (pageflow)

Es el encargado de determinar cuál será la próxima página a mostrar según determinados parámetros como la página actual, la operación realizada, el resultado de dicha operación o el rol del usuario.

• Sistema de caché

Permite almacenar en memoria cualquier información relativa al estado de la aplicación o resultados de una consulta a una base de datos, mejorando el rendimiento.

• Testeabilidad

Las pruebas de software verifican que el software desarrollado o modificado cumple los requerimientos solicitados de forma satisfactoria.

• Mapeo Objeto-Relacional (ORM)

El mapeo objeto-relacional es una técnica de programación para convertir datos entre el sistema de tipos utilizado en un lenguaje de programación orientado a objetos y el utilizado en una base de datos relacional.

Analizaremos si el framework evaluado nos ofrece algún sistema ORM o permite la integración con uno.

• Programación Orientada a Aspectos (AOP)

La Programación Orientada a Aspectos, más conocida como AOP por su nombre en inglés Aspect Oriented Programming, es un modelo de programación que aborda un problema específico: capturar las partes de un sistema que los modelos de programación habituales obligan a que estén repartidos a lo largo de distintos módulos del sistema. Estos fragmentos que afectan a distintos módulos son llamados aspectos y los problemas que solucionan, problemas cruzados (crosscutting concerns).

Usando un lenguaje que soporte AOP, podemos capturar estas dependencias en módulos individuales, obteniendo un sistema independiente de ellos y podemos utilizarlos o no sin tocar el código del sistema básico, preservando la integridad de las operaciones básicas.

• Inyección de dependencias (DI)

Este patrón de diseño consiste en resolver las dependecias de cada clase (atributos) instanciando los objetos cuando se arranca la aplicación e inyectándolos en los objetos que los necesiten. De esta forma liberamos a los objetos de la responsabilidad de instanciar otros objetos y delegamos este trabajo a una factoría que pueda realizar más eficientemente esta tarea, añadiendo funcinalidades como pooling de instancias.

• Ajax

Ajax (Asynchronous JavaScript And XML) es una técnica de desarrollo web para crear aplicaciones interactivas. Se ejecuta en el cliente y mantiene una conversación asíncrona en segundo plano con el servidor, permitiendo realizar acciones sin necesidad de recargar la página, lo que aumenta la interactividad, usabilidad y velocidad. Indicaremos si el framework integra Ajax o es posible su integración.

Otros

• Configuración

Indicaremos el tipo de configuración (anotaciones, xml, ficheros properties…) y si es sencilla, cómoda y manejable.

• Extensibilidad

La facilidad con la que el framework puede ser ampliado integrando nuevos módulos que doten de nuevas funcionalidades o modifiquen las ya existentes.

• Madurez

Indica si el framework está suficientemente probado por los usuarios y ha demostrado ser sólido y efectivo.

• Última versión

La última versión estable del framework, que es sobre la que se ha hecho la comparación

• Curva de aprendizaje

La curva de aprendizaje es una gráfica en la que en el eje de abcisas y la producción en el eje de ordenadas y da una idea del tiempo que lleva a los usuarios ser capaces de desarrollar bajo el framework evaluado.

• Documentación

Indicaremos la cantidad y calidad de documentación existente, ya sea oficial o no.

Los frameworks que se van a evaluar son:

Este y los siguientes artículos son fruto del trabajo personal y podrían contener algún error, cualquier corrección será bienvenida.