Teoría sobre implantación de aplicacións web
Sumario
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:
- 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.
- 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.
- 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 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.
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 ferramento
- 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>
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:
- Autenticación : proceso para identificar quén entra na aplicación é quén di ser, y validar que pode acceder ó recurso requirido.
- Confidencialidade : os extremos da comunicación deben coñecer a información que se intercambia sen que poida ser accedida por terceiros.
- 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.
Configurar o servidor de aplicacións con soporte SSL/TLS
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
- Apache Tomcat é un dos máis populares
- 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.
- La instalación e configuración en sistemas Windows é parecida á de Linux
- as diferencias estriban na estrucura 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 del servidor.