Teoría sobre implantación de aplicacións web

Obxectivos

• Describir os compoñentes e o funcionamiento dos servizos proporcionados polo servidor de aplicacións.
• Identificar os principais ficheiros de configuración e de bibliotecas compartidas.
• Configurar o servidor de aplicacións para cooperar co servidor web.
• Configurar e activar os mecanismos de seguridade do servidor de aplicacións.
• Configurar e usar os compoñentes web do servidor de aplicacións.
• Realizar os axustes necesarios para o despregamento de aplicaciós sobre o servidor.
• Levar a cabo probas de funcionamiento e rendemiento da aplicación web despregada.

Introdución

Aprenderemos sobre certos conceptos:

• o descriptor de despregue
• os diferentes servidores de aplicacións
• a seguridade da aplicación
• cómo se van a autenticar os usuarios
• a administración de sesións
• os rexistros de logs

Arquitectura e configuración básica do servidor de aplicacións

A arquitectura que se adoita empregar neste tipo de aplicacións é un patrón software que separa a lóxica de negocio e os datos da parte representativa que observa o usuario, os eventos e las comunicacións entre os distintos compoñentes.

Este modelo denomínase Modelo-Vista-Controlador (MVC) e basease na separación de módulos para facilitar o seu posterior mantemento e a reutilización de código, fancendo ademáis máis sinxela a detección de erros en caso de fallos; porén é importante separar a representación dos datos (Vista) da parte interna ou Modelo de datos, coma por exemplo a base de datos.

Os tres grandes compoñentes nos que se divide o modelo son:

1. Modelo: encárgase de representar a información coa que a aplicación traballa; realiza as consultas e modificacións con base aos privilexios definidos previamente na análise de requisitos da aplicación. A petición chega por parte do controlador e este compoñente executa a acción e preséntalla á Vista.
2. Vista: visualiza o modelo cun tipo de representación para interactuar co usuario. Normalmente é a interfaz da aplicación que pode ser unha aplicación web, aplicación de escritorio ou calquera aplicación en calquiera entorno ou sistema operativo.
3. Controlador: é o módulo más importante que controla os outros dous compoñentes, servindo de mediador entre o Modelo e a Vista. Responde a peticións realizadas polo usuario (pulsar un botón da interfaz ou calquera outra acción) comunicando co Modelo para manipulalo facendo cambios na Vista.

Servidores de aplicacións

Un servidor de aplicaciones é un software global que permite dar servizo a as aplicacións que se publican no mesmo dando soporte para a seguridade, as transaccións, a administración de sesiones, o cacheo, o rexistro de logs, etc.

Existe un abanico de servidores de aplicacións que son usados:

• WildFly (JBoss Application Server): é un software implementado por JBoss e desenvolto en Java. É software libre disponible para todos os sistemas operativos do mercado. A estructura interna conta con dous núcleos principais:
  • JBoss Modules: controla a carga dos recursos da clase contenedora.
  • Modular Service Container: administra os servizos usados polo contedor. Por exemplo, instala e desinstala os diferentes servizos.
• GlassFish: software de código aberto desenvolto por Sun Microsystems para a plataforma Java EE. Proporciona un proxecto estructurado de desenvolvement que permite ter disponibles as npvas funcionalidades de Java.
• Apache Tomcat: servidor de aplicacións libre implementando Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. Estes módulos son desenvoltos polo Java Community Process. Oracle certifica coa versión de Java correspondente.
• Oracle WebLogic Server é unha plataforma unificada e extensible para desenvolver, implementar e executar aplicacións empresariais (coma aplicacións Java) on-premises e na nube. Ofrece unha implementación sólida, madura e escalable de Java Enterprise Edition (EE) e Jakarta EE.
• Jetty é un servidor HTTP e un contenedor de Servlets escrito en Java. Publícase como un proxecto de software libre baixo a licenza Apache 2.0. É utilizado por outros proyectos (por exemplo os servidores de aplicacións JBoss e Apache Geronimo; e polo plugin Google Web Toolkit para Eclipse. Jetty enfócase en crear un servidor web sinxelo, eficiente, empotrable e pluggable. O tamaño tan pequeño de Jetty faino axeitado para ofrecer servicios Web nunha aplicación Java empotrada.
• IBM WebSphere Application Server é un entorno de execución de servidor Java flexible e altamente seguro para aplicacións empresariais
• Apache TomEE é a Java Enterprise Edition de Apache Tomcat (Tomcat + Jakarta EE = TomEE) que combina outros proxectos coma Apache OpenEJB, Apache OpenWebBeans, Apache OpenJPA, Apache MyFaces e outros]
• Apache Geronimo é un servidor de aplicacións de código abierto desenvolto pola Apache Software Foundation e distribuído baixo a licencia Apache]

