Le moteur de gestion de contenu web eZ Publish est censé être compatible avec MySQL et PostgreSQL nativement et avec Oracle[à l’aide l’extension GPLv2 [eZ Publish Extension for Oracle® Database.]] et SQL Server[au moyen de l’extension propriétaire [MSSQL Database Extension.]] grâce à des extensions.
C’est vrai en ce qui concerne le noyau d’eZ Publish, mais est-il réellement intéressant d’utiliser eZ Publish avec un SGBD autre que MySQL ?
En effet : si le noyau d’eZ Publish est réellement indépendant du SGBD utilisé, ce n’est absolument pas le cas des nombreuses extensions disponibles : 95 % de celles utilisant une base de données ne sont compatibles qu’avec MySQL.
Deux cas de figure se présentent :
- Les requêtes à la base de données effectuées au sein de l’extension sont agnostiques, et seul le schéma de données est à modifier. C’est le cas le plus simple à gérer : il suffit à l’intégrateur de réaliser le schéma approprié à son SGBD. Si l’extension est correctement maintenue, le nouveau schéma sera intégré aux sources officielles et l’intégrateur n’aura plus de soucis à se faire.
- Les requêtes effectuées au sein de l’extension sont spécifiques à MySQL. C’est alors plus problématique : si l’extension est correctement maintenue et architecturée, l’intégrateur peut fournir un patch et espérer qu’il sera intégré aux sources officielles. Si l’extension n’est pas ou plus maintenue (et c’est malheureusement le cas de nombreuses extensions eZ Publish), il ne lui reste plus qu’à créer un fork.
C’est d’autant plus embêtant que même les mainteneurs et contributeurs d’extensions les plus importants ne recherchent pas systématiquement l’indépendance à la base de données :
- L’extension eZNewsletter maintenue par ez.no et très largement mise en avant (ainsi que ses nombreuses dépendances) n’est compatible qu’avec MySQL
- Aucune des extensions certifiées n’indique avec quel SGBD elle est compatible
Ce n’est pas tout. Une des fonctionnalités très attendues de la prochaine version (3.10) est la nouvelle gestion des clusters eZ Publish. Cette fonctionnalité ouvre de nouveaux horizons à eZ Publish en termes de performances et de déploiement en entreprise. Or, ez.no a annoncé en juin dernier qu’il abandonnait le support de PostgreSQL et Oracle (MSSQL n’était déjà pas supporté) en ce qui concerne les clusters.
Enfin, mais c’est un avis personnel, la récente ouverture du code du connecteur Oracle / eZPublish par ez.no, ressemble à un abandon du support officiel du SGBD propriétaire. Il n’apparaît d’ailleurs plus comme étant supporté dans la documentation du CMS : « Required software : A database, currently supported are : MySQL version 3.23 or later, and PostgreSQL version 7.3 or later ».
Ma conclusion est simple : utiliser eZ Publish avec un autre SGBD que MySQL réduit grandement l’intérêt de son écosystème d’extensions, induit une augmentation des coûts de développement et une certaine dose d’incertitude en termes de support. A éviter autant que faire se peut.
Malebo
6 octobre 2007
Bonjour !
Votre intéressant billet induit un possible changement de modèle économique de la part de l’éditeur norvégien. Il y a trop d’abandons (….) pour ne pas soupçonner une mise place dans un futur très proche d’un service payant pour les extensions en question ou conteneurs.
Il n’est pas impossible que ces abandons soient liés à un rachat en préparation de eZ system par un prédateur financier…Cela pourrait aussi être dicté par le choix de n’investir que dans un créneau, celui de l’édition qui trouve un intérêt économique certain dans eZ publish.
Dans les deux cas de figures il y a en perspective un adieu au modèle GPL encore en vigueur pour quelques mois ?
Tristan Rivoallan
6 octobre 2007
@Malebo :
Bonjour,
je ne crois honnêtement pas que ez.no ait un intérêt à abandonner le modèle open-source. Je pense qu’ils s’orientent plutôt vers un modèle économique équivalent à celui de MySQL avec une offre de support et de monitoring. Voir les offres « ez now » et « ez premium » sur le site de l’éditeur.
Maxime THOMAS
8 octobre 2007
J’ai développé un projet sous eZ avec Oracle 8i en utilisant le connecteur fourni. Et je dois avouer que cela ne s’est pas fait sans mal puisque j’ai du rentrer dans le code pour voir ce qui n’allait pas. Et effectivement la portabilité des développements a été réduite à zéro puisque le code des requêtes T_SQL n’était pas jouable sous MySQL.
Maintenant, est-il nécessaire d’employer un SGBD marteau pilon pour réaliser de bons sites sous eZ ? Est-ce que ça implique une erreur de l’éditeur ?
Gonzagues
8 octobre 2007
à ce propos, connaissez vous un cms open-source en php multi-base (avec au moins Mysql, Oracle et SQL Server)
merci par avance
Gaetano Giunta
22 octobre 2007
Passer une extension (oracle) de payante à complètement open source ET gratuite ne relève pas de l’abandon sur mes bouquins, mais indique plutot la volonté de faire participer plus la communauté entière sur ce port: il est vrai que, même si 100% du code d’ez et des extensions certifiées étaient compatibles avec oracle, il faudrait toujours convaincre les développeurs des extensions autres a en faire de même, ce qui n’est pas toujours facile. Leur donner la possibilité de télécharger l’extension et la tester avec, p.e., oracle XE, tout aussi free et facile a installer, est un pas en cette direction.
Coté cluster, la nouvelle version a profité d’un gros effort d’optimisation des performances, et, en général, le tuning est bien specifique a chaque base de données. S’il y a des requêtes de la part des clients pour avoir le cluster sur postgres et oracle (et je suis sur qu’il y en aura pas mal), je crois qu’il est dans l’intérêt d’eZ d’en faire autant au moins pour les deux autres base de données.
Oh, well, mes 2 centimes…
Tristan Rivoallan
22 octobre 2007
@Gaetano Giunta :
C’est exact, et il faudra voir comment cela évolue à l’avenir. Mais cela s’ajoute à un certain nombre d’autres points inquiétants et c’est pourquoi je le mentionne.
Je suis plus sceptique sur ce point, car dans un communiqué (dont je devrais chercher la référence, mais je suis en congés :P) ez.no indique justement qu’aucun de leurs clients n’utilisaient le cluster avec postgres et qu’ils s’étaient arrangés avec leurs quelques client utilisant oracle pour qu’ils passent sous mysql.
Roland Benedetti
8 novembre 2007
Bonjour à tous,
je me permet de commenter avec un peu de retard ce billet très intéressant, j’aurai quelques précisions à apporter :
@ Tristan :
Je suis relativement en phase avec le fond et l’idée générale de cette article : Oui, utiliser eZ Publish avec Mysql présente un intérêt très fort et en font un couple plus que privilégié, notamment en matière de risque. Néanmoins, je diverge un peu avec les discussions et les détails évoqués car la seule raison de ce OUI réside dans le fait que la base installée et le nombre de cas utilisant ce couple est sans contexte très important et largement prédominant. Que l’on soit sur un modèle Open Source ou Professionnel traditionnel, le nombre d’installation reste un indicateur important quand à la stabilité et à la qualité d’une solution logicielle, et dans ce cas, le couplage eZ-Mysql présente de très belles statistiques.
Concernant le fait de considérer l’ouverture du connecteur Oracle comme un abandon : ceci est infondé. Depuis quand le fait d’ouvrir un logiciel en GPL annonce son abandon ? eZ aurait simplement discontinué le développement de ce connecteur s’il avait souhaité abandonné le support Oracle, or c’est tout l’inverse, eZ va de plus en plus vers Oracle (mais pas seulement Oracle, également vers d’autres solutions d’infrastructure « enterprise »), ceci se traduit notamment par le recrutement d’experts techniques maîtrisant fortement ces technologies (Oracle / Java …), ce qui est une nouveauté chez eZ !
Concernant l’abandon de la licence commercial pour le connecteur : ce choix a été motivé par une rationnalisation de notre modèle économique qui repose sur une mise à disposition de nos codes sources progiciels sous licence GPL complétée par la vente de souscriptions annualisées de contrats de support et maintenance professionnels (eZ Publish Premium ou eZ Publish Now). Il reste possible d’utiliser une licence non GPL si le client le souhaite (dual licensing), cette alternative est proposée mais jamais imposée si ce n’est pas des contraintes légales dans certains cas très rares. Ce modèle est désormais très clairement celui que nous avons adopté et que nous proposons aux dévelopeurs d’extensions certifiées (qui ont alors l’opportunité d’utiliser le même système de support et maintenance), et il était devenu innaproprié d’avoir des composants sous licence fermé uniquement comme l’était il y a quelques temps encore le connecteur Oracle ou le Online Editor.
Concernant l’annonce officielle à la conférence 2007 d’abandon du support Oracle pour le cluster eZ Publish (et il faut bien noté ici que ceci ne signifie pas l’abandon d’Oracle pour eZ Publish mais simplement pour le mode cluster natif, il reste d’autres possibilités de faire des clusters sous eZ Publish et Oracle) : nous, eZ, avons peut être été légèrement maladroit dans cette communication qui ne devait pas être mal interprétée comme elle l’est aujourd’hui. Le fait est que le système de Cluster eZ Publish (qui au passage n’est pas nouveau, puisque présent depuis la version 3.8), ne fonctionnait pas de façon satisfaisante sur les bases de données Oracles et Posgresql. Par ailleurs, des améliorations conséquentes ont été apportées au système, se basant sur la base Mysql, mais que nous n’avions pu encore backporter sur d’autres SGBDR car la tâche n’était pas évidente. Partant de ces deux considérations, et visant à fournir un logiciel de qualité et professionnel, nous, eZ , avons décidé pour la version 3.10 de réduire officiellement le support du système de Cluster à Mysql. il n’y a pas la de grande décision stratégique ici mais plutôt la volonté d’être plus clair et honnête avec la communauté ainsi qu’avec nos utilisateurs et clients. L’objectif de nos équipes de développement est naturellement à terme d’offrir un support pour ces solutions, ceci ne peux malheureusement se faire de façon immédiate.
Concernant le fait que nous nous soyons arrangé avec nos clients pour qu’ils oublient Oracle : ceci relève vraiment de l’imagination et de la fiction ! Nous avons entre autre un de nos plus gros clients qui base son installation eZ Publish sur Oracle ! Nous restons honnête avec les capacités et forces d’eZ Publish, et, partant d’une feuille blanche, il est en effet souvent plus approprié aujourd’hui de partir sur un choix Mysql (et là je rejoint Maxime), mais délors que des contraintes d’urbanisation et de systèmes d’information imposent d’envisager l’utilisation d’un autre SGBD, nous avons aussi des réponses possibles et n’envisageons pas la simple négative !
@ Malebo :
Votre réaction, bien que démontrant que vous vous intéressez de près à l’ecosystème eZ et que vous le connaissez bien, vont à mon avis un peu vite en besogne ! eZ se professionnalise de plus en plus, avec notamment l’arrivée de nouveaux capitaux en juin dernier et la mise en place plus récente d’un Board composé de grand noms de notre secteur. De là à vos prévisions, il y a un monde ! eZ a très fortement validé son modèle Enterprise Open Source basé entre autre sur la licence GPL. Par ailleurs, et également évoqué lors de notre conférence, l’ambition d’eZ est de développer un leadership global dans le domaine de la gestion de contenus. D’un point de vue stratégique il nous semble clair que développer un leadership « global » passe par le gain de leaderships plus spécialisés, d’où notre attention toute particulière sur le secteur Media / Publishing / Entertainment. Nous n’inventons rien ici (la lecture de http://en.wikipedia.org/wiki/Crossing_the_Chasm peut être intéressante). Ceci n’est en aucun cas dicté par un hypothétique rachat ou un changement de modèle de distribution.
En guise de conclusion à ce commentaire, oui eZ-Mysql est aujourd’hui un couple privilégié. Pour autant, ce n’est pas le seul possible, et nous, eZ, travaillons pour offrir le plus grand support et la plus grande ouverture au niveau de la pile logicielle requise pour eZ, ce qui passera forcément par l’amélioration du support d’autres SGBD. Tout ceci n’ayant à mon avis, et en qualité de manager Europe de l’Ouest chez eZ Systems, peu à voir avec l’évolution « capitalistique » d’eZ et les hypothèses à mon avis plus que douteuses mentionnées dans cette discussion !
Roland Benedetti – Directeur eZ Systems Western Europe
ps : Gaetano, ayant répondu précédemment, est également consultant chez eZ Systems.
Tristan Rivoallan
9 novembre 2007
@Roland :
Bonjour et merci pour ces nombreux éclaircissements. Ceux-ci, ajoutés aux annonces faites lors des dernier eZ Publish Developer Days me rassurent quant à l’avenir du support multi-SGBD de eZ Publish.
Toutefois, vous ne vous prononcez à propos des extensions. Et notamment, quid de l’extension eZ Newsletter et des extensions certifiées ? En ce qui concerne les extensions contribuées, est-il prévu d’indiquer la compatibilité SGBD sur le site http://projects.ez.no. ?
En fait cela tient à une surlecture d’un message sur les forums de ez.no. Mea culpa. Mais si la réponse que j’apporte est erronée, la question reste posée : comment avez-vous traité ce problème avec vos clients utilisant le support cluster natif sous Oracle ? Sont-ils obligés de rester sur une branche 3.9.x en attendant le retour du support Oracle ?
Cela m’amène à vous posez une dernière question, un peu hors-sujet : comptez-vous toujours implémenter le support JSR 170 ? Il ne me semble pas avoir lu de communication de votre part à ce sujet depuis l’interview de Aleksander Farstad en 2005.
merci d’avance pour vos réponses.
Gaetano Giunta
9 novembre 2007
« Gaetano, ayant répondu précédemment, est également consultant chez eZ Systems »
et, si ce n’etait pas encore assez clair, je suis un des « gurus » Oracle recemment embauches chez eZ, alors, 2 plus 2 ca fait…
Tristan Rivoallan
19 juin 2008
Une extension oracle vient de sortir (pour ezpublish-4.1) : http://projects.ez.no/ezoracle