FACULTAD DE INFORMÁTICA DEPARTAMENTO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES

FACULTAD DE INFORMÁTICA DEPARTAMENTO DE TECNOLOGÍAS DE LA INFORMACIÓN Y LAS COMUNICACIONES PROYECTO DE FIN DE CARRERA DE INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos Autor: Dña. Sandra Vázquez Abrodos Tutor: D. Antonino Santos del Riego A Coruña, 15 de Septiembre de 2005

D. ANTONINO SANTOS DEL RIEGO, Profesor titular de la Universidade da Coruña. HACE CONSTAR QUE: La memoria titulada Diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos ha sido realizada por Dña. SANDRA VÁZQUEZ ABRODOS, bajo mi dirección, en el Departamento de Tecnologías de la Información y las Comunicaciones de la Universidade da Coruña, constituyendo su proyecto clásico de ingeniería que presenta para optar al Grado de INGENIERO TÉCNICO en Informática de la UDC en la convocatoria de Septiembre del 2005. A Coruña, 15 de Septiembre de 2005 Fdo. Prof. D. Antonino Santos del Riego

Agradecimientos A mi familia, sin la que nada de esto habría sido posible. A Nino, por la atención y dedicación con la que ha dirigido el proyecto. A mi pareja, Javier, y a todos los seres humanos que hacen de su vida una entrega generosa al otro. A todos, gracias!. - 3 -

Resumen El presente proyecto se centra en el ámbito del espeleosocorro. Su objetivo es el diseño e implementación de un sistema gestor de espeleosocorro para rescates en entornos subterráneos. Dicho sistema gestor de rescates permitirá coordinar y documentar de un modo eficaz las distintas intervenciones que se puedan llevar a cabo en el campo del espeleosocorro. Para poder realizar todo esto, el sistema resultante permitirá gestionar una base de datos del dominio a través de una arquitectura cliente/servidor sobre los protocolos TCP/IP. Palabras Clave Java, Web, J2EE, Servlets, JSP, JavaBeans, HTML, XML, Tomcat, MVC, UML, MySQL, Hibernate - 4 -

Índice 1. Introducción... 8 2. Dominio de la aplicación... 11 3. Estado del Arte...13 4. Tecnologías y herramientas seleccionadas... 15 4.1 La plataforma Java... 15 4.1.1 El lenguaje Java... 15 4.1.2 El entorno de desarrollo Java... 16 4.1.3 El compilador de Java... 17 4.1.4 La Java Virtual Machine... 17 4.2 Tecnología J2EE... 18 4.2.1 J2EE vs. NET... 18 4.2.2 Ventajas de J2EE... 20 4.2.3 Arquitectura J2EE multicapa... 22 4.2.4 Servlets... 23 4.2.4.1 Ventajas de los Servlets... 24 4.2.4.2 Arquitectura básica de los Servlets... 26 4.2.4.3 El ciclo de vida de un Servlet... 27 4.2.5 JavaServer Pages (JSP)... 29 4.2.5.1 JSPs vs. Servlets... 30 4.2.5.2 Arquitectura básica de las JSP... 30 4.2.6 JavaBeans... 32 4.3 Lenguaje de marcado de hipertexto (HTML)... 33 4.4 extensible Markup Language (XML)... 34 4.5 Apache/Tomcat... 35 4.6 Hibernate... 36 4.7 MySQL... 40 4.8 NetBeans IDE... 42 5 Modelo Vista Controlador (MVC)... 44 5.1 Modelos de diseño: Modelo 1, Modelo 2 y Modelo 2X... 46 6 Modelado... 50 6.1 UML - Lenguaje Unificado de Modelado... 50 6.2 Análisis de requisitos... 51 6.2.1 Actores del sistema... 51 6.2.2 Casos de uso... 52 6.3 Diseño del sistema... 55 6.3.1 Arquitectura general... 55 6.3.2 Diseño de la aplicación servidora... 57 6.3.2.1 Seguimiento de las sesiones... 57 6.3.2.2 Control de acceso a los recursos... 58 6.3.2.3 Lectura de datos del cliente... 59 6.3.2.4 Lógica funcional... 60 6.3.2.5 El Gestor de Flujo... 61 6.3.2.6 Procesamiento de peticiones en el servidor... 62-5 -

6.3.2.7 Arquitectura de paquetes del sistema... 64 6.3.3 Diseño de la base de datos... 69 6.3.6 Interfaz gráfica... 80 7 Conclusiones y desarrollos futuros... 103 Bibliografía... 105 Enlaces electrónicos... 107-6 -

Índice de ilustraciones Figura 1. Procesamiento de una petición... 24 Figura 2. Ciclo de vida de un servlet... 29 Figura 3. Páginas JSP... 30 Figura 4. Creación de una JSP... 31 Figura 5. Ciclo de vida de una JSP... 32 Figura 6. Fichero de mapeado para Hibernate... 39 Figura 7. Arquitectura del Modelo 1... 47 Figura 8. Arquitectura de Modelo 2... 49 Figura 9. Actores del sistema... 51 Figura 10. Casos de uso para todos los usuarios... 53 Figura 11. Casos de uso para el administrador... 54 Figura 12. Arquitectura del sistema... 56 Figura 13. Procesamiento de peticiones en el servidor... 63 Figura 14. Diagrama de paquetes... 65 Figura 15. Esquema E/R extendido... 71 Figura 16. Esquema relacional completo de la base de datos... 79 Figura 17. Pantalla de autenticación... 80 Figura 18. Pantalla de inicio del administrador... 81 Figura 19. Pantalla de inicio de los usuarios... 82 Figura 20. Creación de un usuario... 83 Figura 21. Listado del personal... 84 Figura 22. Creación de un nuevo material... 85 Figura 23. Listado de los materiales... 86 Figura 24. Creación de un equipo... 87 Figura 25. Listado de los equipos... 88 Figura 26. Listado de los roles... 89 Figura 27. Asociación de roles... 90 Figura 28. Listado de los nidos... 91 Figura 29. Listado de la bibliografía... 92 Figura 30. Creación de una intervención... 93 Figura 31. Listado de las intervenciones... 95 Figura 32. Asociación de bibliografía... 96 Figura 33. Asociación de personal... 97 Figura 34. Asociación de materiales... 99 Figura 35. Selección de una intervención para generar su informe... 100 Figura 36. Informe generado... 101 Figura 37. Cierre de una intervención... 102-7 -

