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

De MediaWiki
Ir a la navegación Ir a la búsqueda

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 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.
Estrutura de ficheiros para aplicación web JEE

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:

  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.

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
  • 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.

Referencias