Oleksandr - Fotolia

Microservices : comment Java EE garde le cap

Java EE est une technologie mature, mais elle continue à évoluer de manière à s'intégrer parfaitement dans une architecture de microservices.

Le langage de programmation Java est certes une technologie mature. Mais cela ne l’empêche pas de poursuivre son évolution – même si la mécanique semblait quelque peu rouillée pour l’emmener  vers des terres inexplorées. Avec l'essor des microservices, la question se pose de savoir si le développement de Java EE peut ou non répondre aux exigences modernes.

Dans sa forme actuelle, Java ne peut répondre aux besoins d'une architecture de microservices, répond Robert Roeser, PDG et cofondateur de Netifi.  Pour cette raison, certaines entreprises, à l’image de Netflix, qui ont misé sur les microservices, doivent combler les lacunes de la plateforme. Ce besoin a donné lieu à des développements comme celui du framework Spring, qui offre quelques avancées, mais rien de très cloud-natif. La Cloud Native Compute Foundation (CNCF) est en revanche un excellent exemple d'un groupe de personnes dont les progrès sont le plus notable.

Les microservices représentent un changement radical par rapport au développement d'applications monolithiques traditionnelles, explique encore Robert Roeser, qui a été l'un des pionniers des microservices chez Netflix. Cependant, la difficulté est de savoir comment tout connecter, du datacenter au client. Cet assemblage est particulièrement difficile lorsque l’on ne sait pas si le client fait face au web, à un téléphone ou à un bot, ajoute-t-il.

Java EE est-il prêt ?

Mais tout le monde n'a pas une vision aussi dure de Java. Pour Mark Little, vice-président de l'ingénierie et directeur technique du middleware JBoss chez Red Hat, il est faux de penser que, puisque le développement Java EE est antérieur aux microservices et à la SOA, cela ne convient pas du tout à des environnements de containers et microservices.

Cette fausse idée vient de l'incapacité de faire la différence entre Java EE en tant qu'ensemble de normes et Java EE en tant qu'ensemble d'implémentations, souligne-t-il. « Les spécifications qui forment la norme ont été développées pour être modulaires, ce qui permet de nombreuses implémentations différentes ».

Ceci est illustré par Java Persistance API que l'on trouve dans Java EE et dans les implémentations modernes, comme Hibernate et EclipseLink, confirme l’expert. Pour revendiquer la pleine conformité Java EE, « vous devez ajouter toutes ces spécifications », explique-t-il.

Bien que cette approche aboutisse parfois à des implémentations dites monolithiques, elle n'a pas à l'être. Certains frameworks, dont la notoriété est forte dans les projets de microservices, ne peuvent pas prétendre à la conformité Java EE, insiste Mark Little. Ils peuvent, cependant, utiliser diverses implémentations de spécifications. « Par exemple, Hibernate n'est pas seulement utilisé dans WildFly et EAP [Enterprise Application Platform] »,  note-t-il.

En 20 ans, le développement de Java EE a connu plusieurs itérations et de nombreuses nouvelles fonctionnalités. Les projets open source, comme Hibernate et Spring, ont par exemple été conçus pour s’intégrer au-dessus de Java EE et combler les lacunes initiales des spécifications - en particulier dans le domaine de la persistance.

« Java EE a évolué en incluant les fonctionnalités de ces projets afin de maintenir son attrait pour les développeurs », soutient de son côté Simon Ritter, directeur technique adjoint d'Azul Systems, qui développe des runtimes Java. « De même, quand les web services sont devenus tendances, on a porté Java EE vers cette technologie. »

En entreprise, les développeurs sont encore aux prémices de l'adoption de l'architecture microservices. Cependant, les spécifications Java EE ont tardé à suivre le mouvement, rappelle Simon Ritter. Résultat, Red Hat, IBM ainsi que certains membres de la communauté Java ont développé la spécification MicroProfile (remise entre les mains de la Fondation Eclipse) en dehors du processus classique de la communauté Java.

Mais, heureusement, Oracle a fait don, à cette même fondation, des spécifications Java EE, d'implémentations de référence et de kits de compatibilité afin que soient développées des spécifications à un rythme qui réponde aux besoins des développeurs, lance encore l’expert. Les spécifications Java EE ont aujourd’hui pris le nom de Jakarta EE au sein de l’institution open source.

Java dans les microservices

Si bien conçue, une architecture de microservices permet un large éventail d'implémentations, commente Randy Heffner, analyste chez Forrester Research. En tant que tel, Java peut intervenir à des nombreux endroits, comme dans une architecture mixte.

En grande partie, les grandes entreprises construisent lentement une architecture de microservices, mais les équipes ne peuvent pas toujours tout créer from scratch. Les nouvelles fonctions purement microservices doivent souvent être associées à d’autres, anciennes, qui utilisent alors des API pour s’intégrer à une application basée sur les microservices, ajoute Randy Heffner.

Simon Ritter considère enfin Jakarta EE comme le cas d'utilisation Java le plus courant dans les microservices. « Etant donné les liens étroits de la Fondation Eclipse avec la communauté Java, je m'attends à ce que Jakarta EE continue à se développer pour répondre aux besoins de ceux qui cherchent à utiliser une architecture de microservices », conclut-il.

Pour approfondir sur DevOps et Agilité

Close