1. Introducción Los importantes avances tecnológicos que han tenido lugar en los últimos años y las mejoras en las comunicaciones globales han hecho de la sociedad de la información una realidad que nos brinda nuevas facilidades de comunicación y gestión. Dichas facilidades no deben ser ignoradas en aquellas actividades en las que una comunicación fluida y una coordinación precisa pueden salvar vidas humanas. Sin duda alguna el ámbito del espeleosocorro es uno de estos campos donde la coordinación y organización entre los equipos participantes es de vital importancia. Comunicaciones en tiempo real y una gestión distribuida de materiales reducirían los tiempos de actuación incrementando significativamente las posibilidades de rescatar con vida a los accidentados. En la actualidad los grupos de espeleosocorro se encuentran con importantes carencias a la hora de planificar un rescate. Destacando la inexistencia de un acceso a información actualizada y unos métodos de trabajo poco flexibles que retrasan considerablemente la organización de las operaciones. La utilización de un sistema gestor potente y flexible agilizaría los rescates y disminuiría la complejidad de planificar una operación, ya que haría innecesaria una recopilación de datos permitiendo llevar a cabo una correcta localización del personal y materiales disponibles. Además, la emisión automatizada e instantánea de informes es sin duda otra de las importantes ventajas del sistema. Para la realización de dicho sistema gestor se llevará a la práctica una solución basada en el Web que permita aprovechar las posibilidades ofertadas por una red global de bajo coste como es la red Internet. Dicha solución se desarrollará utilizando la arquitectura Java 2 Enterprise Edition (J2EE) y el denominado Modelo-Vista-Controlador (MVC). - 8 -

Es por tanto objetivo de este proyecto realizar un sistema gestor con el cual se puedan coordinar y documentar las intervenciones de espeleosocorro de un modo eficiente, rápido y automatizado. El presente documento se encuentra organizado en nueve apartados. En el apartado actual, Introducción, se presenta brevemente la actividad del espeleosocorro explicando su situación social, limitaciones y carencias así como la necesidad de un sistema gestor que palie las necesidades existentes. El apartado dos, Dominio de la aplicación, describe el entorno de la aplicación. En el apartado tres, Estado del Arte, se exponen las soluciones que existen en la actualidad para el problema que tratamos de resolver. En el apartado cuatro, Tecnologías y Herramientas Seleccionadas, se describen las tecnologías y herramientas empleadas para el desarrollo del proyecto y se justifica su elección. El apartado cinco, Modelo Vista Controlador (MVC), se describe y justifica la arquitectura software MVC que se utilizará en la implementación del presente proyecto. En el apartado seis, Modelado, se proporciona un análisis de los requisitos en el cual se muestran los casos de uso que permiten apreciar la utilidad de la aplicación. Además, se detalla todo el diseño y la arquitectura del sistema describiendo los distintos componentes y la forma en que se interrelacionan. Al final del apartado se muestra el proyecto en funcionamiento mediante un paseo por la aplicación. El apartado siete, Conclusiones, expone las conclusiones alcanzadas tras la realización del proyecto y la evaluación del mismo. - 9 -

Finalmente, en los apartados ocho y nueve, Bibliografía y Enlaces electrónicos respectivamente, se muestra toda la bibliografía y los enlaces electrónicos utilizados durante la realización del presente proyecto. - 10 -

2. Dominio de la aplicación El fin de la espeleología es la exploración de las cuevas y el estudio de las mismas. Como actividad científica, atrae la atención de geólogos, biólogos, arqueólogos y muchos otros que ven en las cavidades subterráneas un entorno adecuado para la investigación pero, además, es una actividad considerada de alto riesgo que requiere de una cierta preparación técnica que permita maximizar los niveles de seguridad. Para garantizar los rescates en esta actividad existe una disciplina técnica que se conoce como espeleosocorro [FEDE98], la cual tiene como objetivo propiciar los métodos y medios necesarios para tal tipo de intervenciones. Una disciplina que puede reducir el número de rescates es el autosocorro, siendo de gran interés la formación del espeleólogo en dichas técnicas. El autosocorro comprende las acciones que realiza un espeleólogo o grupo de espeleólogos para resolver un problema que se presenta durante la exploración de una cueva. Es el nivel básico del espeleosocorro y debe ser dominado por todo el que practica la espeleología. Este nivel comprende conocimientos de primeros auxilios, soporte vital básico, maniobras de desbloqueo y desobstrucción, supervivencia en condiciones de campaña, etc. que preparan al espeleólogo para afrontar la situación y dar una respuesta inicial limitada. En cuanto al socorro espeleológico o espeleosocorro debemos decir que es una especialidad que requiere de una mayor preparación y de todo un sistema organizativo que va a garantizar una respuesta oportuna y eficiente en caso de producirse un accidente. Para la realización del espeleosocorro es necesaria la participación de un equipo de personas que se conocen como espeleosocorristas y que son los que se entrenan en técnicas especiales de tratamiento, traslado y evacuación de un accidentado, para lo cual se requiere de un gran equipamiento de salvamento y rescate propio de, y para la espeleología. - 11 -

Los espeleólogos españoles se agrupan en la Federación Española de Espeleología que engloba a 15 federaciones territoriales, entre ellas la gallega, que comprenden más de 250 grupos y unos 5.000 federados. Estos grupos organizan cursos de varios niveles con la colaboración de las Escuelas de Espeleología que dependen de las Federaciones y mantienen equipos de rescate para casos de incidentes (retrasos, fatigas, pérdidas durante poco tiempo, lesiones leves, etc.) o accidentes (pérdida total, caídas con fracturas, pérdidas de conocimiento, etc.). Realizar rescates en un entorno subterráneo no es tarea fácil y el factor tiempo suele ser de vital importancia en muchos casos. De esto podemos concretar que es fundamental tener una buena base en cuanto a fundamentos de actuación, organización y planificación de un rescate. - 12 -

