Despliegue de Aplicaciones Java EE: Arquitectura Tomcat, Seguridad y Control de Versiones

Conceptos Fundamentales en el Desarrollo y Despliegue Java

Glosario de Términos Técnicos

Fichero .war:: Es un fichero comprimido que contiene todos los componentes web de una aplicación y es ejecutable.
JavaServer Pages (JSP):: Es una tecnología basada en Java para crear páginas dinámicas en servidores como Tomcat o GlassFish.
JDK (Java Development Kit):: Es un kit de desarrollo que ofrece herramientas muy útiles para programar en Java.
JNDI (Java Naming and Directory Interface):: Es una interfaz que permite localizar información en distintos directorios.
Realm:: Es el concepto que usa Tomcat para referirse a los dominios de seguridad.
Servlet:: Son programas escritos en Java sin interfaz gráfica que permiten escuchar peticiones a partir del protocolo HTTP.
SSL (Secure Sockets Layer):: Es un protocolo de cifrado que se usa para garantizar la seguridad de las comunicaciones.

5. Despliegue de Aplicaciones y Arquitectura de Servidores

5.1 Introducción al Despliegue

Para el despliegue de una aplicación en un servidor de aplicaciones, se deben tener en cuenta varios aspectos clave, como el descriptor de despliegue, el servidor donde se va a publicar la aplicación, la seguridad, la autenticación de los usuarios, la administración de sesiones, los registros, etc.

5.2 Arquitectura y Configuración Básica del Servidor de Aplicaciones

Un servidor de aplicaciones es un software global que permite dar servicio a las aplicaciones que se publican en él.

El Patrón de Diseño Modelo-Vista-Controlador (MVC)

Modelo: Es el componente que se encarga de representar la información con la que la aplicación trabaja. Su función es realizar las consultas y modificaciones. La petición llega por parte del controlador, este componente ejecuta la acción y la presenta a la Vista.
Vista: Visualiza el modelo para que el usuario interactúe. Normalmente es la interfaz de la aplicación.
Controlador: Es el módulo más importante, ya que controla a los otros dos componentes. Responde a peticiones realizadas por el usuario y, a partir de ahí, se comunica con el Modelo para manipularlo y realizar cambios en la Vista.

Servidores de Aplicaciones Populares

Los servidores de aplicaciones más usados son:

WildFly: Es un software implementado por JBoss y está desarrollado en Java. Está basado en proyectos punteros de software open source y se fundamenta en dos núcleos:
- JBoss Modules: Controla la carga de los recursos de la clase contenedor.
- Modular Service Container: Administra los servicios usados por el contenedor.
GlassFish: Es un software de código abierto para la plataforma Java EE, que proporciona un proyecto estructurado de desarrollo.
JonAS: Es un software libre indicado para servidores de aplicaciones, desarrollado por ObjectWeb.
Apache Tomcat: Es un servidor de aplicaciones open source que implementa Java Servlet y JavaServer Pages (JSP). Estos módulos son desarrollados por la Java Community.

5.2.2 Arquitectura de Apache Tomcat y Variables de Entorno

Apache Tomcat usa una arquitectura que permite conectar sus diferentes componentes, donde cada uno realiza una función determinada.

Server: Es el componente que representa el contenedor al completo y dentro de él se ejecutan los demás componentes.
Service: Es un componente intermedio que se comunica y que se encuentra dentro del componente Server.
Engine: Es el servicio que permite procesar las peticiones que provienen desde el exterior y responder a tales solicitudes.
Host: Es un nombre de red que puede poseer varios hosts o alias, como www.daw.com.
Connector: Es el encargado de controlar las comunicaciones con el cliente.
Context: Representa una aplicación web.

Directorios Principales de Instalación de Tomcat

A partir de la instalación de Tomcat, encontramos los siguientes directorios clave:

bin: Es el directorio que contiene los ficheros binarios y los scripts de inicio.
conf: Este directorio es uno de los más importantes, ya que permite la configuración global del servidor de aplicaciones.

5.4 Autenticación de Usuarios y Dominios de Seguridad (Realms)

El siguiente paso es hacer que la aplicación sea segura y permitir la autenticación de usuarios. Los seis plugins que soporta Tomcat para la autenticación son:

JDBCRealm: Autenticación vía driver JDBC a una base de datos relacional.
DataSourceRealm: Autenticación vía JNDI JDBC Data Source a una base de datos relacional.
JNDIRealm: Autenticación mediante JNDI a un directorio activo LDAP.
UserDatabaseRealm: Se autentica mediante el acceso a la información almacenada en un recurso UserDatabase JNDI, normalmente un fichero XML.
MemoryRealm: Se autentica mediante el acceso a la información almacenada en memoria, que es configurada desde un fichero XML.
JAASRealm: Autenticación basada en un framework de Java llamado JAAS.

