Losing Connection

SPRINT 2

ACTIVIDADES

 Preparación del entorno de desarrollo.

 Implementación del sistema de autenticación de usuarios.  Creación del módulo de gestión de ejemplares.

 Implementación del protocolo 2PC para la persistencia en los motores de las bases de datos.

 Desarrollo de la funcionalidad de registro, seguimiento de ejemplares y pedigrí.

ENTREGABLES

 Diagrama de secuencia de la funcionalidad de creación de ejemplar.

 Prototipo con la funcionalidad de autenticación en funcionamiento.

 Prototipo con la funcionalidad de gestión de ejemplares y pedigrí funcionando.

 Mapa de navegación actualizado.  Código documentado (Javadoc).

DURACIÓN 3 semanas

3.3.1 Preparación del entorno de desarrollo.

Para el desarrollo del proyecto uno de los primeros pasos fue la configuración del entorno, que consistió en la instalación de las herramientas y dependencias en sus versiones más estables disponibles en el mercado las cuales se detallan en la tabla 3:

Herramienta Versión Descripción

IDE

Netbeans 8.2 X, con compatibilidad para desarrollo de aplicaciones en Entorno de desarrollo para sistemas Windows, Linux y OS múltiples lenguajes, entre ellos el empleado para este proyecto java y JSF. También cuenta con compatibilidad con servidores Glassfish para el despliegue de aplicaciones web JSF desde el entorno de desarrollo.

BitBucket Herramienta en la nube para administración de códigos colaborativo. Ofrece control de versiones, trabajo colaborativo e integración con NetBeans.

Postgres 9.4.10 Sistema gestor de base de datos diseñado para almacenar y manipular datos en una estructura relacional.

Herramienta Versión Descripción

Neo4j 3.1.2 Sistema gestor de Base de datos diseñado para almacenar y manipular datos en una estructura de grafos.

Maven 2 Herramienta de administración de proyectos java, permite gestionar las diferentes dependencias de librerías usadas por la aplicación JSF para su compilación.

Log4j 1.2.17 Librería para la gestión de mensajes de registros (logs) en la aplicación.

Primefaces

(JSF 2.2) 6.0 versión 2.2. Incluye el conjunto de APIs para la construcción Es la implementación de la tecnología JavaServer Faces ágil de interfaces de usuario del lado del servidor, validación y transferencia de datos en la capa de presentación, gestión de la comunicación por HTTP entre el cliente y el servidor. Se puede acceder a estos APIs a través del repositorio Maven. Glassfish 4.1.1 Servidor de aplicaciones de código abierto para

aplicaciones web java. Posee soporte para el funcionamiento de los componentes tales como JavaServer Faces (JSF), JavaServer Pages (JSP), Servlets, Beans, entre otros.

Hibernate 4.3.1 Framework de persistencia, implementación de JPA (Java Persistence Api) utilizado para hacer el mapeo objeto relacional de la información almacenada en la base de datos Postgres. También es el en cargado de gestionar la interacción entre la aplicación web y la base de datos.

Neo4j-ogm-

core 2.1.2 interactuar con base de datos orientada a grafos Neo4j. A Librería de Java para el mapeo de objeto-grafo para través de POJOS con anotaciones de la librería se pueden mapear nodos, relaciones y propiedades de un grafo para ser usadas por la aplicación. Se puede acceder a la librería a través del repositorio de Maven.

Neo4j-ogm-

http-driver 2.1.2 con el fin de realizar una comunicación con la base datos Librerías de java utilizadas por la librería Neo4j-ogm-core Neo4j a través del protocolo http.

3.3.2 Implementación del sistema de autenticación de usuarios.

Se incluyó en el prototipo el sistema de autenticación de usuarios para evitar que usuarios no autorizados realizaran operaciones sobre la aplicación, tal como lo indicaba la historia de usuario HU_GL_01, básicamente el prototipo cuenta con dos roles y su única distinción es la capacidad de crear otros usuarios, funcionalidad delegada exclusivamente al usuario administrador.

3.3.3 Creación del módulo de gestión de ejemplares

Dentro del primer Sprint de desarrollo del prototipo se creó la funcionalidad de gestión de ejemplares, la cual constituye la base para la posterior creación de los siguientes módulos. Esta funcionalidad tuvo la particularidad de que exige la interacción con los diferentes modelos de bases de datos en las operaciones CRUD, para ello se vio la necesidad de utilizar una técnica utilizada principalmente en bases de datos distribuidas conocido como Two Phase Commit o protocolo de dos fases (Philip y Newcomer, 2009), el cual busca dar tratamiento adecuado a este tipo de operaciones; adicionalmente se creó un mecanismo de compensación al final de la segunda fase para evitar inconsistencias en las bases de datos.

3.3.3.1 Implementación del protocolo 2PC