Nalgúns casos os produtos son resultado da integracion de varias tecnoloxías e pode resultar confusa a súa distinción.

Por exemplo, entre Tomcat, TomEE (e as súas variantes) e TomEE+. Podes atopar un resumo explicatorio pero é preciso coñecer moitas desas tecnoloxías para acadar unha boa comprensión de cales son as súas semallanzas, diferenzas, ou cal é máis axeitado para un proxecto.

Comparación de servidores de aplicacións

Seleccionar a plataforma axeitada pode ter un impacto significativo na eficiencia, escalabilidade e éxito das túas aplicacións de software. Os servidores de aplicacións varían moito en termos de rendemento, escalabilidade, facilidade de uso e nos casos de uso específicos para os que están mellor adaptados.

A continuación, preséntase unha análise comparativa de cinco servidores de aplicacións distintos, cada un cos seus puntos fortes e aplicacións ideais.

Característica	Apache Tomcat	JBoss	WebSphere	GlassFish	NGINX Unit
Rendemento	Bo para aplicacións pequenas e medianas	Optimizado para aplicacións empresariais	Alto, ideal para transaccións complexas	Bo, con soporte completo para Java EE	Eficiente, manexa alta concorrencia
Escalabilidade	Boa, pero limitada para aplicacións a gran escala	Altamente escalable, manexa grandes aplicacións empresariais	Excelente para despregamentos grandes e complexos	Boa escalabilidade con funcións Java EE	Altamente escalable con configuracións dinámicas
Facilidade de uso	Fácil de xestionar, gran soporte comunitario	Complexo, require máis experiencia pero está ben documentado	Require habilidades especializadas e unha configuración complexa	Sinxelo para desenvolvedores de Java EE	Reconfiguración dinámica sen reinicios
Caso de uso ideal	Aplicacións web que non necesitan Java EE completo	Aplicacións completas con Java EE	Corporacións grandes que precisan integración fiable	Desenvolvedores que necesitan unha plataforma robusta para Java EE	Servidor versátil para aplicacións multi-linguaxe

Tanto se a túa prioridade é xestionar transaccións de alto volume, soportar múltiples linguaxes de programación, como administrar aplicacións de nivel empresarial, hai unha opción de servidor adecuada dispoñible. Ao elixir un servidor de aplicacións, considera non só as necesidades actuais, senón tamén as futuras das túas aplicacións para garantir escalabilidade e flexibilidade.

Estrutura de ficheiros

Unha aplicación web JEE debe ter unha estrutura de ficheiros e directorios determinada:

• /: Na carpeta raíz do proyecto almacénanse elementos empregados nos sitios web coma documentos html, CSS e os elementos JSP (*.html *.jsp *.css). Podense subdividir tamén en directorios.
• /META-INF/: é un directorio privado da aplicación que conten habitualmente un ficheiro denominado context.xml que permite definir o contexto da aplicación.
• /WEB-INF/: Atópanse os elementos de configuración do archivo .WAR coma poden ser: a páxina de inicio, a ubicación dos servlets, parámetros adicionais para outros compoñentes. Coma veremos máis adiante o mail relevante é o ficheiro web.xml ou descriptor de despregue da aplicación.
• /WEB-INF/classes/: Conten as clases Java empregadas no ficheiro .WAR; normalmente nesta carpeta atópanse os servlets.
• /WEB-INF/lib/: Conten os ficheiros JAR utilizados pola aplicación: son librerías, entre outras as empregadas para conectarse coa base de datos ou as empregadas polas librerías de JSP.
• O resto de carpetas son para os elementos estáticos da aplicación (imáxenes, etc) que podemos estruturar o noso antoxo.

Descriptor de despregue

Un descriptor de despregue (Deployment Descriptor ou DD) é un compoñente de aplicacións J2EE que describe cómo se debe despregar (ou implantar) unha aplicación web. Esto dirixe a unha ferramenta de despregue (ou publicación) para despregar un módulo ou aplicación con opcións de contedor e requisitos de configuración específicos.

