Java Spring, J2EE, Java EE sont les mots clés les plus trouvés dans le monde de l'informatique d'entreprise. Depuis les années 2000 les entreprises ont massivement investi dans la technologie JAVA.
Le cœur de cible de J2EE était de remplacer à moindre coût les infrastructures Mainframe dans lesquelles les entreprises se sentaient emprisonnées par les éditeurs sur des technologies vieillissantes et du matériel spécifique hors de prix. L'avènement de l'architecture PC pour les serveurs permit alors d'acquérir une puissance de calcul à un coût très compétitif mais il faut une technologie pour y développer des applications d'entreprise : J2EE.
Mais le passage vers J2EE ne tiendra pas vraiment ses promesses, pour divers raisons :
- Alors que l'architecture des applications Mainframe est globalement mise en place et validée par la solution de l'éditeur et au final les développeurs sont dans un cadre qui permet de se concentrer sur l'implémentation du métier. Avec J2EE la complexité d'une application transactionnelle, répartie sur plusieurs machine doit être prise en compte par l'équipe de développement.
- En plus de gérer des concepts compliqués l'implémentation des composant J2EE est tout aussi complexe.
- J2EE un standard ouvert mais les implémentations sont le plus souvent payantes.
- De plus c'est la révolution du Web, on veut des applications d'entreprise en client Web qui sont finalement beaucoup plus contraignantes et complexes à développer que les applications client lourd pour souvent un rendu utilisateur de moins bonne qualité.
Sur le tas de cendre, laissé par les développements J2EE, Spring démarre en flèche. Il modifie le paradigme et on parle de conteneur léger (Tomcat), en général elles sont montées en cluster de type silo.
Finalement Spring a pris une place majeur dans l'écosystème Java, à grossi, c'est enrichi et c'est complexifié... en même temps J2EE a évolué et changé de nom pour Java EE et s'est fait peau neuve pour devenir plus simple. Aujourd'hui ces 2 solutions sont sensiblement équivalentes mais Java EE est tiré par des serveurs d'applications d'entreprise (JBOSS, Weblogic, Websphere...) alors que Spring peut-être utilisé avec du pur Java SE et a un écosystème qui lui est propre.
Et maintenant que trouve-t-on sur le terrain ? De mon expérience, je rencontre des applications développées sur Spring déployées sur des serveurs d'applications Java EE, et c'est quasiment systématique. Les développeurs ont acquis une expérience plutôt positive avec Spring mais au niveau de l'exploitation les serveurs restent Java EE car soit il y a un historique ou la nécessité d'avoir le support d'un éditeur.
En soit pas de souci les 2 technologies peuvent s'intégrer. Donc en général ce n'est pas un problème c'est juste étrange de ne pas exploiter certaines fonctionnalités fournies en standard par le serveur.
Mais ça devient plus problématique quand l'application développée sur Spring embarque des librairies sur lesquels ce base le serveur Java EE ou qui implémente les même fonctionnalité. En effet le serveur Java EE a été testé, certifié par une communauté ou un éditeur pour fonctionner avec ses propres librairies, c'est d'ailleurs une part importante de leur valeur ajoutée. Dans le cas où l'application apporte des librairies en conflit il faut s'attendre à des soucis au démarrage, pour passer outre il faudra démonter le serveur d'application (avec un peu de configuration dans le meilleur des cas, en modifiant dans le système de fichier dans le pire des cas) pour qu'il charge nos librairies à la place des siennes. Par ailleurs les exploitants fournissant le serveur n'auront alors aucune garantie sur la réelle configuration et une montée de version ne se fera pas sans surprise.
En générale avec des serveur d'application propriétaire (Websphere, Weblogic), il y a moins de risque de collision de librairie car il n'est pas évident d'embarquer les leurs par inadvertance vu qu'elles sont payantes et rarement fournies sans le serveur. Par contre pour les serveur open source (JBoss, Glassfish) il est fort probable qu'en embarquant Hibernate, Log4j, Jersey un conflit se produise et ce n'est qu'un début. Sans parler des possibilités de monitoring de la console d'administration qui risque de ne plus être opérationnelle.
Mixer Spring et un serveur Java EE nécessite une petite étude préalable et il est possible que les développements finissent par être adhérents au serveur Java EE choisi lors de la phase de développement. Alors qu'une application Java EE devrait être (en théorie) portable d'une plateforme à une autre, sans parler de la taille des binaires à déployer, utilisant le serveur Java EE il y aura fort peu de librairies à embarquer et sur le terrain livrer un binaire de plusieurs centaine de Mo et quelques Mo ça change la vie.
Aucun commentaire:
Enregistrer un commentaire