Introduction à JavaEE

Aujourd'hui, nous allons parler de ce que c'est - Java EE : en quoi il consiste, quelles sont les caractéristiques de l'architecture des applications Java EE, et nous fournirons des descriptions des différentes technologies de cette plateforme. Le sujet en lui-même est vaste, mais nous ne nous arrêterons pas à l'essentiel. A la fin, nous ferons une petite comparaison de Java EE avec le Spring Framework et répondrons à la question : « quoi de mieux pour apprendre » (spoiler : bien sûr, il faut tout apprendre =) ) Commençons par les bases.

Java EE - qu'est-ce que c'est ?

Java EE est une plate-forme construite sur Java SE qui fournit une API et un environnement d'exécution pour développer et exécuter des applications réseau à grande échelle, multiniveaux, évolutives, fiables et sécurisées. De telles applications sont appelées applications d'entreprise car elles résolvent les problèmes rencontrés par les grandes entreprises. Cependant, les grandes entreprises et les agences gouvernementales ne sont pas les seules à pouvoir bénéficier de ces types d'applications et des avantages offerts par Java EE. Les solutions proposées par la plate-forme Java EE sont utiles, et parfois simplement nécessaires, pour les développeurs individuels et les petites organisations.

Développement JavaEE

Java EE est développé via le Java Community Process (JCP), créé en 1998. Il permet aux parties intéressées de participer à l'élaboration des futures versions des spécifications de la plateforme de langage Java. La base de ce processus est la JSR (Java Spécification Request), des documents formels décrivant les spécifications et les technologies qu'il est proposé d'ajouter à la plateforme Java. Ces demandes sont faites par des membres de la communauté – des développeurs ordinaires et des entreprises. Ces derniers incluent Oracle, Red Hat, IBM, Apache et bien d'autres. Ceux. les gars proposent de nouvelles fonctionnalités et des goodies qu'ils aimeraient inclure dans Java. Et puis ils procèdent à un vote, sur la base duquel une décision est prise sur ce qu'il faut inclure dans la prochaine version. L'historique des versions de Java EE ressemble à ceci :

• J2EE 1.2 (décembre 1999)
• J2EE 1.3 (septembre 2001)
• J2EE 1.4 (novembre 2003)
• Java EE 5 (mai 2006)
• Java EE 6 (décembre 2009)
• Java EE 7 (mai)
• Java EE 8 (août 2017)
• Jakarta EE 8 (septembre 2019)

En 2017, une nouvelle étape dans le développement de la plateforme a été franchie : Oracle a transféré le contrôle du développement de Java EE à la Fondation Eclipse. Et en avril 2018, Java EE a été renommé Jakarta EE, qui est entièrement compatible avec Java EE 8.

Architecture des applications Java EE

Une brève introduction. Pour faciliter la compréhension, parlons de la structure des applications Java EE et de certains des termes que nous utiliserons plus loin. Les applications Java EE ont une structure qui présente deux qualités clés :

