Microservices : comment Java EE garde le cap

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.