El protocolo 2PC (Two Phase Commit) se implementó haciendo uso de un objeto que coordina la transacción sobre los participantes en las operaciones realizadas sobre la base de datos. En el anexo 2 se puede observar el diagrama de secuencia que muestra su funcionamiento.

Se encontró la necesidad de usar del protocolo en la inserción y actualización de los ejemplares; su ejecución inicia desde el Managed Bean del ejemplar al momento de invocar alguna de estas dos operaciones y se implementó como se muestra a continuación:

Fase 1: Preparación

Desde el Managed Bean del ejemplar se crea el objeto coordinador ejemplificando la clase TransaccionGlobal a través de la cual se ejecuta el método guardarEjemplar enviando como parámetros los ejemplares que serán almacenados en las bases de datos Neo4j y Postgres. Inicialmente se obtienen las sesiones a través de las cuales se utilizarán los métodos de persistencia, la fase 1 consta de dos pasos que se muestran a continuación.

Paso 1: Se inicia la transacción para la base de datos de Postgres, si se trata de la creación de un ejemplar se ejecutará el método de guardar, en caso contrario se actualizará el objeto existente con las modificaciones realizadas.

 En caso de fallar esta fase de preparación de la transacción se llamará la funcionalidad rollback por medio de la sesión de Hibernate.

 Si no se genera ningún error en la preparación se procede con el paso 2.

Paso 2: Se inicia la transacción por medio de la sesión de Neo4j, si se trata de la creación de un ejemplar se le asignará el id generado por Postgres, posteriormente se guarda en la base de datos orientada a grafos.

 En caso de fallar la preparación, el coordinador enviará los mensajes de rollback a las sesiones de Postgres y Neo4j.

 Si no se genera ningún error se da por finalizada la fase 1 y se continua con la 2.

Fase 2: Confirmación

La fase 2 inicia evaluando el estado de la preparación de las transacciones, verificando si se encuentra activo para Postgres y abierto para Neo4j. En caso de que no se encuentren en un estado válido se finalizará la segunda fase sin hacer commit en ninguna de las bases de datos, de otra manera se continúa el proceso. La fase 2 consta de 2 pasos los cuales se muestran a continuación.

Paso 3: Se realiza el commit de la transacción de Postgres a través de la sesión de Hibernate en la base de datos relacional.

 En caso fallar este primer commit, se llama la operación rollback sobre la sesión de la base de datos orientada a grafos y se finaliza la ejecución del protocolo.

 En caso de obtener éxito se continúa con el paso 4.

Paso 4: Se realiza el commit de la transacción de Neo4j a través de la sesión del OGM.  En caso de que la operación se ejecute exitosamente, el coordinador da por finalizado el protocolo y se muestra el mensaje de que la creación o modificación del ejemplar se ha efectuado.

 Si llega a fallar la segunda fase del protocolo, el coordinador ejecutará un mecanismo de compensación que borra el ejemplar de la base de datos de Postgres para evitar inconsistencias.

El mecanismo de compensación únicamente soluciona inconsistencias relacionadas con la creación del ejemplar, en caso de actualización se debe recurrir a métodos heurísticos para recuperar la consistencia en la base de datos debido a que Hibernate evita que en una misma sesión existan dos elementos con el mismo identificador, por lo tanto, no es posible realizar una copia del estado del objeto antes de la actualización para su posterior restauración, en este caso, la aplicación mostrará un mensaje informando sobre el error presentado.

3.3.4 Desarrollo de la funcionalidad de registro, seguimiento de ejemplares y pedigrí.

Para la implementación del seguimiento del pedigrí del ejemplar se vio la necesidad de utilizar ambos motores de bases de datos. Los registros de información general del ejemplar y el manejo del árbol genealógico se implementaron utilizando el motor de base de datos orientada a grafos Neo4j; el carnet de vacunación que se debe adjuntar al ejemplar se almacenó en la base de datos relacional debido a que de manera nativa puede almacenar este registro ya que soporta un tipo de dato para el almacenamiento del fichero.

3.3.5 Reuniones por Sprint y retrospección

En el Sprint 2 se alcanzaron a hacer dos reuniones del equipo Scrum, en la primera de ellas se determinó como debería ser la configuración del entorno de desarrollo, se revisó la documentación relacionada con bases de datos distribuidas y se decidió utilizar el protocolo Two Phase Commit al tratarse de una transacción distribuida a través de dos modelos (relacional y orientado a grafos).

En la segunda reunión se revisaron los artefactos producidos durante el desarrollo del

Sprint, se acordó implementar un mecanismo de compensación adicional al protocolo para eludir inconsistencias en la base de datos en caso de presentarse un error. Finalmente se encontró que las funcionalidades asignadas para este Sprint cumplían con los criterios de aceptación de la historia de usuario y que con el estado del prototipo el usuario estaría en capacidad de iniciar sesión y alimentar la aplicación con ejemplares con su respectivo pedigrí. En la figura 14 se muestra el mapa de navegación de la aplicación con las funcionalidades implementadas en el Sprint 2.