Spring in Action Second Edition

Spring es un framework Java que trata de simplificar el desarrollo de aplicaciones Java basándose en la inyección de dependencias y la programación orientada a aspectos. En este libro, Craig Walls hace una explicación exhaustiva de Spring cubriendo todas las capas del desarrollo de una aplicación.

El libro consta de los siguientes capítulos:

1. Pasar a la acción: Se presenta Spring y los módulos que lo componen. Se introducen los conceptos principales de Spring, la inyección de dependencias y la programación orientada a aspectos.


2. Conexión básica de beans: Se presentan los distintos tipos de contenedores de beans, las fábricas de bean y los contextos de aplicación. A continuación se ve cómo crear beans en un contenedor y cómo inyectar valores y propiedades en ellos mediante inyección de dependencias. Después se muestra qué es la autoconexión de beans y, por último, se explica cómo controlar la creación de beans a través de métodos de inicio y destrucción del bean.


3. Conexión avanzada de beans: Se muestran conceptos avanzados del contenedor de beans de Spring. Primero se ve cómo declarar beans padre de los que otros beans hijos pueden heredar propiedades. Después se enseña la inyección de métodos. Luego se pasa a la inyección de beans que no han sido creados dentro del contenedor de Spring. También se ve cómo registrar editores de propiedades y cómo trabajar con beans especiales de Spring que se integran en el ciclo de vida de otros bean. Por último, se ve cómo crear beans con lenguajes dinámicos como Ruby, Groovy o Beanshell.


4. Notificaciones a beans: En primer lugar, se hace una introducción a la programación orientada a aspectos (AOP). Posteriormente se explica cómo crear aspectos clásicos de Spring y qué es el autoproxying. Después se ve la declaración de aspectos POJO y cómo se pueden inyectar aspectos creados con AspectJ.


5. Peticiones a la base de datos: Se examinan las capacidades de acceso a base de datos que ofrece Spring, y su fillosofía de acceso a datos a través de plantillas. Posteriormente se ve cómo se puede integrar Spring con JDBC puro o con ORMs como Hibernate, JPA o iBatis. Por último, se muestran las capacidades de cacheo en Spring.


6. Gestión de transacciones: Se revisa la gestión de transacciones en Spring, comenzando por una explicación de sus conceptos fundamentales. Después se enumeran los distintos gestores de transacciones disponibles y se explica cómo manejar las transacciones en Spring, tanto de forma programática como de forma declarativa


7. Seguridad en Spring: Se hace una introducción a la seguridad en Spring, que se implementa mediante la antigua librería Acegi Security. Posteriormente vamos viendo cómo se autentican los usuarios y se controla el acceso. Finalmente se ve cómo asegurar una aplicación web y cómo asegurar las invocaciones a métodos.


8. Servicios remotos basados en Spring y POJO: Se ve cómo implementar y consumir servicios remotos en Spring mediante RMI, Hessian, Burlap, Spring HttpInvoker y Web Services.


9. Construcción de servicios web contract-first en Spring: Comienza con una introducción a Spring-WS, un framework que permite construir servicios web a partir de un contrato definido en primer lugar. Después se ve cómo se manejan los mensajes de estos servicios mediante puntos finales de servicio y como juntar todo esto para la creación de un servicio. Para terminar, se ve cómo consumir servicios web usando Spring-WS.


10. Mensajería Spring: Se explica qué es JMS y cómo se puede usar desde Spring. Después se explica cómo construir POJOS dirigidos por mensajes y, por último, cómo utilizar RPC basado en mensajes, en contraposición a los servicios remotos vistos en el capítulo 8.


11. Spring y Enterprise Java Beans: Se muestra cómo conectarse a EJBs desde Spring. Después se ve cómo desarrollar EJBs que puedan aprovecharse de las capacidades de Spring. Por último, se ve cómo utilizar anotaciones EJB 3, a través del proyecto Pitchfork, para realizar inyección de dependencia y AOP en Spring.


12. Acceso a servicios empresariales: En este capítulo se estudia el uso en Spring de capacidades empresariales como JNDI, correo electrónico JMS, planificación de tareas y gestión de beans mediante JMX.


