EAR ( E nterprise A pplication a R chive ) es un formato de archivo utilizado por Java EE para empaquetar uno o más módulos en un solo archivo de modo que la implementación de los diversos módulos en un servidor de aplicaciones se realice de manera simultánea y coherente. También contiene archivos XML llamados descriptores de implementación que describen cómo implementar los módulos.
Extensión de nombre de archivo | .oído |
---|---|
Tipo de medio de Internet | aplicación / java-archive |
Desarrollado por | Microsistemas solares |
Tipo de formato | archivo de archivos , compresión de datos |
Extendido desde | FRASCO |
Ant , Maven o Gradle se pueden utilizar para crear archivos EAR.
Estructura de archivo
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
Los desarrolladores pueden incrustar varios artefactos en un archivo EAR para que los servidores de aplicaciones los implementen:
- Un módulo web tiene una extensión .war . Es una unidad implementable que consta de uno o más componentes web, otros recursos y un descriptor de implementación de la aplicación web . El módulo web está contenido en una jerarquía de directorios y archivos en un formato de aplicación web estándar.
- Las clases de POJO Java se pueden implementar en archivos .jar .
- Un módulo Enterprise Java Bean tiene una extensión .jar y contiene en su propio
META-INF
directorio descriptores que describen las clases persistentes implementadas. Los beans de entidad implementados se vuelven visibles para otros componentes y, si se exportan de forma remota, para los clientes remotos. Message Beans y Session Beans están disponibles para acceso remoto. - Un módulo Adaptador de recursos tiene una extensión .rar .
Aislamiento de clases
La mayoría de los servidores de aplicaciones cargan clases desde un archivo EAR implementado como un árbol aislado de cargadores de clases Java , aislando la aplicación de otras aplicaciones, pero compartiendo clases entre módulos implementados. Por ejemplo, un archivo WAR implementado podría crear instancias de clases definidas en un archivo JAR que también se incluyó en el archivo EAR que lo 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), que de otra manera confundirían la configuración entre aplicaciones separadas. Esto también permite implementar en paralelo diferentes versiones de aplicaciones y bibliotecas.
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 las clases de otros archivos EAR y WAR. Esta es una política algo controvertida. El diseño del cargador de clases unificado reduce la sobrecarga de comunicaciones entre las aplicaciones en ejecución, ya que los datos de la 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 independientes. 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 clases unificada.
Directorio META-INF
El META-INF
directorio contiene al menos el application.xml
descriptor de implementación, conocido como Descriptor de implementación de Java EE . 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-icon
ylarge-icon
.display-name
, que identifica la aplicacióndescription
- Un
module
elemento para cada módulo del archivo. - Cero o más
security-role
elementos para los roles de seguridad global en la aplicación
Cada module
elemento contiene una ejb
, web
o java
elemento 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 implementación de Java EE, puede haber cero o más descriptores de implementación en tiempo de ejecución . Se utilizan para configurar parámetros Java EE específicos de la implementación.