Document Details

Oganesson93

Uploaded by Oganesson93

Universidad de Valladolid

Tags

java ee application servers web development

Full Transcript

Tema 30. Servidores de aplicación Java EE. Caso I: Oracle Weblogic. Caso II: Apache y su contenedor de servlets Tomcat. Los servidores de aplicaciones Java EE (Enterprise Edition) son plataformas de software que proporcionan un entorno de ejecución para aplicaciones empresariales basadas en Java. E...

Tema 30. Servidores de aplicación Java EE. Caso I: Oracle Weblogic. Caso II: Apache y su contenedor de servlets Tomcat. Los servidores de aplicaciones Java EE (Enterprise Edition) son plataformas de software que proporcionan un entorno de ejecución para aplicaciones empresariales basadas en Java. El estándar JEE permite el desarrollo de aplicaciones de empresa de una manera sencilla y eficiente. Una aplicación desarrollada con las tecnologías JEE permite ser desplegada en cualquier servidor de aplicaciones que cumpla con el estándar. Frente a la tradicional estructura en dos capas (Cliente/Servidor) de un servidor web un servidor de aplicaciones proporciona una estructura en n capas que permite estructurar nuestro sistema de forma más eficiente. De manera que pueda proporcionar los contenedores y los servicios necesarios para la ejecución de los componentes de las aplicaciones Java EE. Algunos de los ejemplos de servidores de aplicaciones: - Oracle WebLogic Server: Es un servidor de aplicaciones Java EE de alto rendimiento y escalabilidad, que proporciona una amplia gama de servicios y funcionalidades para las aplicaciones empresariales. Fue adquirido por Oracle Corporation en 2008, cuando compró BEA Systems. - WildFly, ​ anteriormente conocido como JBoss, es un servidor de aplicaciones Java EE de código abierto implementado en Java puro, más concretamente la especificación Java EE. - WebSphere® Application Server es un servidor de aplicaciones de IBM. - GlassFish es un servidor de aplicaciones de software libre desarrollado por Sun Microsystems, compañía adquirida por Oracle Corporation, que implementa las tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta especificación. **Apache y su contenedor de servlets Tomcat** El servidor Apache es un servidor web HTTP de código abierto multiplataforma (Linux, Unix, Windows, Mac,\...). La arquitectura del servidor Apache es muy modular. El servidor consta de una sección core y diversos módulos que aportan funcionalidad como puede ser es mod\_php para trabajar con PHP para poder aportar dinamismo a sus páginas web. La diferencia con Apache tomcat que también es un servidor web es que está preparado para la ejecución de código Java (Con su MVJ). \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- Apache Tomcat es un software para la implementación de una parte de las especificaciones de la plataforma JEE. Podemos resumirlo como un servidor web con soporte para servlets y JSPs. Tomcat incluye un contenedor de servlets, lo que significa que puede manejar las solicitudes HTTP y generar dinámicamente contenido web en respuesta. También proporciona una consola de administración web para configurar y gestionar el servidor. Tomcat no se considera como un servidor de aplicaciones al no ser totalmente compatible con todas las especificaciones Jakarta EE (Java EE), ya que no tiene contenedor de EJBs (Enterprise Java Beans). Sí cumple el resto de las especificaciones, bien directamente o bien por medio de módulos externos (están disponibles agregando archivos adicionales Jar descargables gratuitamente). Si se necesita soporte de EJBs, se puede utilizar JBoss/WildFly que es un servidor EJB de código abierto integrable con Tomcat. Los contenedores de Servlets en Tomcat los podemos dividir: - Contenedores de Servlets stand-alone (independientes): este es el modo por defecto usado por Tomcat. Tomcat además de albergar un contenedor de servlets contiene un servidor web completo donde se pueden desplegar aplicaciones web y ser ejecutadas. - Luego puede funcionar como complemento a otros servidores web aportando su contenedor de servlets. Dentro de estos existen dos tipos: - Contenedores de Servlets dentro-de-proceso (inprocess): Donde la MVJ donde se ejecuta los contenedores de servlets se encuentran dentro del servidor web. - Contenedores de Servlets fuera-de-proceso (outprocess): Donde la MVJ se encuentra fuera del servidor web. El servidor web y la MVJ se tendrán que comunicar generalmente a través de sockets TCP/IP. [Estructura lógica (Módulos Tomcat)] Tomcat está compuesto por una serie de módulos cuyo comportamiento es altamente configurable. Incluso se pueden cambiar las clases que utiliza Tomcat por clases propias modificando el fichero server.xml. El esqueleto de la estructura de server.xml: Texto, Carta Descripción generada automáticamente La estructura general de dichos módulos se muestra en la siguiente figura. ![Diagrama Descripción generada automáticamente](media/image2.png) Cada módulo viene representado por su correspondiente etiqueta en el fichero **server.xml**. - [Server]: es el propio Tomcat. Solo existe una instancia de este componente. Representa el contenedor de servlets Catalina al completo. Puede contener una o más instancias \. - [GlobalNamingResources]: sirve para definir recursos JNDI globales a todas las aplicaciones. - [Service]: un objeto de este tipo representa el sistema formado por un conjunto de conectores (connector) que reciben las peticiones de los clientes y las pasan a un único engine, que las procesa. Si se desea que el contenedor actúe en modo stand alone que será el comportamiento por defecto viene definido por el atributo name de la siguiente manera: \ \ o \ \ - [Connector]: representa el endpoint que reciben las peticiones para pasárselas al engine y donde las respuestas son devueltas. Por defecto, Tomcat incorpora un conector HTTP/1.1 (sin SSL) por el puerto 8080, y otro para comunicación con otros servidores (como Apache). Para cambiar el puerto por el que Tomcat acepta las peticiones HTTP basta con cambiar el atributo port de dicho connector. - [Engine]: El Engine analiza las cabeceras HTTP incluidas en las peticiones y estás se derivan al Host (virtual Host) correspondiente. - [Host]: representa un host (o un host virtual) donde se despliegan las aplicaciones. - [Context]: representa cada aplicación web desplegada en el contenedor tomcat. [Estructura física] Una vez realizada la instalación de Tomcat se obtiene una estructura de directorios Tomcat entre los que destacan: - bin: ejecutables y scripts para arrancar y parar Tomcat. - common: clases y librerías compartidas entre Tomcat y las aplicaciones web. Las clases se deben colocar en common/classes, mientras que las librerías en formato JAR se deben poner en common/lib. - conf: ficheros de configuración. - logs: directorio donde se guardan por defecto los logs. - server: las clases que componen Tomcat. - shared: clases compartidas por todas las aplicaciones web. - webapps: directorio usado por defecto como raíz donde se colocan todas las aplicaciones web. - work y temp: directorios para almacenar información temporal [Configuración] (\*) %CATALINA\_HOME% es la ruta donde se ha instalado Tomcat Los aspectos de configuración más importantes se encuentran recogidos en dos ficheros situados bajo \"%CATALINA\_HOME%/conf\": - server.xml: fichero de configuración global de Tomcat. Se configura cada módulo descrito anteriormente. - web.xml: es un fichero en el formato estándar Java EE para aplicaciones web con servlets, que contiene la configuración global a todas las aplicaciones. Luego están: - tomcat-users.xml: lista de usuarios y contraseñas para autentificación. - catalina.policy: políticas de seguridad para la ejecución del servidor. Los scripts más importantes para el usuario: - Catalina: el script principal, es invocado con uno o varios argumentos; los más comunes son start, run y stop. - run: Levanta Tomcat sin redirigir la salida estándar y de errores. - start: Levanta Tomcat redirigiendo la salida estándar y de errores a un fichero log. - stop: Para Tomcat. - Startup: Arranca Tomcat en segundo plano. - Shutdown: Para Tomcat (lo apaga). También se puede utilizar un comando de Linux/Unix para arrancar servicios: systemctr {start\|stop} nombre\_servicidor Estructura de directorios de una Aplicación Web La especificación Servlet 2.2 define la estructura de directorios para los ficheros de una aplicación Web. En primer lugar, se debe especificar la ruta donde se sitúan las aplicaciones Web en el contenedor Tomcat: \%CATALINA\_HOME%/webapps Cada aplicación Web se encuentra en un directorio debajo de webapps (cada directorio debajo de webapps se denomina contexto de Tomcat). Por tanto, cada directorio corresponde a un contexto y por defecto existe un contexto ROOT. En el interior de cada contexto la estructura de directorios es siempre la misma: - Contexto, directorio superior o raíz: posee el nombre de la aplicación y define la raíz de documentos para la aplicación Web (en el caso de la ilustración corresponde con "Gestion\_GC"). - META-INF: Contiene el archivo MANIFEST.MF. - WEB-INF: contiene el fichero de configuración web.xml y los siguientes directorios: - classes: Directorio que contiene todos los servlets y cualquier otra clase de utilidad o complementaria que se necesite para la ejecución de la aplicación web. - lib: contiene las bibliotecas (comprimidas con jar) que utiliza la aplicación.

Use Quizgecko on...
Browser
Browser