13. Manejo de peticiones Web: Se introduce el marco MVC de Spring para la capa web, en el que las peticiones son manejadas por controladores. Se ve cómo mapear las peticiones a los controladores de la aplicación y los distintos tipos de controladores que se pueden utilizar. También se ve cómo se manejan las excepciones que se pueden producir durante el procesamiento de estos controladores.


14. Mostrar vistas Web: Se ve cómo Spring MVC resuelve la vista que debe mostrar como respuesta a una petición. Se examinan las diferentes posibilidades, como JSP, con o sin Tiles, y otras alternativas a JSP, como Velocity y Freemarker. También se ve cómo es posible generar salida no-HTML, como documentos de Excel o PDFs.


15. Spring Web Flow: Se explica qué es Spring Web Flow, un marco de trabajo que permite definer el flujo de navegación de una aplicación. Se ve cómo se puede definir el flujo de la aplicación desde los conceptos básicos hasta técnicas más avanzadas. También se ve cómo se puede integrar Spring Web Flow con otros frameworks web como Struts o JSF.


16. Integración con otros marcos de trabajo Web: Se explica cómo se pueden utilizar las capacidades empresariales de Spring junto con otros conocidos frameworks web como Struts, WebWork/Struts2, Tapestry, JSF y aplicaciones Ajax con DWR.

Este libro es sencillo de leer y te va introduciendo paulatinamente dentro de Spring, explicando los conceptos principales y utilizando gran parte de sus funcionalidades. A mí me ha servido para aprender Spring desde cero, así como para entender la inyección de dependencias y la programación orientada a aspectos.

(ACTUALIZACION 26/10/2011: Ya está disponible la tercera versión de este libro, actualizada a Spring 3.)

Hibernate in Action Second Edition

Este libro, escrito por Christian Bauer y Gavin King, es una revisión de otro libro anterior, Hibernate in Action. Está actualizado a la versión 3 de Hibernate y, además, presenta el estándar de persistencia de de EJB 3.0 (JPA).

Se trata de un libro de referencia no sólo para Hibernate, sino también para JPA. En él se puede encontrar información de introducción a estas dos tecnologías ORM, enseña a realizar con éxito los mapeos de objetos a entidades relacionales, explica el funcionamiento interno de Hibernate y cómo optimizar su comportamiento y da pautas sobre cómo construir aplicaciones que hagan uso Hibernate y/o JPA.

Consta de los siguientes capítulos:

1. Comprender la persistencia objeto/relacional: Se hace una introducción a los problemas de la persistencia en aplicaciones orientadas a objetos que usan bases de datos relacionales, explicando los desajustes que se producen entre estas dos tecnologías. Se presentan las distintas alternativas existentes para la capa de persistencia y se presentan los ORM como la solución que nos permite abstraernos de los desajustes anteriormente mencionados.


2. Comenzar un proyecto: Se presentan las posibles alternativas de desarrollo con Hibernate, dependiendo de si empezamos desde un modelo de clases o desde un modelo relacional. A continuación se muestra la configuración de Hibernate en un proyecto y se implementa el mismo proyecto de distintas formas: usando Hibernate y mapeo XML, anotaciones, JPA mediante el Hibernate EntityManager y componentes EJB. Posteriormente se hace una introducción a la ingeniería inversa con Hibernate dada una base de datos. Por último, se presenta cómo se integra Hibernate con otros servicios de la plataforma JEE como JTA, JNDI y JMX.


3. Modelos de dominio y metadatos: Se presenta el modelo de dominio de ejemplo que se utilizará en el libro, un sistema de subastas. Se presentan las pautas para la implementación de este modelo, como el desarrollo de POJOs. A continuación se muestran las distintas alternativas para los metadatos de mapeo, XML, anotaciones, XDoclet y de forma programática en la ejecución. Por último se presentan representaciones alternativas de las entidades mediante mapas y XML.


