Pour créer un portail d’entreprise en J2EE, il y a le choix entre acheter un coûteux portail propriétaire (IBM ou BEA pour ne citer que les leaders des serveurs d’application J2EE) ou recourir à un portail J2EE open source. Mais autant l’offre open source en matière de serveurs d’application J2EE (JBoss, Jonas) atteint une certaine maturité qui la rend crédible pour des projets de grande envergure, autant l’offre open source en matière de portails J2EE semble largement immature. Ceci semble fermer à l’open source le marché des portails et de la gestion de contenu des grandes entreprises pour encore de nombreuses années.
Aux yeux de la communauté J2EE, des cabinets de conseil du secteur et des gros éditeurs, le meilleur produit du marché sera nécessairement celui qui supportera au moins les deux standards du moment : JSR 168 pour garantir la portabilité des portlets d’un produit à l’autre, et WSRP pour garantir l’interopérabilité des portlets distantes entre leur serveur d’application et le portail qui les agrège et les publie. Il y a donc dans cette gamme de produit une course à celui qui sera le plus dans la mode de la « SOA » (Service-Oriented Architecture). Comme portails J2EE open source, on cite fréquemment Liferay et Exo. Cette offre open source n’est pas étrangère à la fanfaronnade SOA (il faut bien marketer les produits, eh oui…). Du coup, l’effort de développement des portails J2EE open source semble davantage porter sur l’escalade de la pile SOA que sur l’implémentation de fonctionnalités utiles. C’est sûrement ce qui amène la communauté J2EE à constater que les portails J2EE open source manquent encore beaucoup de maturité et de richesse fonctionnelle surtout lorsqu’on les compare à Plone, leader du portail / CMS open source. En effet, Plone s’appuie sur un serveur d’application Python (Zope) et non Java (a fortiori non J2EE) ; il se situe donc hors de la course à JSR168 et semble royalement ignorer le bluff WSRP.
Nombreuses sont les entreprises qui s’évertuent à faire de J2EE une doctrine interne en matière d’architecture applicative. Confrontées au choix d’un portail, elles éliminent donc rapidement l’offre open source J2EE (pas assez mûre). Et, plutôt que de choisir un portail non J2EE reconnu comme plus mûr, plus riches en fonctionnalités et moins coûteux, elles préfèrent se cantonner à leur idéologie J2EE sous prétexte qu’il n’y a point de salut hors J2EE/.Net. Pas assez buzzword compliant, mon fils… Pfff, ne suivez pas mon regard… :-(
Eh oui, J2EE par ci, .Net par là, Bea Portal, Documentum, EJB, JSR truc muche… Les décideurs ne savent même pas de quoi il s’agit réellement, mais commme ils en entendent tout le temps parler, c’est que ça doit être super bien. Et puis ce sont de gros éditeurs et ça coûte un max, c’est rassurant pour eux.
Alors ils font le plein de licences à 1MF et 1 an après, le site finalement si simple fonctionnellement qui pouvait être fait en un ou 2 mois en PHP ou en Zope n’est toujours pas terminé ! Et en plus, une fois en production, il plante sans arrêt. Serveur EJB tombé, désynchronisation entre Documentum et le webcache target, serveur avec 10 GO de RAM « out of memory », j’en passe et des meilleurs. Les dev PHP, c’est souvent crade, mais ça tourne au moins.
Après plus de 2 ans de veille sur les CMS, j’en suis arrivé à la même conclusion : les CMS Java ne sont pas très aboutis, surtout d’un point de vue « utilisateur ». Les développeurs Java pensent plutôt à quelles normes ils vont implémenter plutôt qu’aux fonctionnalités finales. En PHP, les CMS pulullent mais sont souvent médiocres et peu extensibles. SPIP est populaire mais vraiment trop limité et salement codé. Au boulot, des projets sont partis avec et ils ont voulu évoluer après : quelle mauvaise idée !
Finalement, depuis mon dernier commentaire, j’ai enfin réussi à faire comprendre aux architectes que Zope et Plone, c’est pas du pipo. Mais que ce fut long et pénible ! Le plus dur finalement a été de les convaincre d’assister à une petite démo concrète. Et ce fut pour eux LA révélation : comment un produit gratuit peut-il faire des trucs pareils sans EJB ni JSR168 !! Et en plus, 5 jours de dev pour faire un proto fonctionnel à 90%, c’est de la folie pure !
Depuis, ils vendent du Zope aux projets qui veulent partir sur du Java. Comme quoi, y’a que les imbéciles qui ne changent pas d’avis !
ZeGoR a dit : […] j’ai enfin réussi à faire comprendre aux architectes que Zope et Plone, c’est pas du pipo. […] ce fut pour eux LA révélation : comment un produit gratuit peut-il faire des trucs pareils sans EJB ni JSR168 !! Et en plus, 5 jours de dev pour faire un proto fonctionnel à 90%, c’est de la folie pure ! Depuis, ils vendent du Zope aux projets qui veulent partir sur du Java. Comme quoi, y’a que les imbéciles qui ne changent pas d’avis !
ARGH ! GNNN ! COMMENT !?!? Mais comment as-tu fait ??? Quelle est la recette miracle ? Comment as-tu réussi à convaincre un architecte Java ou un manager conservateur de la valeur de Zope et de l’opportunité d’adopter cette techno dans le S.I. ? J’avoue humblement que la tâche me paraît insurmontable chez mon employeur et que j’ai un peu baissé les bras (ce n’est pourtant pas faute d’avoir essayé). STP, raconte !
Ce que je trouve particulièrement dur, notamment, c’est de faire comprendre sur le plan théorique, que ce n’est pas parce que Python est un langage dit « de scripting » qu’il incite pour autant à faire des architectures aussi pourries qu’avec des langages de scripting non-objet (ASP, ou bien PHP dans sa prime jeunesse). Les architectes J2EE/.Net des grandes entreprises semblent engagés dans une croisade pour la rationalisation objet des développement et contre la prolifération des développements à couplage fort (faire du code ASP pour créer des écrans HTML affichant/gérant des données d’une base SQL). J’adhère fortement aux finalités de cette croisade. Mais j’ai l’impression qu’ils sont tellement engagés dans leur croisade qu’ils tendent à verser dans un excès de technologies à millions d’euros au détriment du bon sens. Comment les ramener à la raison et trouver le juste équilibre entre bricolage et purisme ?
Pour répondre à ta question « Comment j’ai fait » :
Suite en fait à l’étude sur les CMS il y a plus d’un an, j’avais réussi à faire passer l’idée à mon chef (qui lui est assez ouvert) le fait de faire travailler un p’tit stagiaire (non payé) sur une maquette du site du département en Plone. Ca tombait super bien car il avait déjà fait un peu de Zope pendant son DUT. Evidemment, ça n’a pas plus à certaines personnes, plus particulièrement les experts PHP, Notes et J2EE qui voyaient d’un sale oeil une nouvelle techno arriver. Tout le monde se moquait un peu de nous, trouvant le mot Zope très amusant.
Mais voilà, un mois après, le site était terminé. Après une petite demo, le chef devant le fait accompli s’exclama : « ben maintenant qu’il est fait, ça serait con de le refaire en PHP ou Java, on n’a qu’à l’utiliser. On dira aux architectes que c’est une expérimentation et surtout, il ne faudra pas dire aux clients qu’il est fait en Zope, ils seraient capables de nous en demander !! »
Vers mars 2004, les projets J2EE, englués dans des Bea Portal et Documentum surdimensionnés par rapport aux besoins, coûtant une fortune pour des résultats peu glorieux, firent émerger l’idée d’une solution certes moins riche mais plus rapide et moins chère. Alors, je retentai ma chance, mais encore raté. Les architectes décidèrent de lancer le projet J2EE « light »: développer un CMS basé sur Bea WorkShop, dans le genre de SPIP mais en Java, car Java, c’est du sérieux ! Franchement, j’ai failli mourrir de rire et je leur souhaitais bon courage, car ils avaient 6 mois pour réussir et 250 K€. Et comme prévu, 6 mois plus tard, rien n’était fait : Panique à bord, il faut trouver tout de suite un autre truc, car le client va pas être content !
Parallèlement, le chef du département lança un concours d’idée sur le principe : « Faire mieux et moins cher ». Très bien, et bien moi, j’ai un joujou extra, qui fait crack boom huuu, les sites en tombe à mes genoux. Le chef du département, convaincu par une offre basée sur Zope, alla voir les architectes pour préparer le terrain. 1 mois et une demo plus tard, c’étaient eux qui étaient à genoux :-)). Je les ai ensuite rassuré avec des références, des SSII…
Cet après-midi encore, j’ai refait une démo aux développeurs et chefs de projets : « Ouais, ç’est super ton truc pour mon projet, c’est bien mieux que SPIP ». Maintenant, il va falloir mettre en place très vite une cellule Zope car les frustrés de J2EE et PHP vont déferler !
@++
Et oui, la plupart des architectes sont des puristes et leur but ultime est d’unifier le SI et de limiter les technos pour faciliter l’intéropabilité :
* une seule interface : Internet Explorer
* un seul serveur d’appli : BEA ou Websphere
* un seul langage : Java
* une seule base de données : Oracle
* un seul outil de GED : Documentum
* un seul OS : Solaris
* …
Evidemment, c’est totalement impossible à réaliser dans une entreprise de grande taille. Une seule techno ne pourra jamais tout faire de façon optimale, et cela peut même être très dangeureux. Faut jamais mettre ses oeufs dans le même pannier, c’est bien connu. Et puis question intéropabilité, les webservices sont souvent suffisants, permettant ainsi à tout le monde de communiquer très facilement.
L’essentiel, c’est de respecter les normes en vigueur et d’éviter de s’embarquer dans des solutions fermées et propriétaires, comme Notes par exemple, qui vous rendent dépendant d’un éditeur. Par exemple, les architectes ont cru bon d’utiliser le carnet d’adresse Notes comme annuaire LDAP. Pratique, mais pas de bol, les mots de passe sont cryptés dans un algo propriétaire impossible à exporter : il sera très diffile de passer sur un véritable annuaire LDAP après.
Donc pour moi, le juste équilibre pour le web :
* PHP pour les développements rapides et spécifiques, en essayant de s’appuyer sur un framework objet (PHP5 va certainement améliorer les choses)
* Zope pour les portails de moyennes envergures, mais potentiellement riches fonctionnellement.
* J2EE pour les gros projets qui en ont vraiment besoin !
J’ai pas d’avis sur .Net, mais j’ai vu qu’on pouvait faire du Python avec et C# a l’air sympa, mais bon, ça reste du Microsoft… Je ne sais pas ce que vaut non plus le portage sous Unix « Mono »…
Bravo et merci pour ce témoignage ! J’espère qu’un jour j’aurai le plaisir de raconter une histoire pareille (à mes enfants, lors d’une longue veillée d’hiver, au coin du feu…). Si je comprends bien la morale de cette histoire, ou les enseignements que l’on pourrait en tirer, c’est de :
Autre chose ?
J’imagine que le challenge suivant pour toi doit être de se montrer à la hauteur des attentes lorsqu’il s’agira de tenir la route en production (robustesse, exploitabilité, maintenabilité, …). Bonne chance !
Tiens, pour la petite histoire que je pourrais raconter de mon côté, après avoir eu le sentiment de prêcher longtemps dans le désert, je viens de recevoir un email d’un collègue qui me dit, en substance : « pour le projet X (que l’on doit mettre en prod dans 15 jours), il paraît que le logiciel ‘Plone’ serait une bonne solution ; c’est l’équipe architecture J2EE qui m’en a parlé car ils l’utilisent pour partager leur documentation technique et suivre une partie de leurs activités ; qu’est-ce que tu en penses ? »
Amusant, non ?
Amusant en effet ! Et à mon avis, ce n’est qu’après avoir désespérément chercher un outil en Java facilement utilisable qu’ils ont finalement trouvé Plone.
Je pense qu’on n’est qu’au début de l’histoire. Peu de personnes connaissent encore Zope. Le nom fait plutôt rire (c’est bête mais cela pose un réel problème d’image, surtout en France) et les gens sont focalisés sur la guerre .Net/J2EE. Certains voient même PHP5 en killer de J2EE, alors que ce n’est qu’un langage comme Perl, Python ou Ruby, qui sont d’ailleurs à mon avis supérieurs et performants (j’ai fait des benchs et PHP est 2 à 3 fois plus lent !). Mais je pense que Plone peut enfin faire décoller Zope. Par exemple, je viens de chercher Plone sur amazone.fr, et j’ai trouvé 4 livres. Pas mal pour un CMS opensource. Y’a que SPIP qui peut en faire autant… Et si je tape « documentum », « vignette », « interwoven », « jalios » ou « noheto » : zéro réponse !
Autre indice : on commence à trouver pas mal de formations un peu partout, et ça, c’est rassurant pour les décideurs.
Qui vivra verra…
Si, il y a un très bon portail/cms opensource : jahia (www.jahia.org) mais il n’est pas gratuit (de l’ordre de 4000 a 5000 euros la license).
Sur le site il y a des demos en flash qui permettent de se faire une idee des possibilités, sinon il s’installe en 10 minutes sur un tomcat.
C’est notamment un des seul CMS que je connaisse qui gère très très bien un site multilangue.
Un bon exemple d’utilisation : le site de l’EPFL http://www.epfl.ch
Jahia n’est pas un portail/cms opensource. C’est un produit propriétaire. Certes, son code source est visible mais la licence sous laquelle il est distribué est une licence « collaborative source ». C’est un peu comme Java ou certains produits de Microsoft : ça a le goût de l’open source mais ça n’en est pas ! Donc c’est un peut-être un très bon produit. Mais ce n’est pas le portail/cms opensource J2EE que l’on aurait souhaité.
Euh, petit rectificatif : Jahia en version illimitée, c’est plutot 30000 euros !
http://www.jahia.com/jahia/page480.html
En gros, on t’accroche avec du libre mais in fine tu passes à la caisse comme les autres.
Effectivement, les CMS en J2EE cela ne court pas les rues. Pour ma part, j’ai trouvé récemment 2 produits assez intéressants sur un salon à Paris dans des budgets décents :
-> 1G-content (1Genia, http://www.1g-content.com)
-> MJContent (Dalysco, http://www.dalysco.com)
A suivre… Quelqu’un a-t-il des retours d’expérience de ces produits ?