XML úsase para a sintaxe do ficheiro descriptor de despregue en aplicacións J2EE. Chámase web.xml e debe ser colocado nun subdirectorio chamado WEB-INF, directamente debaixo da raíz da aplicación web.

AMPLIACIÓN.
Podes atopar información do descriptor de despregue para o servidor de aplicacións IBM Web Application Server

Pódese modificar:

• manualmente editando o ficheiro
• utilizando a consola da ferramenta
• usando un editor de descriptor de despregue da ferramenta de ensamblaxe

As dúas últmas son máis recomendables porque permiten asegurarnos de que o descriptor ten as propiedades válidas e de que as referencias conteñen os valores correctos.

Exemplo sinxelo de descriptor de despregue

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
    <servlet>
      <servlet-name>HolaMundoServlet</servlet-name>
      <servlet-class>org.prueba.servlet.HolaMundoServlet</servlet-class>
    </servlet>
    <servlet-mapping>
      <servlet-name>HolaMundoServlet</servlet-name>
      <url-pattern>/HolaMundoServlet</url-pattern>
    </servlet-mapping>
    <session-config>
      <session-timeout>30</session-timeout>
    </session-config>
</web-app>

Mecanismos de caché nos servidores de aplicacións

A caché é unha técnica importante nos servidores de aplicacións, deseñada para mellorar o rendemento e reducir a latencia almacenando en memoria datos ou páxinas de acceso frecuente.

Deste xeito, os servidores de aplicacións poden proporcionar directamente aos clientes estas respostas almacenadas previamente, ou "en caché", sen procesar repetidamente as mesmas solicitudes. Isto acelera significativamente os tempos de resposta e reduce a carga sobre os recursos do servidor.

Por exemplo, datos de sesión, perfís de usuario e contido dinámico de acceso frecuente, como noticias ou datos financeiros, poden ser almacenados en caché.

Estratexias de caché eficaces aseguran que os datos permanezan actualizados mentres minimizan a necesidade de consultas á base de datos, optimizando así a eficiencia e escalabilidade das aplicacións web.

Seguridade no servidor de aplicacións

Débese protexer á aplicación web e o servidor de aplicacións de accesos malintencionados, de que non interceptan a información.

Seguridade e autenticación

Para protexer ante as anteriores ameazas un sistema de seguridade basease en tres conceptos clave:

1. Autenticación : proceso para identificar quén entra na aplicación é quén di ser, y validar que pode acceder ó recurso requirido.
2. Confidencialidade : os extremos da comunicación deben coñecer a información que se intercambia sen que poida ser accedida por terceiros.
3. Integridade : a información que se transmite de extremo a extremo non é alterada por axentes externos.

É importante que o servidor de aplicacións controle de xeito transparente ó usuario as comunicacións entre os distintos elementos que intercambian información no fluxo da aplicación. O ficheiro web.xml encárgase desta función coas marcas que xa se explicaron.

Pódese tamén controlar a seguridade mediante a programación dos servlets e ficheiros .jsp que permitan a seguridade da aplicación.

Autenticación

Existen distintos tipos de autenticación que se poden implementar nunha aplicación web:

• Autenticación basic: basease en solicitar datos o usuario, como un nome de usuario e un contrasinal. Esta información non vai codificada polo que é peligroso usar este tipo de autenticación.
• Autenticación digest: variante da basic onde o contrasinal viaxa pola rede encriptada mediante unha función hash. Non todos os servidores soportan este tipo de autentificación.
• Autenticación baseada en formularios: basease en solicitarlle datos ó usuario mediante un formulario no que introduzca o usuario e contrasinal. Este mecanismo é débil de cara a los hackers xa que pódese obter esta información de forma fácil.
• Certificados dixitais e SSL: o ideal é usar o protocolo HTTPS que funciona no porto 443 permitindo garantir a confidencialidade e integridade da información, e asegurando a autenticación. O funcionamento basease na criptografía de clave pública.

Recuperación ante desastres nos servidores de aplicacións

A recuperación ante desastres é un aspecto esencial da xestión de servidores de aplicacións, garantindo que os servizos poidan retomarse rapidamente despois dun evento catastrófico. Este proceso implica unha planificación estratéxica e a implementación de tecnoloxías e procesos para realizar copias de seguridade, manter a integridade dos datos e asegurar unha alta dispoñibilidade.

