EAR ( E p. De aplicación a R chive ) es un formato de archivo utilizado por Java EE para empaquetar uno o más módulos en un único archivo, de modo que el despliegue de los diversos módulos en un servidor de aplicaciones se realiza de manera simultánea y coherente. También contiene archivos XML llamados descriptores de implementación que describen cómo implementar los módulos.
Ant, Maven o Gradle se pueden usar para construir archivos EAR.
Estructura de archivo
- ¿Puede una startup tecnológica obtener fondos solo con una aplicación web antes de crear las aplicaciones móviles?
- ¿Por qué son importantes las pruebas de seguridad de aplicaciones web?
- ¿Qué marco sería mejor para construir una aplicación web empresarial?
- Estoy buscando patrones de IU útiles que faciliten la creación de un objeto complejo o actividad de entidad / registro de cambios para un CRM. Las entidades incluyen un cliente potencial (cliente futuro o actual) con sus datos personales, direcciones de envío, pedidos, conversaciones por correo electrónico, teléfono y mensajes de texto, etc. ¿Cómo hago esto?
- Cómo hacer un plan y crear una estructura para mi aplicación web
Un archivo EAR es un archivo JAR estándar (y, por lo tanto, un archivo Zip) con una extensión .ear, con una o más entradas que representan los módulos de la aplicación, y un directorio de metadatos llamado META-INF que contiene uno o más descriptores de implementación.
Módulo [ editar ]
Los desarrolladores pueden incrustar varios artefactos dentro de un archivo EAR para su implementación por los servidores de aplicaciones:
- Un módulo web tiene una extensión .war. Es una unidad desplegable que consta de uno o más componentes web, otros recursos y un descriptor de implementación de aplicaciones web. El módulo web está contenido en una jerarquía de directorios y archivos en un formato estándar de aplicación web.
- Las clases de POJO Java pueden implementarse en archivos .jar.
- Un módulo Enterprise Java Bean tiene una extensión .jar y contiene en sus propios
META-INFdirectorioMETA-INFque describen las clases persistentes implementadas. Los beans de entidad desplegados se vuelven visibles para otros componentes y, si se exportan de forma remota, a clientes remotos. Los beans de mensaje y los beans de sesión están disponibles para acceso remoto. - Un módulo Adaptador de recursos tiene una extensión .rar.
Aislamiento de clase
La mayoría de los servidores de aplicaciones cargan clases desde un archivo EAR desplegado como un árbol aislado de cargadores de clases Java, aislando la aplicación de otras aplicaciones, pero compartiendo clases entre módulos desplegados. Por ejemplo, un archivo WAR desplegado podría crear instancias de clases definidas en un archivo JAR que también se incluye en el archivo EAR que contiene, pero no necesariamente en los archivos JAR de otros archivos EAR. Una razón clave para este comportamiento es permitir la separación completa entre aplicaciones que usan singletons estáticos (por ejemplo, Log4J), lo que de otro modo confundiría la configuración entre aplicaciones separadas. Esto también permite implementar diferentes versiones de aplicaciones y bibliotecas en paralelo.
Los servidores de aplicaciones JBoss anteriores a la Versión 5 fueron notables porque no aíslan los componentes implementados. Una aplicación web implementada en un archivo EAR tendría acceso a clases en otros archivos EAR y WAR. Esta es una política algo controvertida. El diseño de Unified Classloader reduce la sobrecarga de comunicaciones entre las aplicaciones en ejecución, ya que los datos de clase se pueden compartir por referencia o copias simples. También permite a los desarrolladores evitar tener que comprender los problemas que puede crear un árbol de cargadores de clases. Sin embargo, evita que se implementen diferentes versiones de bibliotecas dependientes en aplicaciones separadas. JBoss 4.0.2 cambió a un cargador de clases jerárquico, pero en la versión 4.0.3 volvió a un cargador de clases unificado por razones de compatibilidad con versiones anteriores. Ahora hay una opción de configuración para cambiar este comportamiento. JBoss 5.x, 6.xy 7.x ya no utilizan la carga de clase unificada.
Directorio META-INF
El directorio META-INF contiene al menos el descriptor de implementación application.xml , conocido como Java EE Deployment Descriptor . Contiene las siguientes entidades XML:
-
icon, que especifica las ubicaciones de las imágenes que representan la aplicación. Se realiza una subdivisión parasmall-iconlarge-icon. -
display-name, que identifica la aplicación -
description - Un elemento de
modulepara cada módulo en el archivo - Cero o más elementos de
security-rolepara los roles de seguridad global en la aplicación
Cada elemento del module contiene un elemento ejb , web o java que describe los módulos individuales dentro de la aplicación. Los módulos web también proporcionan una context-root que identifica el módulo web por su URL.
Junto al descriptor de despliegue de Java EE puede haber cero o más descriptores de despliegue en tiempo de ejecución . Estos se utilizan para configurar parámetros Java EE específicos de la implementación.
