Principes de conception prévus pour Jakarta EE

Bonjour, Habr! Nous avons récemment publié le livre « Learning Java EE. Modern Programming for Large Enterprises » du champion allemand de Java Sebastian Dashner.


M. Dashner écrit et parle activement sur des sujets liés à Java EE moderne, donc son blog n'a pas ignoré les principes généraux de conception de la plate-forme Jakarta EE, désormais développée par Eclipse. La traduction de cet article (juin) que nous portons à votre attention aujourd'hui.

La plate-forme Jakarta EE prend progressivement le relais et de nouvelles spécifications pour le développement des entreprises émergent avec elle. Pour se mettre d'accord sur les différentes normes et technologies qui sont sur le point d'émerger, la communauté Java EE entière n'en bénéficiera que si les principes généraux de conception des spécifications Jakarta EE sont développés.

Je crois que la technologie Java EE a connu un tel succès avec seulement quelques principes. Ci-dessous, je présenterai mon point de vue sur les principes de conception développés en Java EE qui me semblent les plus importants, qui méritent une étude plus approfondie et peuvent potentiellement servir de recommandations pour la conception à Jakarta EE.

J'ai décidé d'écrire cet article, inspiré par les propositions de Dmitry Kornilov sur la direction dans laquelle le développement technique de Jakarta EE devrait aller.

La première chose est la logique métier

Le modèle de programmation adopté en Java EE permet au développeur de se concentrer exactement sur ce qui est requis, c'est-à-dire sur la logique métier. Vous n'avez plus besoin d'hériter des classes d'API; le développeur peut exprimer la logique de son domaine dans le langage Java habituel et contrôler de manière prédominante (à l'aide d'annotations) le comportement du serveur d'applications. Ainsi, le cadre s'intègre de manière transparente dans votre code et, en substance, il est tout aussi facile à supprimer de là. Lors de la conception, ne comptez pas sur la réutilisation, mais sur un retrait facile.

Cependant, les implémentations devraient soulager au maximum le développeur du travail le plus difficile, c'est-à-dire lui permettre d'échapper aux exigences techniques qui ne sont pas liées à la logique métier. Les exemples sont le multithreading, les transactions, l'inversion de contrôle ou le traitement des requêtes HTTP. Côté application, c'est ennuyeux :)

Il me semble important que le cadre n'interfère pas seulement avec la mise en œuvre de la logique métier, mais encourage également les programmeurs à mettre rapidement en production les fonctionnalités développées. Il n'est pas nécessaire de peaufiner le cadre pour qu'il brille - il vaut mieux amener le code de la logique métier à l'idéal. Comparez Java EE ou Spring moderne avec les anciennes versions de J2EE - je pense que vous comprendrez immédiatement ce que je veux dire.

Jakarta EE devrait évoluer dans le même esprit et, par conséquent, se concentrer sur les spécifications qui permettront aux développeurs de mettre en œuvre rapidement la logique métier.

Conventions de configuration

Java EE minimise la configuration requise pour définir une application d'entreprise typique. Dans la plupart des situations pratiques, les accords fonctionnent dès la sortie de l'emballage, aucune configuration n'est requise. Ainsi, vous n'avez plus besoin de fichiers XML pour configurer une simple application Java EE. Un autre exemple est que JAX-RS fournit des codes de réponse HTTP par défaut qui correspondent aux valeurs de retour des méthodes JAX-RS.

Java EE a la flexibilité de modifier le comportement et d'implémenter des scripts plus complexes; cependant, il n'y a pas d'accord à ce sujet.
Jakarta EE doit continuer de transformer le simple en facile et le complexe en possible.

Spécifications d'interopérabilité

Jakarta EE devrait poursuivre et étendre l'interopérabilité des spécifications. Java EE est conforme aux spécifications existantes et aux fonctionnalités présentes qui font déjà partie de la norme.

Les développeurs peuvent s'appuyer sur des spécifications disparates pour bien interagir les uns avec les autres, sans aucune configuration requise. Normes exigées: si l'environnement d'exécution prend en charge à la fois la spécification A et la spécification B, alors A + B doit interagir les uns avec les autres. Exemples: la validation des composants, JAXB ou JSON-B peut être utilisée dans les classes de ressources JAX-RS, et aucune configuration supplémentaire n'est requise.

Injection de dépendance et CDI

Bien sûr, il n'est pas souhaitable que Jakarta EE réinvente les choses qui existent déjà - par exemple, l'injection de dépendance liée à l'ICD. Il est souhaitable que les spécifications utilisent et soulignent les points forts du JSR 330 ou, si nécessaire, du CDI.