Componentes clave dun plan de recuperación ante desastres

• Replicación de datos: Realizar réplicas de datos de forma regular en múltiples localizacións físicas ou na nube para previr a perda de información.
• Mecanismos de failover: Cambio automático a un servidor de aplicacións ou centro de datos en espera cando o sistema principal falla.
• Copias de seguridade regulares: Programar copias de seguridade frecuentes dos datos e configuracións das aplicacións para facilitar a recuperación.
• Probas e documentación: Probar regularmente o proceso de recuperación para garantir a súa eficacia e manter unha documentación detallada sobre os procedementos de resposta ante desastres.

A implementación destas medidas permite ás organizacións minimizar os tempos de inactividade e manter a continuidade do servizo, algo fundamental para preservar a confianza dos clientes e as operacións empresariais.

Conclusións

Os servidores de aplicacións desempeñan un papel vital no ecosistema dixital, facilitando aplicacións web dinámicas que son responsivas e adaptadas ás necesidades dos usuarios. Ao diferenciarse dos servidores web pola súa capacidade para xestionar lóxica empresarial complexa e proporcionar contido dinámico, ofrecen unha plataforma robusta para que os desenvolvedores creen experiencias web sofisticadas e interactivas.

Exploramos as definicións, configuracións e funcións esenciais dos servidores de aplicacións. Comparamos estes cos servidores web, discutimos o seu papel nas arquitecturas cliente-servidor e revisamos diferentes tipos de servidores de aplicacións, como Apache Tomcat, Wildfly e WebSphere. Tamén destacamos a importancia da caché, a seguridade e a recuperación ante desastres para manter ambientes de aplicacións eficientes, seguros e resilientes.

A medida que coma desenvolvedores gañes experiencia e vais ampliando os límites das aplicacións baseadas na web, poderás comprender e aproveitar as capacidades dos servidores de aplicacións o que será clave para ofrecer aplicacións de alto rendemento, escalables e seguras.

Resumo

• a arquitectura de modelo-vista-controlador é básica en cualquier aplicación del mercado, xa que permite separar ao programador as partes ben diferenciadas das que consta una aplicación.
  • o modelo fai de ponte entre o controlador y la vista e encárgase de realizar as peticións e modificacións en base aos privilexios.
  • a vista é a parte que observa o usuario e que posee unha capa de abstracción que permite que se oculte toda a lóxica que existe detrás.
  • o controlador é o cerebro da aplicación e permite que todo funcione correctamente.
• Existen no mercado moitos servidores de aplicacións
  • Apache Tomcat é un dos máis populares
    • a instalación e posta en funcionamento basease no uso do JDK para compilar as clases de Java, na instalación do seu software e na configuración das variables de entorno.
    • para poder administrar as aplicacións no servidor de aplicaciones permite configurar usuarios, contrasinais e roles no ficheiro de configuración tomcat-users.xml
• Na administración de aplicacións é fundamental
  • coñecer cómo se despliega unha aplicación a partir dun ficheiro .war ou de forma manual.
  • a estrutura fixa de directorios que debe poseer unha aplicación para poder desplegarse.
• A autenticación de usuarios realízase en Tomcat a partir dos dominios de seguridade (Realm)
  • engloba o conxunto de usuarios, contrasinais e roles que se van definir nos correspondentes ficheiros .xml.
• Para a administración e configuración das sesións das aplicacións é necesario coñecer cómo se configura unha sesión persistente.
  • Podenos axudar examinar á configuración dos rexistros de acceso e os filtros de solicitudes.
• A instalación e configuración en sistemas Windows é parecida á de Linux
  • as diferencias estriban na estrutura de directorios e algúns ficheiros coma os de execución
• Unha vez programada unha aplicación web debemos documentar cómo se desprega indicando a súa estructura e a configuración dos ficheiros clave no despregue:
  • web.xml
  • context.xml
  • o ficheiro de inicio index.jsp, index.html
  • calquera outro que sexa compatible co servidor de aplicacións.
• Débese securizar ó servidor de aplicacións mediante SSL para impedir accesos malintencionados
  • para iso é necesario modificar o ficheiro server.xml do servidor.

Referencias

• What is an application server - Contabo