| « Kosmos | L'habit AJAX » |
[MAJ] JBoss et .NET
Rodrigo produit un des blogs les plus hype du moment. Au style "rentre-dedans" et au format informel, ses interviews vidéo d’entrepreneurs donnent un ton libéré à la conversation qui humanise quelque part les candidats à l'exercice. On se surprend même parfois à trouver de la sympathie ou du talent dans les pires capitaux-risqueurs et autre golden boy aux dents longues à rayer les parquets.
Dans son dernier billet, l'entrepreneur visé n'est autre que Marc fleury, Fondateur de JBoss et accessoirement l'un des hommes les plus controversés de la communauté Java.
Cela faisait un moment que je voulais blogguer sur JBoss et cette interview de Rodrigo m'en donne l'occasion. Et puis il y a aussi cette récente discussion avec Luc, ami de longue date, passé récemment dans le giron de l'éditeur en Suisse au côté de Sacha (qu’on voit à un moment à côté de Marc Fleury). Depuis maintenant plus de 5 ans que je suis activement JBoss (de la version 3 à l'actuel JEMS), je dois dire que le parcours de cette société m'a plutôt agréablement surpris pour ne pas dire impressionné. JBoss a créé et institutionnalisé le concept d'Open Source Professionnel au nez et à la barbe des plus sceptiques, tout en effectuant une série de levées de fonds qui ont contribué à assoire financièrement la crédibilité de la société. Progressivement, JBoss est en passe de réussir le pari de la rentabilité (même si l'éditeur reste discret sur ses chiffres). Tout cela, en structurant tant bien que mal une bande de joyeux lurons qui n'ont d'autres noms que Gavin Ging (hibernate), Bill Burke (la crème des crèmes techniquement) et autre Remy Maucherat (Lead Dev de Tomcat). Un autre pari est en passe d'être gagné, celui d'enlever à IBM, BEA, Sun et autre Oracle le monopole du serveur d'application. A un tel point qu’une soudaine gratuité frappe désormais le marché, Sun offre GlassFish, IBM donne Geronimo, Oracle va peut-être suivre la tendance.
Mais la bataille s'annonce rude et les principaux différentiateurs de JBoss que sont la gratuité du produit et le support vont avoir fort à faire face à la concurrence des mastodontes prêts à jouer des coudes pour garder leur part de marché. Et puis n’oublions pas ObjectWeb, qui avec JoNAS, commence à pointer le bout de son nez.
Dans un tel contexte, il faut avouer que l'annonce récente du rachat de l'outil de mapping .NET Open Source, nhibernate, a quelque peu semé le doute dans les esprits. JBoss nous prépare t-il un conteneur léger .NET ? Il semble que Non d'après Luc. Etonnamment d'ailleurs. D'autant plus étonnant qu'il y a là un vrai marché dont nul ne semble aujourd'hui prendre la mesure. Avec l'émergence d'outils tels que Spring.NET, nhibernate, Castle ou Pico, un éventuel outsider disposerait de toutes les cartes pour créer une alternative viable à Indigo de Microsoft. Une alternative basée sur des outils OpenSource et proposant le cadre d'un conteneur dit "léger". Jboss pourrait ainsi imaginer un modèle de composant .NET à la EJB 3 fonctionnant au dessus de nhibernate avec Spring côté injection de dépendance.
Sans compter la carte du portage de Seam pour jouer éventuellement le rôle de glue.
Ceux qui étaient au Symposium DNG, on pu découvrir Indigo, ses forces mais aussi ses faiblesses. Indigo est trop orienté SOA et pas assez serveur d'application léger (la distribution étant une condition sine qua non à son utilisation).
En faisant le pari du conteneur léger .NET, JBoss gagnerait non seulement un nouveau marché mais réunirait sous une même bannière deux communautés, aujourd'hui séparée, et ayant pourtant en commun les mêmes problématiques d’entreprise.
Marc, si tu m'entends...
MAJ : Marc Fleury vient de m'envoyer un mail que je ne peux bien entendu pas quoter ici. Tout ce que je peux dire c'est qu'il semble que JBoss ait largement dépassé la vision que je propose dans mon billet. Tout ça augure de belles choses pour l'avenir ... Stay Tuned donc.
5 commentaires
Indigo se nomme désormais Windows Communication Foundation, et comme son nom l'indique, il prend en charge la communcation dans les applications distribuées et les systèmes connectés. L'intention ne rejoint pas la notion de conteneur et de serveur d'application.
Je désespère de trouver un jour un peu de temps pour ne serait-ce que creuser Indigo mais intuitivement je ne vois pas en quoi on ne peut pas faire du léger avec, Sami...
Mais comme tu vois, je boycotte le terme WCF :-), d'ailleurs tu n'a pas dû l'entendre souvent au Symposium non plus ...
Plus sérieusement, par "conteneur léger" j'entends un conteneur qui permettrait d'utiliser les services d'Indigo (Securité, Transaction, Pooling, ...) *SANS* distribuer mes services (un espèce de COM sans DCOM).
Les développeurs Java savent de quoi je veux parler :-)
http://www.vnunet.fr/actualite/gds_comptes/applications/20051107016