Un exemple UriInfo est l'utilisation d' UriInfo de JAX-RS dans les méthodes de ressources. Annotation @Inject ne prend pas encore en charge la mise en œuvre de ce type de méthode. Il est plus pratique pour le programmeur de travailler, plus il s'appuie sur le mécanisme universel.

Une autre mesure spécifique est la suivante: les fournisseurs CDI doivent être fournis dans les spécifications et, si nécessaire, des qualificatifs typesafe pour les types à créer. Ainsi, pour le moment, l'instance du client JAX-RS ne peut être obtenue que par programme, via l'API ClientBuilder . Les fabricants et qualificateurs simplifient le travail d'un programmeur en fournissant des définitions déclaratives.

Approches déclaratives

Pour tout cela, l'API Java EE s'appuie fortement sur une approche déclarative, tout en utilisant l'inversion de contrôle. Ainsi, les développeurs n'appellent pas directement la fonctionnalité; le conteneur est responsable de l'appel de la fonctionnelle, tandis que nous nous appuyons sur les définitions de code. Des exemples (à partir des spécifications les plus récentes) sont JAX-RS, JSON-B ou CDI.

Jakarta EE fournit non seulement des API logicielles plus complètes, mais devrait également faciliter l'utilisation des définitions déclaratives et des inversions de contrôle.

Stratégies de déploiement

Une caractéristique distinctive (et à mon avis, un grand avantage) de Java EE est que le modèle de déploiement proposé ici, dans lequel les problèmes de logique métier se dissocient de la mise en œuvre. Le développeur programme exclusivement pour l'API, qui ne fait pas partie de l'artefact de déploiement et est implémentée par le conteneur d'application.
Ces artefacts de déploiement compacts simplifient et accélèrent la livraison des programmes, y compris l'assemblage, la publication et le déploiement en tant que tels. Ils sont également compatibles avec les niveaux du système de fichiers conteneur utilisé, par exemple, dans Docker. Au cours du processus d'assemblage, il vous suffit de reconstruire ou de soumettre à nouveau les éléments modifiés.

Idéalement, les artefacts de déploiement ne devraient contenir que la logique métier et rien d'autre; Les implémentations d'exécution et les bibliothèques tierces éventuellement ajoutées sont fournies à un niveau inférieur, par exemple, dans les bibliothèques du serveur d'applications ajoutées à l'étape précédente de l'assemblage du conteneur.

Dans Jakarta EE, les artefacts déployés doivent également être considérés comme des entités de première classe. Il sera peut-être possible de resserrer davantage l'environnement d'exécution en fonction des spécifications requises par l'application. Cependant, Jakarta EE s'attend à accorder une attention maximale à la logique métier et à la productivité du développeur, et le raffinement du temps d'exécution est déjà secondaire.

Testabilité

En appliquant les principes ci-dessus, notamment en privilégiant la programmation déclarative et l'injection de dépendances, nous améliorons la testabilité du code métier. Ainsi, les développeurs peuvent instancier directement des objets dans des scripts de test, car vous n'avez plus besoin d'hériter des classes d'API ni d'appeler des fonctionnalités gênantes que vous auriez dû simuler auparavant.

Cependant, à Jakarta EE, il est nécessaire d'affiner sérieusement la standardisation des tests d'intégration au niveau du code, afin qu'elle ne dépende pas du fabricant. Auparavant, c'était exactement ce à quoi vous deviez faire face lorsque vous travailliez avec Arquillian. Dans les projets réels, une telle norme serait utile, ce qui vous permet de déclarer uniquement des scénarios de déploiement de test et d'appeler des fonctionnalités pour un ou plusieurs composants. Plus tôt, j'ai écrit que je ne considère pas les tests d'intégration au niveau du code comme extrêmement importants, par exemple, lors de l'exécution d'une application dans des conteneurs intégrés. Cependant, si vous standardisez les tests d'intégration au niveau du code, cela aura clairement un effet positif.

Conclusion

Je pense que ce n'est pas un hasard si les API Java EE sont si largement utilisées dans les projets réels: ces API sont bien pensées et conçues selon des principes clairs, grâce auxquelles il a été possible d'unifier non seulement une seule spécification, mais une plate-forme entière. Ils vous permettent d'utiliser plusieurs spécifications à la fois, dans le même esprit. Ici, nous avons réussi à nous débarrasser des obstacles artificiels qui ne font que compliquer le travail du programmeur - par conséquent, je pense que tout développement d'entreprise est devenu beaucoup plus agréable.