4. Mapear clases persistentes: Se explica la diferencia entre las entidades y los tipos de valor. También se ve el concepto de identidad en Hibernate. Después se ven algunas opciones para el mapeo de clases. Por último, se ve como mapear tipos de valor, tanto para tipos de datos Java como para clases.


5. Herencia y tipos personalizados: Se muestran las distintas formas de manejar la herencia en Hibernate. También se ve el conjunto de tipos de datos que ofrece Hibernate y explica como crear tipos de datos personalizados.


6. Mapear colecciones y asociaciones de entidades: Se presentan los distintos tipos de colecciones que maneja Hibernate y se muestra cómo mapear colecciones de tipos de valor tanto en el caso de tipos simples como de clases. Posteriormente se ve cómo mapear una relación padre/hijo entre entidades.


7. Mapeo avanzado de asociaciones de entidades: Se continúa viendo cómo mapear relaciones entre entidades, tanto relaciones simples como múltiples. También se ven las asociaciones polimórficas entre entidades.


8. Bases de datos heredadas y SQL personalizado: Se comentan los principales problemas en la integración con bases de datos heredadas. Después se estudia la personalización del SQL que genera Hibernate en las consultas, y se ve la integración de procedimientos almacenados y funciones. Por último, se muestra cómo mejorar el DDL generado por Hibernate para personalizar los nombres y los tipos de datos, añadir restricciones o crear índices.


9. Trabajar con objetos: En este capítulo se comienza exponiendo el ciclo de vida de los objetos persistentes y después se habla de los conceptos de identidad e igualdad de objetos, introduciendo las conversaciones y el ámbito de identidad de un objeto. A continuación se ven los interfaces de persistencia de Hibernate y de JPA, terminando con una explicación de cómo usar JPA en componentes EJB.


10. Transacciones y concurrencia: Se revisan los conceptos básicos de las transacciones en las bases de datos y cómo pueden ser manejadas en Hibernate y JPA. También se trata el control del acceso concurrente en las bases de datos, revisando el control optimista de la concurrencia y cómo se pueden obtener garantías adicionales en el aislamiento. Por último, se estudia el acceso no transaccional, viendo en qué casos se puede trabajar en modo autocommit tanto con Hibernate como con JPA.


11. Implementando conversaciones: Se comienza viendo cómo se propaga la sesión en Hibernate, que puede ser a través de una variable thread-local, a través de JTA o mediante EJBs. Después se ve cómo se pueden implementar convesaciones en Hibernate, JPA y EJB a través de objetos “separados” (detached) y extendiendo la sesión.


12. Modificar objetos eficientemente: En primer lugar se estudia la persistenca transitiva de objetos a través de las asociaciones en cascada, tanto con Hibernate como con JPA. Posteriormente se pasa a ver cómo manejar operaciones que implican grandes volúmenes de datos a través de HQL y JPA QL y cómo procesar lotes. Por último, se ve cómo filtrar los datos de las consultas y cómo interceptar eventos en Hibernate.


13. Optimizar la recuperación y el cacheo: Comenzamos viendo cómo definir el plan de obtención de datos en Hibernate y se dan pautas de qué estrategia elegir y cóm optimizarla. Posteriormente se exponen los principios de cacheo en Hibernate y se explica cómo establecer una cache de segundo nivel a través de proveedores de cache.


14. Hacer consultas con HQL y JPA QL: Veremos cómo crear y ejecutar consultas a base de datos. Se aprenderá a crear consultas básicas con HQL y JPA QL y cómo se usan las joins, las consultas de informes y las subselects.


15. Opciones de consulta avanzadas: En este capítulo se ve cómo usar las APIs Criteria y Example para construir consultas de forma programática. También se ve cómo hacer consultas nativas en SQL. Después se ve cómo filtrar colecciones, y, por último, se habla del cacheo de resultados de consultas y en qué casos es conveniente hacerlo.


16. Crear y probar aplicaciones en capas: En este capítulo se dan pautas para el diseño de aplicaciones web con Hibernate, a través de patrones como OSIV (Open Session In View), Command y DAO (Data Access Object). También se trata el diseño de aplicaciones con EJB 3.0. Por último, se trata el tema de cómo probar estas aplicaciones y se presentan herramientas como TestNG y DBUnit.