3. Estado del Arte Durante la fase de documentación del presente proyecto pudimos comprobar las líneas de desarrollo seguidas en los últimos años. En ellas se puede apreciar una intensa labor en la digitalización de los informes y de la documentación relativa a operaciones de rescate realizadas con anterioridad. Sin embargo, los métodos utilizados en la actualidad para dichas labores de digitalización carecen de un estándar, lo que a la hora de automatizar cualquier manipulación de la información supone dificultades que no pueden ser obviadas. Entre estas dificultades cabe destacar las siguientes: La inexistencia de una estructura, los datos habitualmente se encuentran almacenados sin usar ningún tipo de criterio formal. La escasa variedad de datos, sólo una pequeña parte de los datos de interés de un rescate llega a tratarse adecuadamente. Los sistemas de consulta son poco flexibles y proporcionan unas opciones de consulta muy limitadas. La realización de actualizaciones no es una tarea fácil, esto se debe principalmente a la ausencia de estructuras de datos. La disponibilidad de los datos es muy limitada, ya que la mayoría de los sistemas utilizados en la actualidad requieren disponer de una copia para su utilización. Creemos por tanto que el desarrollo de sistemas gestores y la innovación en los mismos no sólo cubren la necesidad de almacenar la información en un soporte digital flexible y - 13 -

automatizado sino que también añaden nuevas posibilidades de distribución y gestión que facilitan y estandarizan la inclusión del nuevo material digitalizado. - 14 -

4. Tecnologías y herramientas seleccionadas A lo largo de esta sección se expondrán las tecnologías y herramientas más importantes que se han utilizado en el desarrollo de este proyecto. De cada una de ellas se expondrán sus características, ventajas y desventajas, explicando las razones que nos han llevado a elegir esas tecnologías, y no otras, para la realización del presente proyecto. 4.1 La plataforma Java Java es una plataforma, desarrollada al comienzo de los años 90 con el objetivo concreto de permitir ejecutar programas sin tener relativamente en cuenta el hardware final. Consiste en tres grandes bloques, el lenguaje Java, una máquina virtual y un programa de aplicación de interfaz o API (Application Programming Interfaz). 4.1.1 El lenguaje Java A finales de 1995 se introdujo Java como lenguaje de programación para computadores. La clave fue la incorporación de un intérprete Java en la versión 2.0 del programa Netscape Navigator, produciendo una verdadera revolución en Internet. La compañía Sun describe el lenguaje Java [ALLE00] como simple, orientado a objetos, distribuido, interpretado, robusto, seguro, de arquitectura neutra, portable, de altas prestaciones, multitarea y dinámico. Además de una serie de halagos por parte de Sun hacia su propia criatura, el hecho es que todo ello describe bastante bien el lenguaje Java. Para el desarrollo del presente proyecto se ha optado por el lenguaje de programación Java así como por diversas tecnologías asociadas al mismo. Esta decisión se ha tomado en base a las características anteriormente mencionadas del lenguaje Java y a que cuenta con una amplísima colección de APIs a nuestra disposición. Al programar en Java no se - 15 -

parte de cero. Cualquier aplicación que se desarrolle cuelga (o se apoya, según como se quiera ver) de un gran número de clases preexistentes. Algunas de ellas las ha podido hacer el propio usuario y otras pueden ser comerciales, pero siempre hay un número muy importante de clases que forman parte del propio lenguaje. Otro de los motivos clave para declinarse por este lenguaje es la amplísima plataforma de desarrollo de aplicaciones que se encuentra detrás de Java. El equipo de desarrollo de Java agrupó las características de Java en tres ediciones [JAVA04], cada una de las cuales cuenta con un kit de desarrollo de software (Software Development Kit o SDK). J2SE (Java 2 Standard Edition): La Java2 edición estándar es la edición original de Java y consiste de las interfaces de programación de aplicaciones, APIs, necesarias para construir una aplicación o applet en Java. J2ME (Java 2 Mobile Edition): Es la edición móvil de Java 2. Contiene las API que se utilizan para crear aplicaciones Java inalámbricas o para dispositivos pequeños. J2EE (Java 2 Enterprise Edition): La Java 2 edición empresarial es una versión mejorada de la J2SE. Contiene las API necesarias para construir aplicaciones para arquitecturas multicapa. 4.1.2 El entorno de desarrollo Java Existen distintos programas comerciales que permiten desarrollar código Java. La compañía Sun, creadora de Java, distribuye gratuitamente el Java(tm) Development Kit (JDK). El JDK se trata de un conjunto de programas y librerías que permiten desarrollar, compilar y ejecutar programas en Java. Incorpora además la posibilidad de ejecutar - 16 -

parcialmente el programa, deteniendo la ejecución en el punto deseado y estudiando en cada momento el valor de cada una de las variables (con el denominado Debugger). 4.1.3 El compilador de Java Se trata de una de las herramientas incluidas en el JDK. Realiza un análisis de sintaxis del código escrito en los ficheros fuente de Java (con extensión *.java). Si no encuentra errores en el código genera los ficheros compilados (con extensión *.class). En otro caso muestra la línea o líneas erróneas. En el JDK de Sun dicho compilador se llama javac.exe. 4.1.4 La Java Virtual Machine La existencia de distintos tipos de procesadores y ordenadores llevó a los ingenieros de Sun a la conclusión de que era muy importante conseguir un software que no dependiera del tipo de procesador utilizado. Se planteó la necesidad de conseguir un código capaz de ejecutarse en cualquier tipo de máquina. Una vez compilado no debería ser necesaria ninguna modificación por el hecho de cambiar de procesador o de ejecutarlo en otra máquina. La clave consistió en desarrollar un código neutro el cual estuviera preparado para ser ejecutado sobre una máquina hipotética o virtual, denominada Java Virtual Machine o JVM. Es esta JVM quien interpreta este código neutro convirtiéndolo a código particular de la CPU utilizada. La JVM ejecuta los bytecodes (ficheros compilados con extensión *.class) creados por el compilador de Java (java.exe). De este modo se evita tener que realizar un programa diferente para cada CPU o plataforma. - 17 -

