Outre l'utilisation de serveurs d'application traditionnels, qui ne sont pas vraiment très lourds, vous pouvez goûter à une autre saveur de Java EE, appelée microconteneurs.
Java EE n'est qu'un ensemble de normes. Une norme se traduit par une spécification d'API, que chacun est ensuite libre de mettre en œuvre. Un serveur d'application (AS) est principalement une collection affinée de cette fonctionnalité. Ces API n'ont pas été créées sans raison. Elles représentent des fonctionnalités couramment utilisées dans les projets. Le serveur d'application peut être considéré comme un ensemble de ces fonctionnalités. Cette approche présente de nombreux avantages - AS a de nombreux utilisateurs, il est donc bien testé au fil du temps. Le câblage des fonctionnalités par vos propres moyens peut entraîner des bogues.
Quoi qu'il en soit, une nouvelle ère est arrivée, où avec Docker, l'application emporte ses dépendances avec elle. Dans de nombreux cas, il n'est plus nécessaire d'avoir un serveur d'application complet avec toutes les fonctionnalités prêtes à être servies aux applications. Par le passé, le serveur d'application ne savait pas exactement de quels services les applications déployées auraient besoin. Par conséquent, tout était intégré. Parmi les services les plus innovants, on peut citer Vol à l'air libre n'a instancié que les services nécessaires. Il existe également des profils Java EE qui facilitent quelque peu la tâche du serveur d'application monolithique.
Actuellement, nous livrons généralement l'application avec ses dépendances (JDK, bibliothèques, AS) à l'intérieur d'un Docker - ou nous nous y dirigeons. Par conséquent, un effort pour regrouper exactement la bonne quantité de est un choix logique. Mais, et c'est un "grand mais", le besoin de fonctionnalité de l'AS est toujours d'actualité. C'est toujours une bonne idée de développer une fonctionnalité commune basée sur des normes et des efforts communs. Seulement, il ne semble plus possible de les distribuer sous la forme d'un gros paquet, en laissant potentiellement la plupart des API inactives. Cet effort porte de nombreux noms, qu'il s'agisse de microconteneurs, de créateurs d'uberjar ...
Il existe des serveurs Java EE si légers qu'il est difficile d'utiliser autre chose. * Spring Boot n'est pas basé sur Java EE et dans la configuration par défaut présente dans le guide de démarrage, Tomcat est utilisé en interne.
L'essentiel est que votre application Java EE soit développée comme une application Java EE indépendante. Ces micro-solutions sont chargées de l'envelopper d'une fonctionnalité "juste suffisante". C'est, du moins à mon humble avis, la bonne façon de procéder. De cette manière, vous conserverez la compatibilité avec les AS complets et les micro-solutions. L'uber-jar, qui contient toutes les dépendances, peut être créé pendant ou après le processus de construction.
WildFly Swarm ou Payara Micro sont capables de "scanner" l'application, en n'exécutant que les services nécessaires. Pour une application réelle, l'empreinte mémoire en production peut être aussi faible que 100 Mo - pour une application réelle. C'est probablement ce que vous souhaitez. Spring Boot peut faire des choses similaires, si vous avez besoin de Spring. Cependant, d'après mon expérience, Spring Boot est beaucoup plus lourd et gourmand en mémoire que le Java EE moderne, car il contient évidemment Spring, donc si vous êtes un utilisateur de Java EE, vous ne pouvez pas vous en passer. recherche de légèreté en termes de consommation de mémoire, essayez Java EE, en particulier WildFly Swarm (ou WildFly pur) et Payara Micro. Ce sont mes AS préférés et ils peuvent être très, très petits. Je dirais que WildFly Swarm est beaucoup plus facile à démarrer, Payara Micro nécessite plus de lecture, mais offre des fonctionnalités intéressantes. Les deux peuvent fonctionner comme un wrapper - vous pouvez simplement envelopper votre projet actuel avec eux après la phase de construction, pas besoin de changer quoi que ce soit.
Payara Micro even fournit des images Docker prêt à l'emploi ! Comme vous pouvez le voir, Java EE est mature et prêt à entrer dans les terres de Docker :)
L'une des ressources les plus fiables et les plus intéressantes est celle d'Adam Bien. Vidéo sur les micro/nanoservices Java EE . Jetez un coup d'œil.