6. Documentación y Sistemas de Control de Versiones

Resumen de la Unidad 6

Glosario de Documentación y Desarrollo

Bug:: Es un error de software que provoca un resultado no deseado.
Historia de un Repositorio:: Es un listado de cualquier repositorio que permite observar los diferentes commits, pushes y la creación de ramas.
Tags:: Son unas etiquetas que se aplican en el entorno de programación, por ejemplo, cuando se documenta un proyecto.
Template (Plantilla):: Es un documento base, a partir del cual se puede programar.

6.2 Herramientas Externas para la Generación de Documentación

La lista de las herramientas que generan automáticamente documentación son las siguientes:

Javadoc: Es la herramienta de Oracle por excelencia para generar documentación en formato HTML a partir del código desarrollado en Java.
phpDocumentor: Es otra herramienta escrita en PHP para generar documentación automáticamente a partir del código fuente PHP.
Doxygen: Esta herramienta es más versátil, ya que permite generar documentación en bastantes lenguajes de programación como C++, Java, C, Python, etc.

6.3 Formatos Estándar para la Documentación

Todas las formas de documentación deben tener un objetivo común: documentar de forma clara y concisa las clases.

Comentario en línea: Este tipo de comentario va precedido de dos barras, por ejemplo: // Atributos.
Comentario en bloque: Estos comentarios van precedidos de /*, luego se escribe el texto y se finalizaría con */. Todo el texto que esté dentro se consideraría comentario. Si se quiere que lo interprete Javadoc, habría que englobar los comentarios entre los símbolos /** y */.

Estructura de Documentación de una Clase

Explicación de cómo se documentaría una clase:

Nombre de la clase: Sería el nombre de la clase de forma identificativa.
Descripción: Una descripción corta de qué contiene la clase.
Autor: Quién es el autor o autores de la clase.
Versión: Es fundamental para comprobar cuántas versiones se han realizado de la misma.

También se deben documentar los constructores, métodos y destructores que tenga:

Tipo de método: Público o privado.
Nombre del método o constructor: Descripción breve del método o constructor.
Parámetros: Las variables de entrada al método o constructor.
Variables de salida: Si el método devuelve algún valor.

6.5 Herramientas Colaborativas para la Elaboración y Mantenimiento de la Documentación

Actualmente existen muchas herramientas para elaborar documentación, tanto open source como de pago. Una de las mejores es Slack, que posee una versión gratuita muy potente, pero si se quiere ampliar, hay que pagar. Por otro lado, la mayoría de las empresas dedicadas a la implementación de software usan el paquete Microsoft Office 365, que posee una gran variedad de opciones (no es gratuita).

6.6 Instalación, Configuración y Uso de Sistemas de Control de Versiones en SO Windows

Cuando no existían sistemas de control de versiones, se programaba en un directorio y, si se modificaba algo, era necesario hacer un backup del directorio para poder volver atrás si la modificación realizada no era la correcta. Esto significa que la forma de trabajar ha cambiado considerablemente, ya que en la actualidad es más fácil programar y reutilizar código.

6.6.1 Conceptos Básicos del Control de Versiones

Repositorio (Repository): El lugar de almacenamiento de las distintas versiones del software que está desarrollando un equipo.
Rama (Branch): Cada programador tiene su copia de trabajo en local y realiza modificaciones sobre una rama en concreto del proyecto.
Conflicto: Se produce cuando varios programadores han realizado cambios en la misma rama del software y estos son contradictorios.
Cambio (Change): Se realiza cuando se ha modificado la parte asignada a un programador y se sube al repositorio.
Revisión (Revision): Es una revisión del software y permite al sistema controlar las distintas revisiones realizadas.
Confirmar (Commit): Confirmación de que se han realizado varios cambios en el mismo documento.

6.6.2 Funcionamiento del Control de Versiones

Los sistemas de control de versiones se pueden clasificar, atendiendo a la arquitectura usada, en tres tipos:

Locales: Es la versión más simple de la arquitectura de los sistemas, ya que la copia del proyecto no se comparte con nadie. Es como si se hiciera un backup en local, pero es la base de los siguientes tipos.
Centralizados: Esta arquitectura consiste en un servidor central que contiene el repositorio con todo el código y está asignado a un usuario, que normalmente es el jefe del proyecto. Todas las operaciones que se hagan pasan por su aprobación, por ejemplo, GitHub.
Distribuidos: En este caso no existe un repositorio central, sino que cada equipo de trabajo tiene su propio repositorio. Los repositorios que existen en cada equipo se pueden intercambiar y fusionar revisiones entre ellos. Es necesario que el equipo de trabajo controle esta forma de trabajar, si no, pueden ocurrir interferencias. Tiene la ventaja de que no es necesario conectarse al servidor central.