4.2 Tecnología J2EE A lo largo de los últimos años el desarrollo de aplicaciones Web ha sufrido un auge muy importante, la Web ha ido pasando de ser un mero contenedor de texto estático en forma de páginas HTML, a convertirse en un entorno dinámico, movido por diversas tecnologías que permiten y facilitan la creación de HTML en base a contenidos dinámicos provenientes de diversas fuentes como pueden ser las bases de datos. Las aplicaciones Web en Internet se están convirtiendo en un importante motor de la economía digital. Frente a esta nueva demanda surgen dos plataformas distintas para el desarrollo de este tipo de aplicaciones: J2EE de Sun y.net de Microsoft. 4.2.1 J2EE vs. NET J2EE y.net son los dos titanes que se enfrentan en el ring de los servidores para aplicaciones web. A lo largo de los últimos años se han vertido miles de líneas sobre la estrategia.net de Microsoft [MICR05] y su comparación con la plataforma J2EE [REJ05]. Para poder comparar y luego valorar cual de estas tecnologías es conveniente usar en el desarrollo del presente proyecto vamos a mostrar primero una panorámica general. J2EE: J2EE [KEOG02] se denomina plataforma porque proporciona especificaciones técnicas que describen el lenguaje pero, además, provee las herramientas para implementar aplicaciones. Veamos la definición que proporciona Sun de J2EE: J2EE define un estándar para el desarrollo de aplicaciones empresariales multicapa. J2EE simplifica las aplicaciones empresariales basándolos en componentes modulares y estandarizados, proveyendo un completo conjunto de - 18 -

