blog de ezamudio

Escribo esto porque hace poco hice unas pruebas para comparar el performance de SLF4J contra Jakarta Commons Logging.

Llevaba ya tiempo usando JCL, un framework para logging que tiene la ventaja de ser una capa de abstracción sobre otros frameworks; es decir, se puede programar usando el API de JCL y en deployment se utiliza Log4J por ejemplo para hacer realmente el trabajo de los logs, o bien usar java.util.logging sin tener que cambiar una sola línea de código (JCL auto-detecta Log4J y si no está, se usa java.util.logging). Se pueden hacer interfaces para usar otros frameworks de logging.

SLF4J (Simple Logging Framework for Java) es muy similar: es simplemente una API que en tiempo de ejecución se apoya en algún framework de logging como Log4J, java.util.logging, etc. Su arquitectura interna es distinta en la manera que usa el framework real para logging: debe tenerse en el classpath el JAR que define el API junto con una sola implementación de backend, por ejemplo para Log4J.

Una parte importante de cualquier aplicación web seria, es la manera en que se almacenan variables de sesión. Por ejemplo, una aplicación que requiere login y se crea una sesión para el usuario; se requiere validar el usuario/password y cuando es un usuario válido, guardar sus datos en la sesión y las páginas que solamente son para usuarios válidos necesitan redirigir al usuario al login para que solamente usuarios registrados puedan ver la página.

Otro ejemplo es un simple blog como éste, en el que solamente los usuarios registrados pueden dejar comentarios. Vamos ver este ejemplo. Primero, supongamos que ya tenemos la página que muestra el blog y los comentarios, y tenemos un componente para dejar un nuevo comentario pero solamente a los usuarios ya registrados.

Al principio de esta serie, mencioné que Tapestry trae su propio manejador para inyección de dependencias. Sin embargo, muchos de nosotros ya estamos familiarizados con Spring, y en el caso de integración adicional con Hibernate y cosas así, ya tenemos configuraciones algo complejas en un ApplicationContext y queremos conservarlas. Así que es importante poder usar Spring con Tapestry.

Pues bien, es muy sencillo. Primero que nada, integramos la parte de Spring como en cualquier aplicación web. Suponiendo que tenemos un solo archivo de configuración spring.xml dentro de WEB-INF:

Continuando con la cátedra de Tapestry 5, vamos a ver ahora tres cosas sencillas pero bastante ilustrativas del poder de este framework: cómo funcionan los componentes (unidades funcionales que pueden ir contenidas en páginas o dentro de otros componentes); inyección de objetos en páginas y componentes, y cómo internacionalizar una página o componente.

Los componentes son fragmentos de páginas que van dentro de otros componentes o dentro de páginas. Un ejemplo muy típico es este: queremos dar a nuestro sitio una apariencia uniforme, con hojas de estilos, una serie de ligas en la parte superior, algunos datos de copyright y demás en la parte inferior, etc. Todas las páginas deben salir igual. Esto en Tapestry se resuelve muy fácil con un solo componente que podemos llamar Marco, que además va a tener la peculiaridad de que va a envolver a su componente o página padre:

Pues bien, después de un largo recorrido histórico por el nacimiento de las herramientas para desarrollo de aplicaciones web, finalmente aquí pongo una introducción a mi framework favorito para web, Tapestry.

Cabe mencionar que voy a enfocarme solamente en la versión 5, que cambió radicalmente de la 3 y la 4. Reescribieron el framework por completo y se perdió toda compatibilidad con versiones anteriores, lo cual puede ser muy problemático para quienes tengan desarrollos en producción en esas versiones, pero para comenzar aplicaciones nuevas, hay muchísimas ventajas. No voy a mencionar las diferencias con versiones anteriores, solamente detallaré las características de esta nueva versión.

Este es un primer intento de explicar las diferencias entre Tapestry y JSP. De hecho no solamente con JSP sino con los otros frameworks que son basados en el esquema de JSP. Esta vez voy a empezar con algo de historia, para ponernos en contexto de por qué Tapestry funciona como funciona (aunque tal vez no llegue a esa parte en este post).

En tiempos inmemoriales, a mediados de los 90's, cuando empiezan a popularizarse los web servers, solamente sirven contenido estático. Los primeros contenidos dinámicos fueron por medio de programas llamados CGI's, Common Gateway Interface, que consistía en que el web server le pasaba la URL y datos de la petición HTTP a un programa en UNIX, que lo leía del STDIN, y podía imprimir a STDOUT cualquier salida; ésta era devuelva por el web server al navegador. Esto es muy ineficiente porque cada petición ejecuta un programa y un programa medio complejo puede tardar bastante en ejecutarse, utilizar recursos, etc (por ejemplo cuando el CGI ya hacía conexiones a base de datos, etc).

Veo que no hay prácticamente nada información acerca de este tema en el sitio, así que decidí escribir esto esperando que a alguien le resulte útil.

Desde la versión 1.4 de Java apareció un paquete nuevo, java.nio, similar a java.io; esa n es de non-blocking. Los que hayan usado InputStream y OutputStream para leer por ejemplo de un socket, sabrán que los métodos de lectura y escritura bloquean el thread que los invoca, hasta que terminen su operación. Por lo tanto, en ambientes donde se tienen un alto volumen de intercambio de datos por medio de sockets, normalmente se tiene maneja una cola de mensajes que se deben enviar, junto con un thread dedicado a tomar mensajes de dicha cola y escribirlos al socket; y por otra parte se tiene un thread dedicado a leer del socket continuamente, poniendo en una cola los mensajes que van llegando (ojo: aquí cuando digo "mensajes" me refiero a tramas de datos que llegan por el socket que vienen delimitadas de alguna forma, pero aun sin parsear).

El tercer y último ejemplo que vimos en la plática de Seguridad en Aplicaciones Java, fue el de Cross-Site Scripting, conocido por su abreviatura como XSS.

Este ataque puede ser bastante complejo en cuanto al daño que se pueda hacer y los lugares por donde se puede realizar (vectores de ataque). Sin embargo, el fundamento es muy similar al de la inyección de SQL: usar datos que capturan los usuarios, sin validarlos apropiadamente.

La inyección de SQL permite que un usuario malicioso pueda enviar a una aplicación ciertos datos que incluyan sentencias de SQL que se ejecutarán en el servidor de base de datos. Los ataques de XSS usan ese mismo principio pero los datos que se envian, pueden incluir código HTML y/o Javascript; la principal diferencia es que dicho Javascript es inocuo en el servidor pero al ser incluido en páginas que se envían a otros usuarios, sus navegadores posiblemente ejecutarán dicho Javascript.

El siguiente ejemplo que hubo en la plática de seguridad en aplicaciones Java fue de inyección de SQL. Este ataque es posible cuando se capturan datos y se concatenan directamente dentro de una sentencia SQL, sin validarse; este método de hecho también es el fundamento de los ataques XSS (cross-site scripting).

En seguimiento a la plática del sábado (seguridad en aplicaciones Java), aquí están nuevamente los ejemplos que expuse ese día. Comencemos con el de DoS (Denial of Service: negación de servicio)

Este ataque se puede dar cuando tenemos un ServerSocket aceptando conexiones y manejando un protocolo propietario. En este caso el protocolo es muy simple y consiste simplemente en un mensaje de texto que primero lleva dos bytes de encabezado indicando su longitud (en binario). De modo que para recibir las conexiones tenemos el siguiente código: