Format binaire Java
Format JAR
Le format JAR (Java ARchive) pour les fichiers à l'extension *.jar
est le format le plus rependu dans le monde Java.
Il s'agit simplement d'une archive type ZIP contenant le code Java compilé (fichier à l'extension .class
).
Par défaut, il est utilisé pour former des bibliothèques logicielles pour d'autres applications.
Variante exécutable
Suivant les métadonnées renseignées lors de la compilation un fichier JAR peut se comporter comme un programme exécutable. Voici comment l'exécuter en ligne de commande:
java -jar my-app.jar
Variante EJB
Pour les projets utilisant les technologies Jakarta EE, notamment la technologie EJB: Enterprise Java Bean, le format JAR est également utilisé, mais les métadonnées sont différentes.
Source: Oracle
Par exemple, on peut encore identifier la présence du fichier ejb-jar.xml dans le code compilé.
Format WAR
Le format WAR pour Web application ARchive ou fichier portant l'extension *.war
, est utilisé généralement pour la conception d'application web en Java.
Pour fonctionner, ce type de fichier doit être déployé sur un serveur d'applications Java tel que Wildfly, Glassfish, Payara, WebLogic ou encore Tomcat.
Source: Oracle
Dans ce type d'archive, on retrouve:
* Les métadonnées (fichiers XML)
* Le code Java compilé.
* Les ressources web: JSP, JSPX, XHTML, HTML, CSS, JavaScript.
* Les ressources statiques : images, polices d'écriture...
* Les autres dépendances logicielles sous forme de JAR dans un sous-dossier lib
.
Format EAR
Il signifie Enterprise ARchive pour les fichiers à l'extension *.ear
.
Ce format est exclusif aux applications Jarkarta EE et il ne peut uniquement être déployé sur des serveurs d'applications supportant pleinement la plateforme Jakarta EE.
Source: Oracle
Cette archive est en réalité un regroupement :
- De métadonnées (fichier XML)
- De modules EJB
- De modules WAR
- De modules RAR
- De modules client JAR
- Des autres dépendances logicielles sous forme de JAR.
Note Les archives RAR (Resource Adapter ARchive) à l'extension
*.rar
sont d'anciennes archives de l'écosystème Java EE contenant des fichiers spécifiques à un environnement ou à une architecture. Ce type de module est en désuétude, de même que les modules clients JAR.
Philosophie de construction
Dans un projet de type EAR chaque module à des fonctions bien définies.
Les modules EJB représente la partie de traitement côté serveur où le traitement métier est effectué ainsi que la sauvegarde en base de données. En général pour de grande application, on crée un module EJB par zone fonctionnelle.
Les modules WAR représente la partie client léger de l'application, il peut s'agit d'une application servant des pages web ou d'une application de type SOAP ou REST. On crée un module WAR par zone fonctionnelle et/ou par catégorie d'interface (interface web, REST, SOAP...).
Exemple : Dans un site marchand, on peut imaginer la gestion de stock et la préparation d'une commande comme deux zones fonctionnelles distinctes. Ainsi, nous avons deux modules EJB pour le traitement métier et au moins deux modules WAR pour la partie cliente. (Je précise au moins, car on pourrait imaginer pour un module EJB avoir une partie accessible à travers des pages web et une autre à travers une API REST, soit deux modules WAR).
Cela permet un découpage logiciel plus propre. À l'avenir, il est d'autant plus simple de découper l'applicatif si l'on considère le découpage micro-service.