Nuxeo RCP permet de réaliser des applications clientes consacrées à la gestion de contenu, capables de fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers (i.e. web), par exemple dans le domaine de l’édition de documents multimédias ou de la collaboration synchrone.
Nuxeo RCP a été développé grâce à trois projets clients majeurs pour Nuxeo qui ont été développés au cours de l’année passée : deux solutions de gestion éditoriale créées pour l’Agence France-Presse, d’une part, The Press Association, d’autre part, et un projet de gestion documentaire pour la DGA. Selon le principe de mutualisation, un certain nombre de composants génériques ont été développés de manière ouverte dans le SVN de Nuxeo pour servir de base à ces projets, et sont ensuite réutilisés pour les projets qui en ont besoin.
L’un des avantages majeurs de Nuxeo RCP est qu’il embarque le même noyau de gestion documentaire Nuxeo Core et propose le même système de greffons que les logiciels serveurs Nuxeo, notamment le serveur Nuxeo EP. Il est ainsi facile de mutualiser une partie du code et des modèles entre la partie serveur et la partie cliente des applications d'ECM développées sur la base de ces technologies.
Aller plus loin
- Le communiqué de Nuxeo (10 clics)
- Le "RCP Book": documentation initial du proje (8 clics)
- Présentation des projets AFP et PA (7 clics)
- Dépêche précédente sur Nuxeo Core (1 clic)
- Dépêche précédent sur Nuxeo EP (2 clics)
- Le dépôt de sources SVN (9 clics)
# Coût d'une telle solution
Posté par Trois Singes . Évalué à 2.
En ce qui concerne Nuxeo, et le nuage d'applications qui gravitent autour, je me pose la question du coût de mise en place d'une telle solution. La pile logicielle sur laquelle elle repose peut en effet effrayer les équipes informatiques nourries au LAMP :
- Nuxeo RPC
- Nuxeo EP
- JBoss
- Eclipse (+Ant et Maven)
- Java
- J'en oublie peut-être...
Si le parc logiciel est plutôt basé sur des clients légers (applications web), la migration risque de donner des sueurs froides au DSI, coûter cher en formations, en maintenance, ...
(Je me demande d'ailleurs si Nuxeo n'avait pas déjà pris conscience du problème avant de décider d'abandonner Zope/Python pour JBoss/Java, réduisant déjà l'effet "sueurs froides")
Est-ce que certains d'entre vous ont réussi à mettre en place une telle solution dans leur entreprise de manière pérenne et évolutive ? Est-ce que les solutions concurrentes étaient effectivement plus chères/moins performantes ?
[^] # Re: Coût d'une telle solution
Posté par Stefane Fermigier (site web personnel) . Évalué à 2.
Quelques éléments de réponse:
1. Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
2. Distinguons bien Nuxeo EP, qui est le fondement de notre offre, de Nuxeo RCP qui est une "cerise sur le gâteau", un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
3. On se place donc bien dans la situation où les développeurs auxquels on s'adressent connaissent bien Java. En général, ils connaissent bien Ant, et le plus souvent (c'est en tout cas ce que nous avons constaté dans 100% des cas chez nos clients et partenaires), ils utilisent Eclipse comme IDE. Ils ont l'expérience d'un ou plusieurs serveurs d'applications, et dans la plupart des cas cela inclut JBoss. Maven était moins bien connu il y a deux ans quand on a commencé le projet Nuxeo 5, mais on a constaté depuis que de nombreux projets Java libres étaient passés à Maven et que ça connaissance se répandait dans l'industrie des services. De toute façon, les connaissances Maven nécessaires pour démarrer, builder et déployer un projet Nuxeo tiennent en deux pages de texte (il y a trois ou quatre options différents de la commande "mvn" à connaître), et par ailleurs des plugins Maven sont en train de mûrir pour Eclipse (et Netbeans).
4. Pour en revenir à la philosophie générale, et à la prospective, nous avons effectivement choisi de nous appuyer sur les approches les plus standards du monde Java, mais en même temps en tirant partie du dynamisme insufflé depuis la sortie de Java 5 et Java EE 5, de façon à faciliter la vie des développeurs qui travaillent sur notre plateforme.
Parmi les points sur lesquels nous comptons travailler dans les mois qui viennent (entre autres) et sur lesquels bien sûr nous accueillons à bras ouverts toute contribution (-> http://www.nuxeo.org/sections/community/ ), qu'elle soit sous forme de code, de plugins ou simplement d'idées:
- La réalisation d'un IDE (en fait, un profil pour Eclipse, avec une selection des plugins qui vont bien + quelques plugins spécifiques) dédié au développement d'applications sur la plateforme Nuxeo.
- Le déploiement de Nuxeo EP dans d'autres serveurs d'applications que JBoss.
- Une version de Nuxeo dédiée au développement d'application web légères, qui pourra être customisée par des développeurs qui ne connaissent pas Java.
S.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . Évalué à 2.
C'est justement ce dernier point que j'aimerais voir éclairci. Qu'est-ce qu'un « gain de productivité » ? Pourquoi un coût « pas forcément moins élevé » ? Ce n'est pas du tout une critique de Nuxeo (qui a l'air prometteur) mais plutôt une critique du discours : quels sont les arguments qui démontrent clairement des coûts équivalents et un gain de productivité ?
Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté. Or Java, c'est très intimidant pour eux. C'est pourquoi je m'étonne que vous ne vous adressiez pas plus à cette communauté, un peu comme Apple qui fait pas mal de bruit autour des switchers ;-)
[^] # Re: Coût d'une telle solution
Posté par Stefane Fermigier (site web personnel) . Évalué à 3.
Je me base sur un cas très concrêt: celui de l'AFP, où les responsables informatiques ont mesuré un gain de productivité de 40% des journalistes entre la nouvelle console, basée sur RCP, et l'ancienne. Cf. cet article de 01 Net:
http://www.01net.com/editorial/373461/l-agence-france-presse(...)
Ce gain de productivité s'explique dans cet exemple par une interface plus riche que l'ancienne en termes de gestion des flux d'information, de recherche, et d'édition en ligne du texte et des images.
Si on devait comparer une interface RCP à une interface web ajaxifiée, on ne retrouverait sûrement pas 40%, mais peut-être 10% ou 20%, en fonction des besoins des utilisateurs. Ici, on se place dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans, ce qui à ma connaissance n'est pas évident à faire sur un navigateur), qui ont a travailler des informations multimédia, etc.
Cf. par exemple cette photo: http://flickr.com/photos/nuxeo/2082947465/ où on voit le rédacteur en chef du desk multimédias de l'AFP à Paris avec ses deux écrans, la dépêche et la photo sur lesquels il est en train de travailler sur l'écran de gauche, et les différents flux de dépêches textes et d'images à partir desquels il compose ses dépêches multimédias, ainsi que les flux de dépêches qu'il a à valider, sur l'écran secondaire, à droite.
Pourquoi un coût « pas forcément moins élevé » ?
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen. Je n'ai à ce jour pas suffisamment de données pour dire laquelle de ces deux approches est la moins lourde, en tout cas pour des applications relativement complexes, avec beaucoup de dépendances entre les éléments d'interface, etc., ce qui est le cas qui nous intéresse. Mais il me semble qu'il y a de bons arguments pour dire qu'à partir d'un certain niveau de complexité, c'est le client riche (ou lourd) qui gagne.
Par ailleurs, pour ce qui concerne les gains de productivité ou en tout cas la diminution de la charge de développement sur un projet d'ECM basé sur Nuxeo par rapport à des technologies similaires, propriétaires ou open source, nous n'avons évidemment pas témoignage direct puisque tous les projets que nous faisons sont basés sur les technologies Nuxeo. Mais plusieurs de nos camarades intégrateurs nous ont affirmé, sans souhaiter être cités pour l'instant, pouvoir chiffrer des charges de développement moins élevées avec Nuxeo qu'avec les autres plateformes qu'ils pratiquent.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté.
Il serait illusoire pour nous de chercher à imposer notre technologie à tout le monde d'un seul coup, surtout lorsque cela représente un effort d'apprentissage important de nouvelles technologies. Notre cible principale est les développeurs Java et nous pensons que sur ce point nos efforts pour rendre le framework Nuxeo accessible ont déjà payé, ce qui ne nous empêche pas de travailler (notamment sur les outils) pour le rendre encore plus accessible.
Concernant les développeurs de type "LAMP" (PHP/RoR/Django/...), le nouveau framework web léger que nous allons annoncer prochainement (je ne manquerai pas de poster une annonce sur linuxfr) devrait répondre à leurs attentes.
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Coût d'une telle solution
Posté par wilk . Évalué à 4.
Mais d'après ce que j'ai compris vous avez prévu les deux solutions.
[^] # Re: Coût d'une telle solution
Posté par Stefane Fermigier (site web personnel) . Évalué à 1.
En effet, pour nous les deux approches sont complémentaires (et on sait aussi faire du Flex au-dessus de notre plateforme si nécessaire, etc.).
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . Évalué à 1.
Je comprends mieux l'opposition que vous faites entre client riche (RPC) et client nouveau-riche (Ajax) ; opposition qui concerne clairement les usages actuels de ces deux méthodes. Le fait que vous vous placiez « dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans) » est pour moi beaucoup plus clair que lorsque vous écrivez « fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers ».
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen.
Je ne peux que confirmer ce point. Nos développements Ajax sont effectivement encore plus proche de l'artisanat que de l'industrialisation -- ils sont grisant mais coûteux. Ajax est une rustine qui se colle sur les technologies^Wstandards du web, c'est à la fois bien et mal : bien parce que ces standards sont d'une haute qualité sémantique (attention, je n'ai forcément pas dit technique...) et parce que, à terme, ils permettent un déploiement d'application bien moins cher que des interfaces riches comme Nuxeo : pensez donc, l'architecture web est déjà en place depuis 15 ans ! Mal parce qu'une rustine, ça se décolle, c'est pas facile à fabriquer, il y a 50 méthodes différentes, pas pérennes...
Donc, avec Ajax, développement difficile mais déploiement pas cher... et j'ai l'impression qu'avec les technologies Java, une fois passé le cap de l'apprentissage, c'est l'inverse.
C'est alors l'utilisateur qui départagera, selon l'expérience qu'il veut vivre (et ça rejoint totalement le début de mon commentaire, waow, je devrais écrire plus souvent à 1H20 un dimanche matin). Ça va être passionnant.
Au fait : est-ce que vous avez jeter un œil sur XUL, qui pourrait être un compromis intéressant ? Je crois d'ailleurs que le back-office du journal Le Monde est codé en XUL, ce qui fait un parallèle intéressant avec l'AFP.
[^] # Re: Coût d'une telle solution
Posté par Stefane Fermigier (site web personnel) . Évalué à 2.
Oui, à condition qu'une condition soit bien remplie: que le parc de navigateurs web chez les utilisateurs soit homogène et parfaitement contrôlé.
En pratique, ca peut arriver dans certaines organisations, mais c'est plutôt l'exception. Et quand ca arrive, ce n'est pas la version du navigateur que les développeurs utilisent, ou que les bibliothèques Ajax veulent utiliser, etc.
Bref, ca peut dégénérer assez facilement.
Au fait : est-ce que vous avez jeté un œil sur XUL?
Amusant que tu poses la question: notre première réponse à l'appel d'offres de l'AFP reposait sur XUL, mais après en avoir parlé à des développeurs Mozilla qui ont eu la gentillesse de nous faire part de leur expérience sans cacher les problèmes, nous avons préférer proposer à l'AFP, qui a accepté, de partir plutôt sur Eclipse RCP. Le message de l'époque (il y a 3 ans) était qu'il fallait attendre Mozilla 3 pour avoir quelque chose de stable...
"There's no such thing as can't. You always have a choice." - Ken Gor
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.