• Premièrement, à plusieurs niveaux. Les applications Java EE sont à plusieurs niveaux, et nous en parlerons plus en détail ;
• deuxièmement, la nidification. Il existe un serveur Java EE (ou serveur d'applications), avec des conteneurs de composants situés à l'intérieur. Ces conteneurs abritent (bingo !) des composants.

Pour expliquer l'architecture des applications Java EE, parlons d'abord des couches. Quels sont les niveaux ? Quelles technologies Java EE sont utilisées à différents niveaux ? Nous verrons ensuite comment les serveurs d'applications, les conteneurs de composants et les composants eux-mêmes sont interconnectés. Mais gardez à l’esprit que ce sont toutes des vues sous différents angles de la même chose, et que l’ordre n’est pas si important ici.

Niveaux d'application

Les applications multi-niveaux sont des applications divisées selon des principes fonctionnels en modules isolés (niveaux, couches). Généralement (y compris dans le contexte du développement Java EE), les applications d'entreprise sont divisées en trois niveaux :

• client;
• niveau moyen;
• niveau d'accès aux données.

1. La couche client est une application qui demande des données au serveur Java EE (couche intermédiaire). Le serveur, à son tour, traite la demande du client et lui renvoie une réponse. L'application client peut être un navigateur, une application autonome (mobile ou de bureau) ou d'autres applications serveur sans interface graphique.

2. Le niveau intermédiaire est divisé, à son tour, en niveau Web et niveau logique métier.

   1. La couche Web se compose de certains composants qui assurent l'interaction entre les clients et la couche de logique métier.

      Les technologies Java EE suivantes sont utilisées au niveau Web :

      • Technologie JavaServer Faces (JSF);
      • Pages du serveur Java (JSP) ;
      • Langage d'expression (EL);
      • Servlets ;
      • Contextes et injection de dépendances pour Java EE (CDI).

   2. La couche de logique métier est constituée de composants qui implémentent toute la logique métier de l'application. La logique métier est un code qui fournit des fonctionnalités qui couvrent les besoins d'un domaine d'activité spécifique (secteur financier, banque, commerce électronique). Ce niveau peut être considéré comme le cœur de l’ensemble du système.

      Technologies impliquées à ce niveau :

      • Entreprise JavaBeans (EJB) ;
      • Services Web RESTful JAX-RS ;
      • Entités API de persistance Java ;
      • Service de messagerie Java.

3. Niveau d'accès aux données. Ce niveau est parfois appelé niveau des systèmes d'information d'entreprise (EIS). EIS se compose de divers serveurs de bases de données, de systèmes de planification des ressources d'entreprise ERP (Enterprise Resource Planning) et d'autres sources de données. La couche de logique métier accède à cette couche pour les données.

   A ce niveau, vous pouvez trouver des technologies telles que :

   • API de connectivité de base de données Java (JDBC) ;
   • API de persistance Java ;
   • Architecture de connecteur Java EE ;
   • API de transactions Java (JTA).

Serveurs d'applications, conteneurs, composants

Jetons un coup d'œil à la définition de Java EE sur Wikipédia. Java EE est un ensemble de spécifications et de documentation associée pour le langage Java, décrivant l'architecture de la plateforme serveur pour les tâches des moyennes et grandes entreprises. Pour mieux comprendre ce que signifie dans ce contexte un « ensemble de spécifications », faisons une analogie avec une interface Java. L'interface Java elle-même est dépourvue de fonctionnalités. Il définit simplement un contrat selon lequel certaines fonctionnalités sont implémentées. Mais d'autres classes implémentent l'interface. De plus, une interface peut avoir plusieurs implémentations, chacune pouvant différer les unes des autres sur certains détails. Avec les spécifications, tout est exactement pareil. Naked Java EE n'est qu'un ensemble de spécifications. Ces spécifications sont implémentées par différents serveurs Java EE. Un serveur Java EE est une application serveur qui implémente les API de la plateforme Java EE et fournit des services Java EE standard. Les serveurs Java EE sont parfois appelés serveurs d'applications. Les données du serveur peuvent contenir des composants d'application, chacun correspondant à son propre niveau dans une hiérarchie à plusieurs niveaux. Le serveur Java EE fournit divers services à ces composants sous la forme d'un conteneur. Les conteneurs constituent l'interface entre les composants qu'ils hébergent et la fonctionnalité de bas niveau indépendante de la plate-forme qui prend en charge le composant. Les conteneurs fournissent des services spécifiques aux composants qu'ils hébergent. Par exemple, la gestion du cycle de vie du développement, l’injection de dépendances, la concurrence, etc. Les conteneurs masquent la complexité technique et augmentent la portabilité. Il existe quatre types différents de conteneurs dans Java EE :

1. Les conteneurs d'applets sont implémentés par la plupart des navigateurs. Lors du développement d'applets, vous pouvez vous concentrer sur le côté visuel de l'application, tandis que le conteneur offre un environnement sécurisé.

2. L'Application Client Container (ACC) contient un ensemble de classes Java, de bibliothèques et d'autres fichiers nécessaires à la mise en œuvre de fonctionnalités telles que l'injection, la gestion de la sécurité et les services de noms dans les applications Java SE.

3. Le conteneur Web fournit les services de base pour la gestion et l'exécution des composants Web (servlets, composants EJB Lite, pages JSP, filtres, écouteurs, pages JSF et services Web). Il est responsable de l'instanciation, de l'initialisation et de l'appel des servlets, ainsi que de la prise en charge des protocoles HTTP et HTTPS. Ce conteneur est utilisé pour servir des pages Web aux navigateurs clients.

4. Le conteneur EJB (Enterprise Java Bean) est responsable de la gestion et de l'exécution des composants du modèle EJB qui contiennent la couche de logique métier de l'application. Il crée de nouvelles entités de bean EJB, gère leur cycle de vie et fournit des services tels que des capacités de transaction, de sécurité, de concurrence, de distribution, de dénomination ou d'appel asynchrone.

Également dans Java EE, il existe quatre types de composants qu'une implémentation de la spécification Java EE doit prendre en charge :

1. Les applets sont des applications d'interface utilisateur graphique (GUI) qui s'exécutent dans un navigateur. Ils exploitent la riche API Swing pour produire des interfaces utilisateur puissantes.

2. Les applications sont des programmes qui s'exécutent côté client. Il s'agit généralement d'une interface utilisateur graphique (GUI) utilisée pour le traitement par lots.

3. Applications Web (composées de servlets et de leurs filtres, écouteurs d'événements Web, pages JSP et JSF) - s'exécutent dans un conteneur Web et répondent aux requêtes HTTP des clients Web. Les servlets prennent également en charge les points de terminaison des services Web SOAP et RESTful.

4. Les applications d'entreprise (construites avec Enterprise Java Beans, Java Message Service, Java Transaction API, Asynchronous Calls, Time Services) s'exécutent dans un conteneur EJB. Les EJB gérés par conteneur gèrent la logique métier transactionnelle. Ils sont accessibles localement ou à distance via RMI (ou HTTP pour les services Web SOAP et RESTful).

Le diagramme ci-dessous montre une architecture d'application Java EE typique :

Les technologies

Nous avons donc réglé l'architecture. La structure globale doit être claire. Dans le processus de description des composants architecturaux, nous avons abordé certaines technologies Java EE telles que EJB, JSP, etc. Le tableau ci-dessous présente les technologies utilisées principalement au niveau client : Le tableau ci-dessous présente les technologies utilisées au niveau de la logique métier : Le tableau ci-dessous présente les technologies utilisées au niveau de la couche d'accès aux données :

Java EE et Spring

Le Spring Framework est considéré comme un concurrent de Java EE. Si l’on regarde le développement de ces deux plateformes, une image intéressante se dégage. Les premières versions de Java EE ont été créées avec la participation d'IBM. Ils se sont avérés sympas, mais encombrants, lourds et peu pratiques à utiliser. Les développeurs ont eu des difficultés en raison de la nécessité de conserver un grand nombre de fichiers de configuration et d'autres raisons qui compliquent le développement. Au même moment, Spring IoC était né. C'était une petite bibliothèque belle et facile à utiliser. Il utilisait également un fichier de configuration, mais contrairement à Java EE, il n’y en avait qu’un. La simplicité de Spring a conduit au fait que presque tout le monde a commencé à utiliser ce framework dans ses projets. Et puis Spring et Java EE ont commencé leur chemin vers la même chose, mais à partir de buts différents. Pivotal Software, le développeur de Spring, a commencé à publier projet après projet pour couvrir tous les besoins possibles et impossibles des développeurs Java. Peu à peu, ce qui s'appelait auparavant Spring est d'abord devenu l'un des projets, puis a complètement fusionné avec plusieurs autres projets de Spring Core. Tout cela a conduit à l’inévitable complication de Spring par rapport à ce qu’il était à l’origine. Au fil du temps, il est devenu très difficile de suivre l'ensemble des dépendances de Spring, et le besoin s'est fait sentir d'une bibliothèque distincte qui chargerait et exécuterait tout lui-même (maintenant, le Spring Boot bien-aimé a hoché quelque part). Pendant tout ce temps, JCP a travaillé sur une chose : parvenir à une simplification maximale de tout ce qui est possible dans Java EE. De ce fait, dans un EJB moderne, pour décrire un bean, il suffit de spécifier une annotation au dessus de la classe, ce qui donne au développeur accès à toute la puissance de la technologie Enterprise Java Beans. Et des simplifications similaires ont affecté chaque spécification de Java EE. En conséquence, Spring et Java EE sont à peu près à parité en termes de fonctionnalités. Certaines choses sont meilleures, d’autres pires, mais si l’on regarde globalement, il n’y a pas de grandes différences. Il en va de même pour la complexité du travail. Spring et Java EE sont tous deux d'excellents outils. Peut-être le meilleur qui existe actuellement pour créer des applications réseau d’entreprise en Java. Cependant, Java EE ne peut généralement fonctionner qu'au sein du serveur d'applications d'entreprise (Tomcat n'en est pas un), et une application sur la pile Spring peut s'exécuter sur n'importe quoi (sur le même Tomcat), et même sans serveur du tout (puisqu'elle s'exécutera). il en lui-même indépendamment). Cela fait de Spring un outil idéal pour développer de petites applications GUI frontales ou des architectures de microservices. Mais l'élimination de la dépendance aux serveurs d'applications a eu un impact négatif sur l'évolutivité des applications Spring. Et Java EE est bien adapté à la mise en œuvre d’une application de cluster monolithique évolutive. Les développeurs familiers avec Spring Framework sont actuellement plus demandés sur le marché du travail. C'est ainsi que cela s'est passé historiquement : à une époque où Java EE était trop compliqué, Spring "a gagné une clientèle". Et pourtant, il n'y a pas de réponse claire à la question de savoir quoi apprendre Spring ou Java EE. Un débutant peut recevoir les conseils suivants. Familiarisez-vous (au moins superficiellement) avec les deux plateformes. Écrivez un petit projet domestique en Java EE et Spring. Et puis approfondissez le cadre qui sera nécessaire au travail. En conséquence, basculer entre Spring et Java EE ne sera pas difficile.

Résultats

Bien entendu, un sujet à grande échelle ne peut être traité dans un seul article ! Après une tonne de nouveaux termes, vous souhaiterez probablement « appliquer » ces connaissances à un exemple réel. Nous continuerons donc à étudier Java EE : vous trouverez des leçons pratiques sur la mise en place d'un environnement local pour le développement Java EE dans le prochain article.