17. Introducción a JBoss Seam: En este capítulo se hace un introducción al marco de trabajo JBoss Seam, un marco de trabajo orientado a Java EE 5.0 que se base en JSF y EJB 3.0. Se ve cómo mejorar una aplicación usando este marco, cómo utilizar componentes contextuales, cómo validar los datos de entrada y cómo simplificar la persistencia.

Se trata de un libro difícil de leer de corrido por la complejidad de los temas que trata. Sin embargo, creo que es un libro de referencia excelente sobre Hibernate y JPA.

Control de versiones con ClearCase

Rational ClearCase es el sistema de control de versiones de IBM. Aunque Subversion es más de mi agrado por su sencillez, esta herramienta es la que utilizo en el trabajo. Estamos teniendo un montón de problemas trabajando con ella, aunque estoy convencido que es más por desconocimiento que por la herramienta en sí. Así que voy a exponer a continuación que es ClearCase, cómo lo usamos y qué problemas estamos encontrando de cara a compartir experiencias con otros usuarios de ClearCase.

Cómo otros sistemas de control de versiones, ClearCase almacena distintas versiones de los elementos que forman parte de un proyecto, que pueden ser directorios o archivos. Estos elementos se almacenan en un repositorio que en ClearCase se llama base de objetos de versionado (VOB).

ClearCase proporciona un proceso de gestión de la configuración llamado gestión del cambio unificado (UCM). UCM se situa sobre la base de ClearCase simplificando el trabajo.

En UCM un proyecto es un producto de un desarrollo de software que contiene información de configuración sobre el mismo. Un proyecto está formado por componentes, que constituyen las partes de un proyecto, como módules web o módulos JAR en un proyecto Java.

Las modificaciones que se llevan a cabo durante las tareas de desarrollo dentro de la ejecución de un proyecto se registran en actividades, que consisten en varias versiones de distintos elementos de un componente.

Un proyecto consta de un área de trabajo compartido y muchas áreas de trabajo privadas. Cada área de trabajo está formada por una corriente y una o varias vistas. Una corriente es un objeto de ClearCase que mantiene una lista de actividades y líneas base que determinan que versiones de elementos aparecen en la vista. Una vista es un árbol de directorio que muestra una única versión de cada archivo del proyecto.

Todo proyecto tiene un área de trabajo compartido que se maneja mediante una corriente y una vista de integración. Su función es registrar las líneas base del proyecto y recibir las nuevas versiones de los elementos compartidos del proyecto para su integración conjunta.

Cada línea base representa una versión de los elementos de un componente en un determinado momento del desarrollo. A lo largo del proyecto, el administrador crea y recomienda líneas base para reflejar hitos del proyecto.

Según UCM, los desarrolladores tienen un área de trabajo privada donde realizan sus cambios. Esta área de trabajo consta una de corriente de desarrollo que mantiene la lista de actividades del desarrollador y determina qué versiones de los elementos del proyecto aparecen en su vista de desarrollo.

Cuando los desarrolladores se unen a un proyecto incluyen en sus áreas de trabajo las versiones de los elementos del proyecto marcados en la línea base recomendada del proyecto. Éstos harán sus cambios dentro de actividades en su área de trabajo privada y, una vez finalizados y probados, harán entrega (deliver) de estas actividades a la corriente de integración, lo que podría llevar a tener que combinar elementos si otro desarrollador ha hecho modificaciones en los mismos elementos.

Periódicamente, los desarrolladores deben hacer rebase para actualizarse a las últimas líneas base recomendadas. Si las líneas base incluyen nuevas versiones de los elementos que se están modificando en la vista de desarrollo, la operación de rebase fusiona las dos versiones en una nueva versión dentro de la corriente de desarrollo.

Lo explicado hasta ahora es el proceso de gestión de la configuración que define UCM, que implica que cada desarrollador tiene su propio área de trabajo privada. Esto permite que los desarrolladores trabajen de forma paralela e independiente sin colisionar entre ellos a la hora de modificar los mismo elementos. Estos serán fusionados posteriormente en las operaciones de deliver y rebase.

