EAR (format de fichier)

Un article de Wikipédia, l'encyclopédie libre.

EAR (Enterprise ARchive)
Extension de fichier :	`.ear`
Type MIME :	`application/java-archive`
Développé par :	Sun Microsystems
Type de format :	Archive (avec Compression de données)
Conteneur de fichiers :	Modules Java
Extension du :	ZIP

Un EAR (pour Enterprise ARchive) est un format de fichier utilisé par Java EE pour empaqueter un ou plusieurs 'modules' dans une seule archive, de façon à pouvoir déployer ces modules sur un serveur d'applications en une seule opération, et de façon cohérente. Ces archives contiennent aussi des fichier XML appelés descripteurs de déploiement, qui indiquent comment les modules doivent être déployés sur le serveur.

Sommaire

1 Structure du fichier
2 Les modules
- 2.1 Isolement des classes
- 2.2 Le répertoire META-INF
3 Voir aussi
4 Notes et références
5 Liens externes

[modifier] Structure du fichier

Un fichier EAR est un JAR standard, dont l'extension a été changé en .ear. il contient un ou plusieurs répertoires contenant les modules de l'application, ainsi qu'un répertoire META-INF contenant les méta données, c'est à dire les fichiers descripteurs de déploiement.

[modifier] Les modules

Différentes éléments peuvent être contenus dans un fichier EAR, pour être déployés sur le serveur :

Une archive d'application web, avec une extension .war. C'est un élément consistant en un ou plusieurs composants de l'application web (répertoires et fichiers), et son descripteur de déploiement spécifique (contenu dans un répertoire WEB-INF).
Des classes Java, groupés dans des archives .jar.
Un module Enterprise JavaBean dans une archive .jar, qui contient dans son propre répertoire META-INF son descripteur de déploiement spécifique. Une fois déployés, ces beans sont visibles aux autres composants.
Eventuellement, un Resource Adapter (connecteur) dans un fichier .rar.

[modifier] Isolement des classes

La plupart des serveurs d'application chargent les classes d'un EAR par un arbre de classloaders isolant les exécutions des applications entre elles, mais permettant le partage des classes entre les modules à l'intérieur de l'application elle même. Ainsi, un code présent dans un JAR pourra être utilisé par toutes les webapps de l'application, mais pas par celles déployées depuis un autre EAR. Une des raisons les plus importantes expliquant cet isolement est de permettre la séparation complète entre applications qui utilisent des singletons statiques (par exemple ceux présents dans Log4J, souvent inclus dans les applications). Cette séparation évite que des configurations statiques se mélangent. Une autre raison pratique est de permettre l'utilisation de différentes versions d'une même librairie dans des applications déployées sur le même serveur.

[modifier] Le répertoire META-INF

Ce répertoire contient au moins le fichier de description de déploiement application.xml, qui indique la méthode d'installation des modules sur le serveur. Il contient les balises XML suivantes:

icon, qui indique l'emplacement pour les logos de l'application. Une différenciation est faite entre small-icon et large-icon.
display-name, qui indique le nom de l'application
description, qui indique une description sommaire de l'application
Une balise module pour chaque module contenu dans l'archive
Une ou plusieurs balises security-role définissant les rôles pour la sécurité générale de l'application

Chaque balise module contient une balise ejb, web ou java qui indique quel type de module est présent, et qui le décrit. Les modules pour les applications webs contiennent en plus la balise context-root qui spécifie l'URL permettant aux utilisateurs d'y accéder.

En plus de ce descripteur de déploiement peuvent se trouver un ou plusieurs descripteurs d'exécution spécifiant des paramètres additionnels à utiliser lors de l'exécution de la JVM.