servicios a estos componentes, y manejando muchas de las funciones de la aplicación de forma automática, sin necesidad de una programación compleja. Esquemáticamente se resumiría en la siguiente ecuación J2EE = Java + componentes adicionales orientados a empresas (JavaBeans, JSPs, etc.). La plataforma J2EE ha sido creada con la participación de cientos de empresas de diversa índole y es sin lugar a dudas una plataforma conjunta, no exclusiva de Sun o de ninguna otra compañía..net: Nació a principios de este siglo, producto de una serie de herramientas de software que Microsoft ya ofrecía a sus clientes, especialmente en lo que a servidores se refiere. Más que una plataforma, es un concepto creado por Microsoft para generar servicios a través de Internet, gracias a servidores de bases de datos que contienen la información. Según Steven B. Levy, redactor de Microsoft TechNet, ".NET es una plataforma llena de servicios para construir aplicaciones basadas en web y desarrollar experiencias interactivas para los usuarios y sus sistemas". La parte más importante de la plataforma.net es NET framework, una suite de herramientas que incluye COM+ (Component Object Model), un entorno de ejecución común, un compilador JIT (just-in-time) y un conjunto de librerías de sistema. Desde el punto de vista del programador, el entorno.net ofrece un solo entorno de desarrollo para todos los lenguajes que soporta (Visual Basic, C++, C#, Visual J#, Fortran, Cobol, etc.). Aunque entre J2EE y.net existen diferencias, ventajas y desventajas también existen similitudes. A continuación se muestran algunas características comunes. - 19 -

El propósito tanto de J2EE como de la plataforma.net es facilitar y simplificar el desarrollo de aplicaciones empresariales o corporativas. Los servidores de aplicaciones J2EE y.net proporcionan un modelo de acceso de componentes a datos y de lógica del negocio, separados por una capa intermedia de presentación implementada mediante ASP.NET (.NET) ó Servlets (J2EE). Visual Basic.NET y C# son lenguajes orientados a objetos, al igual que Java, y en su diseño ha tenido mucha importancia la existencia de Internet. Desde la perspectiva de los desarrolladores, J2EE y.net proporcionan las herramientas necesarias para crear sitios web. 4.2.2 Ventajas de J2EE Para explicar los motivos que nos han llevado a utilizar J2EE en la realización de este proyecto vamos a ver algunas de las ventajas que ofrece esta plataforma frente a.net. Aunque Java fue creado originalmente por una compañía, Sun MicroSystems, lo cierto es que J2EE es ahora el producto de la colaboración de un gran número de empresas y organizaciones de todo tipo (públicas, privadas sin ánimo de lucro, privadas con ánimo de lucro, y de normalización en ámbitos nacionales e internacionales). Este hecho permite la existencia de una cierta competencia que acarrea como resultado mejores productos. Esta competencia no existe en el caso de Microsoft y su.net. La plataforma.net es, y será, el producto de una sola compañía. - 20 -

Debido al proceso evolutivo de los productos de Microsoft y, en muchos casos, a motivos de compatibilidad, la seguridad frente a virus informáticos de los productos de Microsoft es menor que los basados en Java, pues desde un comienzo Java se fundamentó siempre en un estricto modelo de seguridad. Hasta el momento, la plataforma J2EE es la única plataforma que corre en múltiples sistemas operativos y múltiples máquinas hardware y cuyos usuarios pueden seleccionar la implementación que más le convenga. Además, no solo corre en computadores domésticos o servidores o estaciones de trabajo, sino también en multitud de dispositivos como teléfonos móviles, agendas, componentes electrónicos industriales de automatización, etc. Java ya ha hecho realidad el sueño de "escriba el código una vez, ejecútelo en cualquier parte". Hasta la fecha,.net corre solamente sobre sistemas operativos de Microsoft. La tecnología Java es una tecnología abierta (en el sentido de que el código de la plataforma completa puede ser obtenido, revisado y estudiado por cualquiera que esté interesado) y se basa en gran parte en estándares de organizaciones de normalización y estándares empresariales "de facto". Esto posibilita que los desarrolladores puedan conocer y entender completamente cómo hace las cosas Java y aprovecharlo para sus aplicaciones y, por otro lado, al basarse en estándares empresariales, simplifica la integración con productos de múltiples compañías. En contraposición, sólo el código fuente del Nuevo lenguaje C# de la plataforma.net ha sido abierto al público general (aunque Microsoft permite a determinadas compañías el acceso al código fuente de ciertas partes de.net). La tecnología Java goza ya de una veteranía en el mercado y J2EE ha probado su eficacia en muchos entornos y situaciones empresariales distintas. De hecho, J2EE llegó al mercado tres años antes que.net. - 21 -

4.2.3 Arquitectura J2EE multicapa J2EE posee una estructura estándar basada en tres capas: Capa de usuario: Representa lo que el usuario ve. Por ejemplo, las páginas HTML. Capa Intermedia. Es la que se utiliza en el negocio de una empresa y contiene la gestión de la aplicación, como es el caso de objetos Java que acceden a datos. Capa de datos: Representa la base de datos. Este tipo de estructuras permiten que exista cierta independencia entre la visualización, la gestión y la base de datos. Además, permite acceder a la información que interesa vía http. Por lo tanto, se envía la información a través de una página HTML (capa cliente), la cual es interpretada por la capa intermedia, que a su vez accede a la base de datos. La capa intermedia resuelve las peticiones del cliente mediante el servidor de aplicaciones J2EE. Como se dijo anteriormente, el único lenguaje que soporta J2EE es Java y por lo tanto es el que se usará en el desarrollo de todos los componentes. Existen sólo dos formas oficiales para acceder a la plataforma J2EE con otros lenguajes: a través de JNI (Java Native Interface) o mediante la interoperabilidad que ofrece CORBA. Un elemento fundamental en las aplicaciones web soportadas bajo Java son los denominados "patrones J2EE", que describen los típicos problemas encontrados por desarrolladores de aplicaciones empresariales y proveen soluciones para éstos. En esencia, estos patrones contienen las mejores soluciones para ayudar a los desarrolladores a diseñar y construir aplicaciones para la plataforma J2EE. - 22 -

Las características y usos de estos patrones para su implementación se pueden encontrar en la web de Sun. El diseño de aplicaciones Web basadas en los Patrones J2EE se organiza alrededor de la utilización de varios elementos: un controlador frontal, dispatchers (despachadores), vistas compuestas, vistas JSP y los helpers (ayudantes) de las vistas (JavaBeans). 4.2.4 Servlets Los servlets son programas o clases Java que se ejecutan en un servidor de aplicaciones web, por ejemplo Tomcat, y hacen de capa intermedia entre una petición proveniente de un navegador web u otro cliente HTTP, y las bases de datos o aplicaciones del servidor http. Es decir, los servlets contienen la lógica de negocio para procesar una petición. Por ejemplo, un servlet podría ser responsable de tomar los datos de un formulario en HTML y aplicarle la lógica de negocio utilizada para actualizar la base de datos. En la siguiente figura (véase Figura 1) se muestra el procesamiento de una petición. - 23 -

Figura 1. Procesamiento de una petición 4.2.4.1 Ventajas de los Servlets En el caso del presente proyecto se utilizan servlets porque estos tienen numerosas ventajas [HUNT98] sobre otras tecnologías como puede ser la Interfaz Común de Pasarela (Common Gateway Interface o CGI). A continuación se muestran los principales beneficios de utilizar servlets. Eficiencia: Con el CGI cada vez que se realiza una petición HTTP se inicia un nuevo proceso. El coste de arrancar este nuevo proceso puede llegar a superar el tiempo de ejecución del propio programa CGI y esto es inaceptable. Con los servlets, la JVM permanece en ejecución y administra cada petición mediante un - 24 -

ligero subproceso de Java. De forma similar, si hay n peticiones simultáneas al mismo programa CGI, el código del programa se carga la misma cantidad de veces en memoria. Sin embargo, con los servlets puede haber n procesos y sólo una copia del servlet en memoria. Finalmente, cuando un programa CGI termina de manejar la petición, el programa finaliza. Esto dificulta agilizar los procesos, mantener abiertas conexiones a la base de datos y realizar otras optimizaciones que se basan en datos persistentes. Por su parte, los servlets permanecen en memoria aún después de que han dado una respuesta, por lo que es fácil almacenar datos entre las peticiones. Adecuados: Los servlets cuentan con una extensa infraestructura para analizar y decodificar automáticamente los datos de los formularios HTML, leer y establecer encabezados HTTP, administrar cookies, rastrear sesiones y muchas otras utilidades. Poderosos: Los servlets pueden comunicarse directamente con el servidor web, mientras que los programas CGI no pueden hacerlo, para ello necesitan utilizar cierta API específica de los servidores. Además el hecho de que los servlets puedan mantener información de una petición a otra, simplifica el rastreo de sesiones. Transportables: Los servlets están escritos en el lenguaje de programación Java y siguen una API estándar. De este modo pueden utilizarse de manera directa en cualquier servidor web. Además ahora son parte de J2EE. Seguros: Una de las principales fuentes de vulnerabilidad en los programas CGI proviene del hecho de que por lo general son ejecutados por entornos de sistemas operativos de propósito general. Por ello, el programador de CGI debe tener cuidado de filtrar caracteres como las comillas y los puntos y coma porque tienen un tratamiento especial por el entorno. Una segunda fuente de problemas es el - 25 -

hecho de que ciertos programas CGI son procesados por lenguajes que no verifican automáticamente los límites de las matrices o cadenas. Por ello, los programadores que olvidan realizar esta verificación, abren sus propios sistemas a posibles ataques de desbordamiento de buffer. Los servlets no tienen estos problemas. Aun si un servlet ejecuta una llamada a un sistema distante para ejecutar un programa en el sistema operativo local, no utiliza el entorno del sistema operativo para lograrlo. Y por supuesto la verificación de los límites de las matrices y otras características para la protección de la memoria son una parte central de Java. 4.2.4.2 Arquitectura básica de los Servlets Un servlet es una clase Java que recibe peticiones que envía un cliente y envía información de vuelta al cliente como respuesta. Para que esta clase Java se convierta en servlet es necesario que extienda a la clase HttpServlet y que sustituya a lo métodos doget o dopost de dicha clase, dependiendo de si los datos son enviados por GET o por POST. El método doget se utiliza para interactuar con aquellas peticiones que se envían utilizando METHOD=GET. Las peticiones GET son el tipo usual de peticiones del navegador para las páginas Web. Un navegador Web genera una petición cuando el usuario teclea un URL en la línea de Dirección, sigue un vínculo desde una página Web o envía un formulario HTML que no especifica un METHOD. Los servlets también pueden manejar con facilidad peticiones POST, que se generan cuando alguien envía un formulario HTML que establece METHOD=POST. Ambos métodos, doget y dopost, toman un par de argumentos: un HttpServletRequest y un HttpServletResponse. - 26 -

HttpServletRequest: contiene métodos por los cuales puede encontrar información entrante como los nombres de los parámetros pasados por el cliente, encabezados de petición HTTP, y el nombre del host cliente que ha realizado la petición. HttpServletResponse: le permite especificar la información de salida como los códigos de estado de HTTP (200, 404, etc.), encabezados de respuesta (Content-Type, Set-Cookie, etcétera) y, lo más importante, le permite obtener un PrintWriter utilizado para enviar el contenido del documento de regreso al cliente. 4.2.4.3 El ciclo de vida de un Servlet Los servlets se ejecutan en el servidor HTTP como parte integrante del propio proceso del servidor. Por este motivo el servidor HTTP es el responsable de la inicialización, llamada y destrucción de cada objeto de un servlet, tal y como puede observarse en la Figura 2. El servidor web se comunica con el servlet mediante los métodos de la interface javax.servlet.servlet también esta interface está constituida por al menos cuatro métodos que serán llamados durante el ciclo de vida del servlet. Estos cuatro métodos son: init(): Es llamado por el servidor HTTP cuando un servlet se carga por primera vez. Este método no será llamado nunca más mientras el servlet se esté ejecutando. El método init() es utilizado para leer parámetros de inicialización como pueden ser parámetros de la base de datos. Se puede sobrescribir y no recibe parámetros. - 27 -

service(): Es el núcleo fundamental del servlet. Cada petición por parte del cliente se traduce en una llamada al método service() del servlet. El método service() lee la petición y debe producir una respuesta en base a los dos argumentos que recibe: 1. Un objeto de la interface ServletRequest con datos enviados por el cliente. Estos incluyen parejas de parámetros clave valor. 2. Un objeto de la interface ServletResponse que encapsula la respuesta del servlet al cliente. doget(), dopost(): El método service() examina el tipo de petición HTTP y llama al método adecuado, por ejemplo doget() o dopost(). Estos métodos contienen la verdadera esencia del servlet. El noventa por ciento del tiempo, sólo se atenderá a peticiones GET y, en su caso, POST, por lo que sustituirá a doget y, en su caso, a dopost. destroy(): es el último método que se llama justo antes de destruir el servlet. Una buena implementación de este método debe permitir que el servlet concluya sus tareas de forma ordenada. De esta forma es posible liberar recursos (ficheros abiertos, conexiones con bases de datos, etc.) de una forma limpia y segura. Cuando esto no es necesario o importante, no hace falta redefinir el método destroy(). - 28 -

Figura 2. Ciclo de vida de un servlet 4.2.5 JavaServer Pages (JSP) Las JavaServer Pages (JSP) son programas del servidor cuyo diseño y funcionalidad es muy similar al de los servlets. Una JSP procesa las peticiones mediante la lógica que incluye o mediante llamadas a otros componentes construidos con tecnología de servlets o con alguna otra tecnología. La diferencia entre una JSP y un servlet radica en la forma en que se escribe la JSP. El servlet se escribe en lenguaje Java mientras que la JSP se escribe en HTML, XML o en el formato del cliente, entremezclado con elementos de código, directivas y acciones escritas en lenguaje Java. - 29 -

4.2.5.1 JSPs vs. Servlets JSPs y servlets tienen muchas características en común [HALL01] y ambos pueden servir contenido dinámico. Sin embargo, los servlets se han de utilizar estrictamente como una extensión del servidor. Esto puede incluir la implementación de un controlador ofreciendo servicios de autenticación, validación de bases de datos, etc. Las JSP se usarán para desarrollar aplicaciones basadas en contenido dinámico. En el apartado cinco, en el cual se habla del MVC, se explica con más detalle el uso que haremos de los servlets y de las JSPs para la realización del presente proyecto. En la siguiente figura (véase Figura 3) se muestra el uso de las JSP. Figura 3. Páginas JSP 4.2.5.2 Arquitectura básica de las JSP Crear una JSP es más sencillo que crear un servlet debido a que, como se dijo anteriormente, la JSP está escrita en HTML. Sin embargo, una JSP proporciona - 30 -

fundamentalmente las mismas características que un servlet, ya que una JSP se convierte en un servlet la primera vez que el cliente la solicita. Es decir, las páginas JSP pasan por una fase de traducción que realiza el motor JSP por si mismo cuando recibe una petición de la página JSP por primera vez. El resultado de esta traducción es que el fichero.jsp se convierte en un fichero.class. Además, este fichero.class extiende a HttpJspBase el cual a su vez implementa la interfaz Servlet. En la siguiente figura (véase Figura 4) se muestra como una JSP se convierte en un servlet. Figura 4. Creación de una JSP Hay tres métodos que se llaman de forma automática al llamar a una JSP y cuando la JSP termina en forma normal: jspinit(): Es idéntico al método init() de un servlet. jspdestroy(): Es idéntico al método destroy() de un servlet. jspservice(): Una vez que el fichero.class es cargado en el contenedor servlet, se llama de forma automática al método service(), que es el responsable de responder a las peticiones de los clientes enviando el resultado de la JSP mediante HTTP. - 31 -

En la Figura 5 se muestra como son llamados los métodos init(), destroy() y service() a lo largo del ciclo de vida de las JSP. Figura 5. Ciclo de vida de una JSP 4.2.6 JavaBeans El modelo de componentes de la tecnología JSP está basado en la arquitectura de componentes JavaBeans. Un componente JavaBean no es más que un objeto Java que ha sido realizado siguiendo un patrón de nombres y diseño realizado previamente. Un bean encapsula sus propiedades declarándolas como privadas y proporciona métodos de acceso públicos (gets y sets) para permitir leer y modificar sus valores. La principal función de los JavaBeans es la de proporcionar la lógica de negocio a la aplicación e interactuar con otros componentes del servidor. - 32 -

4.3 Lenguaje de marcado de hipertexto (HTML) Como indica su nombre, HTML es un lenguaje de marcado que se utiliza para definir la forma en que el texto se debe mostrar en un navegador u otro software capaz de interpretar HTML, como pueden ser algunos procesadores de texto. Para indicar la forma de mostrar el texto se utilizan etiquetas. Una etiqueta se puede considerar como una orden al navegador. Es importante conocer HTML antes de crear componentes J2EE con JSP, ya que, como se verá posteriormente, la mayor parte del contenido de las JSP se escribe con HTML. Un usuario interactúa con una aplicación J2EE a través de una interfaz de usuario que se crea utilizando HTML. La interfaz de usuario envía la petición del cliente a componentes construidos con servlets y/o JSP. Hay dos características que se encuentran frecuentemente al utilizar HTML en una JSP para construir una página web en forma dinámica. Estas características son los formularios y las tablas. Los formularios HTML se utilizan frecuentemente en las JSP para generar una página web que recolecta información de un usuario, la cual se envía entonces a una JSP o servlet para su procesamiento. Un ejemplo de formulario HTML puede ser un formulario que captura datos. Los datos que recibe la JSP o servlet del formulario por lo general se envían a un componente javabean, el cual conecta con un Sistema de Gestor de Bases de Datos (SGBD). Una tabla HTML es una matriz similar a una hoja de cálculo que una JSP o servlet genera en forma dinámica para mostrar datos recuperados del SGBD. El código HTML de la JSP o servlet crea cada componente de la tabla y coloca etiquetas y datos dentro de sus celdas antes de enviar la página HTML al navegador para su despliegue. - 33 -

4.4 extensible Markup Language (XML) La familia XML es un conjunto de especificaciones que conforman el estándar que define las características de un mecanismo independiente de plataformas desarrollado para compartir datos. Se puede considerar a XML como un formato de transferencia de datos multi-plataforma. Es un subconjunto de LMGS (Lenguaje de Marcado Generalizado Standard) y uno de sus objetivos es permitir que LMGS genérico pueda ser servido, recibido y procesado en la web de la misma manera que actualmente es posible con HTML. XML ha sido diseñado de tal manera que sea fácil de implementar. No ha nacido sólo para su aplicación en Internet, sino que se propone como lenguaje de bajo nivel (a nivel de aplicación, no de programación) para intercambio de información estructurada entre diferentes plataformas. XML [MCLA00] hace uso de etiquetas (únicamente para delimitar datos) y atributos, y deja la interpretación de los datos a la aplicación que los utiliza. Por esta razón se van formando lenguajes a partir del XML, y desde este punto de vista XML es un metalenguaje. El conjunto de reglas o convenciones que impone la especificación XML permite diseñar formatos de texto para los datos estructurados, haciendo que se almacenen de manera no ambigua, independiente de la plataforma y que en el momento de la recuperación se pueda verificar si la estructura es la correcta. Para comprobar que los documentos estén bien formados se utiliza un DTD (Definición de Tipo de Documento). Se trata de una definición de los elementos que pueden incluirse en el documento XML, la relación entre ellos, sus atributos, posibles valores, etc. Es una definición de la gramática del documento [ERDP05], es decir, cuando se procesa cualquier información formateada mediante XML, el primer paso es comprobar si está - 34 -

bien formada, y luego, si incluye o referencia a un DTD, comprobar que sigue sus reglas gramaticales. En el caso del presente proyecto, XML se utiliza activamente en tareas de configuración, como pueden ser los ficheros de configuración del descriptor de implementación Servlet 2.4 y los ficheros de mapeo de Hibernate. 4.5 Apache/Tomcat En el desarrollo del presente proyecto necesitaremos un contenedor web. Los contenedores web son la puerta de las aplicaciones Java a la World Wide Web. Son servidores, escritos normalmente en Java, que son capaces de recibir peticiones HTTP y ejecutar las clases de Java (que a su vez utilizarán recursos tales como páginas HTML e imágenes) indicadas para darles respuesta, formando lo que se llama una aplicación web. Además, aunque casi todos incluyen un pequeño servidor web que les permite funcionar en solitario, normalmente pueden ser integrados con los servidores más conocidos como Apache. Las aplicaciones web realizadas en Java pueden tomar dos formas: servlets y páginas JSP. Las especificaciones de estas tecnologías forman parte de J2EE y como se dijo anteriormente, su principal cometido es el de crear páginas web dinámicas, es decir, páginas web que se generan en el servidor en base a nuestra lógica de negocio. Podemos elegir entre varios contenedores de servlet de código abierto y gratuitos. Los más conocidos y ampliamente usados en la industria, tanto de forma independiente, como en conjunto con servidores de aplicaciones, son Jetty [JETT05] y Apache Tomcat [APAC05]. Jetty lleva en marcha desde 1995 y es la mayor competencia de Tomcat. Aunque el menor tamaño de su comunidad y de la publicidad que recibe lo hacen pasar más - 35 -

desapercibido, se trata de un contenedor web muy ligero y que está desarrollado para ser integrado fácilmente en otras aplicaciones y así proporcionar a estas una interfaz HTTP. Para la realización de este proyecto utilizaremos Apache Tomcat a pesar de que Jetty se trate también de una buena solución. Las principales razones de esta decisión son lo estandarizado que se encuentra Tomcat (es la implementación de referencia para las JSP y los Servlet), su rendimiento más que aceptable y su contrastada estabilidad. Apache Tomcat forma parte del proyecto Jakarta. Este proyecto, que se encuentra bajo la dirección de la Apache Software Foundation (ASF, ampliamente conocida por su servidor web Apache), desarrolla tecnología orientada a software de construcción de sitios web. Jakarta está compuesto por varios subproyectos que dan soluciones potentes basadas en el lenguaje Java a problemas en particular. Entre estos subproyectos se encuentra Tomcat, que es sin lugar a dudas el proyecto de software libre escrito en Java más famoso. Tomcat implementa las especificaciones de los servlets y de las JSP de Sun Microsystems [CHOP05] e incluye el compilador Jasper que compila las JSPs para convertirlas en servlets. Dado que Tomcat fue escrito en Java, funciona en cualquier sistema operativo que disponga de la máquina virtual. La última versión de Tomcat, Tomcat 5.5, se trata de una implementación de las especificaciones Servlet 2.4 y JSP 2.0 API. 4.6 Hibernate Trabajar con software orientado a objetos y bases de datos relacionales puede hacernos invertir mucho tiempo en los entornos actuales. Hibernate [HIBE05] es una herramienta que realiza el mapping entre el mundo orientado a objetos de las aplicaciones y el mundo entidad-relación de las bases de datos en entornos Java. El término utilizado es ORM - 36 -

(Object/Relational Mapping) y consiste en la técnica de realizar la transición de una representación de los datos de un modelo relacional a un modelo orientado a objetos y viceversa. Hibernate no solo realiza esta transformación sino que nos proporciona capacidades para la obtención y almacenamiento de datos de la base de datos que nos reducen el tiempo de desarrollo. Este tipo de herramientas son necesarias debido a que el modelo de objetos sobre el que hoy en día se desarrolla la mayor parte del software, no concuerda adecuadamente con el modelo relacional que se utiliza de forma mayoritaria para el almacenamiento de información. La potencia que nos ofrecen los mapeadores objetos/relacionales es realmente impresionante, y se aprecia en todo su esplendor cuando vemos que gracias a ellos no es necesario escribir ni una sola línea de código SQL, ni siquiera para llevar a cabo tareas complejas, como puede ser recuperar colecciones de objetos, o estructuras de herencia. Hemos elegido Hibernate debido a que en los últimos años se ha convertido en un estándar de facto en la industria, por encima de otras soluciones realmente estándares. Y es que Hibernate nos proporciona un método de trabajo muy eficiente y funcional, el cual se encuentra basado totalmente en torno a lo que se conoce como ficheros de mapeado [RESP05]. Estos ficheros son prácticamente lo único que un programador tiene que desarrollar para poder acceder a la base de datos, y consisten en unos ficheros con sintaxis XML en los que se especifica, mapea, la relación entre los diversos atributos de nuestras clases y las filas de las tablas SQL. - 37 -

Estas relaciones pueden ser muy sencillas, como sería el caso de atributos basados en tipos de datos simples, como pueden ser enteros, cadenas de caracteres, etc. Algo a lo que el modelo relacional se adapta muy bien, y resulta sencillo pasar a un modelo de objetos. Sin embargo, los verdaderos problemas entre el modelo relacional y el modelo de objetos aparecen cuando vemos que en un modelo de objetos resulta muy sencillo implementar relaciones entre atributos complejos. Por ejemplo, no supone ningún problema que una clase tenga un atributo que no es tipo de dato simple, sino otra clase, que a su vez puede tener también otros atributos complejos asociados. O incluso podemos tener atributos que son colecciones de objetos. Todo ello de una forma natural y sencilla, mientras que esto no es posible en el mundo relacional. Y en esta área es donde resultan realmente útiles los mapeadores objeto/relaciones. Como ejemplo, si tenemos que recuperar desde una base de datos relacional un objeto que pertenece a una clase que tiene como atributo una colección de objetos de otra clase diferente, primero tendremos que recuperar el objeto que deseamos, y posteriormente a partir de su clave primaria acceder a la tabla donde se almacenan los objetos de la colección, recuperarlos y asociarlos al objeto inicial. Esto da lugar a código bastante complejo y lioso, que hace muy difícil añadir nuevas relaciones o entidades (clases). Sin embargo, con Hibernate simplemente especificamos en los ficheros de mapeado que la clase tiene un atributo que es una colección, y que además forma parte de una relación uno a muchos con otra entidad, y cuando recuperemos un objeto de esa clase, el propio Hibernate, de forma totalmente transparente, recupera el resto de objetos asociados a el. Esto hace que añadir nuevas relaciones o clases sea muy sencillo, debido a que solo es necesario crear las nuevas clases y tablas SQL que necesitemos, y por último definir las asociaciones en los ficheros de mapeado. - 38 -

En la Figura 6 se puede ver un ejemplo de fichero de mapeado para Hibernate, que se utiliza en el proyecto, en el que se describe cual es la clave primaria de la entidad, y a continuación se describen las diversas propiedades de tipos de datos simples. Para finalmente definir la relación uno a muchos existente entre la tabla personal y la tabla equipos. Figura 6. Fichero de mapeado para Hibernate Como vemos, Hibernate nos facilita enormemente la tarea de la persistencia desde aplicaciones orientadas a objetos, y todo ello de una forma muy sencilla, teniendo en la especificación de los ficheros de mapeo la base de toda la herramienta. - 39 -

4.7 MySQL En el presente proyecto se ha hecho uso de la herramienta MySQL [MYSQ05] para todas las tareas de almacenamiento de la información. Para la elección del SGBD se ha partido de que tenía que ser un producto de código abierto y además gratuito. Otros de los motivos por los que se ha optado por utilizar MySQL es el ser un gestor de bases de datos sencillo de usar e increíblemente rápido. También es uno de los motores de bases de datos más usados en Internet y está avalado por empresas de renombre. La principal razón de esto es el ser gratis para aplicaciones no comerciales. Las características principales de MySQL [SUEH20] son: Es un gestor de base de datos. Una base de datos es un conjunto de datos y un gestor de base de datos es una aplicación capaz de manejar este conjunto de datos de manera eficiente y cómoda. Es una base de datos relacional. Una base de datos relacional es un conjunto de datos que están almacenados en tablas entre las cuales se establecen unas relaciones para manejar los datos de una forma eficiente y segura. Para usar y gestionar una base de datos relacional se usa el lenguaje estándar de programación SQL. Es Open Source. El código fuente de MySQL se puede descargar y está accesible a cualquiera, por otra parte, usa la licencia GPL (General Public License) para aplicaciones no comerciales. Es una base de datos muy rápida, segura y fácil de usar. Gracias a la colaboración de muchos usuarios, la base de datos se ha ido mejorando optimizándose en velocidad. Por eso es una de las bases de datos más usadas en Internet. Existe una gran cantidad de software que la usa. - 40 -