Sin embargo, esto añade carga de gestión al desarrollo, porque para ver las últimas modificaciones de otro desarrollador es necesario que haya entregado sus actividades, se haya hecho una nueva línea base y los otros desarrolladores hagan un rebase.

Para aligerar esta carga, nosotros usamos una única área de desarrollo para todos los desarrolladores, que tienen vistas a ella. Todos los cambios que un desarrollador registra pueden ser vistos por los demás desarrolladores sin más que hacer un update de su vista, permitiendo que los nuevos cambios se publiquen de manera más inmediata.

Sin embargo, si todos los desarrolladores están desarrollando en vistas de la misma corriente, se pueden producir situaciones no deseadas:

Modificaciones concurrentes de los mismos archivos

• Un desarrollador desaA está modificando un archivo fich1, para lo cual lo ha reservado (check out).
• Otro desarrollador desaB también quiere modificar este archivo, y, si no quiere quedarse bloqueado en su trabajo, lo reserva (check out) después de que aparece un aviso de que el desarrollador desaA lo ha reservado previamente.
• El desarrollador desaA sube (check in) el archivo con sus modificaciones.
• El desarrollador desaB sube (check in) el archivo con sus modificaciones, pero en ese momento ClearCase le avisa de que en el repositorio hay una versión de este archivo posterior a aquella que reservó, por lo que debe fusionar las dos versiones (merge). Este merge puede ser automático o manual, a través de la herramienta de ClearCase para esto.
• Este problema, que con un solo archivo puede ser fácil de solucionar, se complica cuando se están modificando varios archivos que coinciden por parte de varios desarrolladores. Se puede llegar a situaciones de bloqueo, por ejemplo, si un desarrollador no puede actualizarse un archivo que ha modificado otro desarrollador y es necesario para que los cambios en otros archivos compilen sin error porque el archivo necesario está reservado y siendo modificado por el desarrollador. Se puede llegar a situaciones difíciles de salir.

Dependencia entre actividades no relacionadas

• Un desarrollador desaA está realizando modificaciones dentro de una actividad activA que implican a los ficheros fich1, fich2 y fich3.
• Comienza reservando (check out) fich1, haciendo los cambios pertinentes y subiéndolo (check in) al repositorio, y después pasa a reservar fich2 y modificarlo.
• En ese momento, otro desarrollador desaB realiza otras modificaciones distintas dentro de otra actividad activB que implican modificar el fichero fich2, previamente modificado en la actividad activA de desaA.
• Por necesidades del proyecto, hace falta crear una nueva versión (línea base) del proyecto sólo con la modificación realizada en la actividad activB y no las modificaciones de activA. Por ejemplo, porque activB es una corrección de un bug que queremos solucionar rapidamente en producción, pero activA es un nuevo desarrollo que no queremos subir hasta no haberlo probado concienzudamente.
• Al tratar de subir la actividad activB, ClearCase nos dirá que esta actividad depende de la actividad activA y que también hay que subirla. Esto es debido a que la modificación del fichero fich2 se hizo sobre la versión modificada en la actividad activA.
• Resultado, no se puede subir activB de forma independiente de activA. Y este problema se puede complicar exponencialmente a mayor número de desarrolladores.

Conclusión, hay que evitar que varios desarrolladores modifiquen los mismo archivos por el bien de la productividad del equipo y de la facilidad en la gestión del proyecto. Lo cual me hace pensar que lo mejor sería un área de desarrollo privada por cada desarrollador como dicta UCM, pero esta forma de trabajar, que también usamos en otro proyecto aumentaría el número de merges de forma considerable con el riego que conllevan.

Aquí os pido colaboración. ¿Alguien tiene experiencia con ClearCase? Me gustaría saber qué estrategias se están usando en otros proyectos y cómo solucionan todos estos problemas.

Referencias:
Introducción a Rational ClearCase LT (Rosa María Carretero López)
ClearCase en Wikipedia
Comparación de software de control de versiones

Manifiesto en defensa de los derecho fundamentales en Internet

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.

10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.