Billet intéressant à lire pour les architectes JEE : Rod Johnson le créateur du framework Spring expose dans ce billet sur son blog sa vision à plus long terme sur la faune Java et le monde de l’entreprise. Rod est à fond pour le support des modules dans JEE 6, même s’il est encore tôt pour savoir le contenu de ces profils. J’étais étonné de voir qu’en décembre Rod blogait ceci à propos de JBoss et de Tomcat:
«
Also from our observations in customer accounts, I would expect that a large part of the JBoss numbers are actually Tomcat. Many users who think they’re using JBoss are actually using a less efficient form of Tomcat. One example–the French Tax Office’s online taxation service–is a public reference for both JBoss and Spring. » (article complet ici)
J’ai un peu de mal avec l’affirmation ci-dessus. Tout d’abord Jboss est un sponsor de Tomcat depuis 3 ans, Mladen Turk a écrit le module APR qui permet de faire fonctionner Apache avec un serveur Tomcat, et il fait partie de l’équipe JBoss. Enfin la version JBoss Web est une version avec support JBoss qui est composée d’Apache et de Tomcat, justement utilisé par nous, gentil contribuable, lorsque nous effectuons notre déclaration d’impôts. Il serait intéressant d’avoir le retour d’une personne du ministère des finances ou de JBoss pour nous éclairer là-dessus.
Aujourd’hui il serait dommage de passer à côté de Spring, de la puissance de l’inversion de contrôle et de la souplesse de ce framework. Avant tout, pour moi, c’est un framework d’assemblage. Il ne m’offre pas de solution de mapping object-relationnel. En même temps, j’ai le choix d’utiliser librement Hibernate, TopLink ou autre. La première chose qui me séduit c’est que je n’enferme pas ma solution dans une architecture compliquée, sans possibilité d’évolutions. Je détache mon produit des griffes des éditeurs comme BEA ou IBM. En effet aujourd’hui, nous payons une fortune des accords OEM, qui, je le dis sans problèmes, ne me servent à rien. Même le support ne sert à rien… Il est payé par le client final qui achète la solution. Mais quelque part, j’ai un peu de mal à me dire que j’engraisse un éditeur avec une rente viagère, le temps que l’architecture J2EE basée sur les EJB 2.1 s’arrête d’exister… On en est là aujourd’hui.
SpringSource, l’entreprise, est devenu une entreprise qui doit maintenant monétiser Spring. Cela passe par des formations, des certifications, du support d’architecture. SpringSource va sur le même chemin que JBoss Inc., l’entreprise. Le support de JBoss est indispensable à nous, éditeurs de logiciels. En effet sans l’existence de la societé JBoss et d’un accord entre ma societé et JBoss, nous ne pourrions pas vendre nos produits à nos clients.
Tout simplement.
Donc en terme de « faut-il un SpringSource… » si demain nous avons des produits architecturés sur Spring, il sera obligatoire pour nous, en tant qu’éditeur, d’aller taper à la porte de SpringSource afin de mettre en place un accord.
La difficulté que je vois, c’est que JBoss offre plusieurs produits, SpringSource offre un framework d’intégration pour grouper plusieurs technologies. Il y a cependant des projets 100% Spring qui sont vraiment biens, à mon sens. Mais on ne peut pas imaginer que Spring va réécrire un moteur de persistence, de transactions ou de sécurité. Spring est avant tout un outil d’assemblage très fléxible. Du coup, lorsque nous envisagons le support, qu’allons-nous vraiment couvrir ? Lorsqu’un client signale un bug, comment identifier ce qui est Spring de ce qui est Hibernate ?
En conclusion donc, il est intéressant de suivre ce qu’il va se passer autour de Java EE 6 et de la position de SpringSource et de JBoss. Il n’y a pas de compétition entre les 2, mais même s’il y avait un embryon de compétition, c’est toujours bon pour le business…
