Jeudi matin j’ai assisté à un séminaire sur les Portails Java Open-Source organisé par Ippon Technologies dans les locaux de Sup Info à Paris. Après une présentation des Portails, de la spécification des Portlets et des différents types de projets rencontrés, nous avons eu le témoignage d’un client eXo Portal puis d’un client Liferay. Le tout s’est terminé avec une séance de questions/réponses.
Bertrand Pinel d’Ippon Technologies a tout d’abord présenté un état de l’art des Portails Open-Source. La présentation débute par une explication du mot « Portail ». Car chacun a une image en tête. Certains voient un portail à la iGoogle ou la NetVibes, d’autres voient une page comme Amazon.com, et d’autres voient un portail en fer forgé. Bon pour le groupe 3 : un Portail Java est un logiciel qui permet d’agréger du contenu, et d’agir comme un proxy vers l’information. Les Portlets sont en quelques sortes des applications légères qui, lorsqu’elles sont placées ensembles, créent un service sur une page. Comme tout ceci est un peu abstrait, je vous promets de vous raconter une vraie histoire d’ici à la fin de l’année sur le Touilleur Express.
Un Portail est aussi un moyen de proposer des services communs comme l’authentification, la gestion des droits des utilisateurs, la possibilité de personnaliser son interface, ou de contribuer avec du contenu. Un portail est aussi un socle technique sur lequel vous pouvez faire fonctionner des services à valeur ajoutée comme un gestionnaire de contenu (CMS) ou un Wiki par exemple. Donc on retiendra surtout qu’un Portail est le chassis de la voiture, et que ce sont les services que l’on pose dessus qui en font ensuite « un portail de contenu » ou « un intranet » ou encore « une page d’accueil de notre site institutionnel ». Vous suivez ?
Tout le monde fait du portail… Mais tout le monde ne fait pas du Portail, avec un P majuscule. Les éditeurs traditionnels comme Oracle et IBM sont certes présents sur ce marché. Mais ce sont des constructeurs qui viennent du monde du middleware. A l’opposé, dans le monde de l’open-source il y a d’autres acteurs qui ne font que cela, et qui le font mieux d’après Bertrand Pinel. Avis que je partage de plus en plus.
Cette carte de métro provient du site « CMS Watch ». Elle présente l’ensemble des Portails, des CMS, des outils de publication de contenu.
(voir l’image en grande taille)
Alfresco et Nuxeo sont sur la branche « Enterprise Content Managment » alors que les Portails d’Entreprise sont représentés par JBoss Portal, eXo Portal, Liferay ou uPortal par exemple. Je trouve ce schéma très intéressant pour comprendre comment chacun des acteurs du marché se positionne. Et finalement, est-ce qu’une approche modulable à la eXo n’est pas plus intéressante qu’une approche tout ou rien à la Liferay ? Je crayonne sur mon bloc… « Modularité = Flexibilité = eXo ».
Nous parlons ensuite de licences, LifeRay comme eXo Portal sont open-sources. Puis ensuite quelque chose qui me parle en ce moment : est-il possible d’identifier les attentes des utilisateurs selon leur métier ? Un utilisateur final demande de la facilité d’utilisation. Une interface intuitive, une ergonomie, une simplicité pour qu’il soit autonome. Un administrateur de contenu demande des outils d’administration pratiques et simples. Un admin technique aimerait des Portlets d’administration afin de visualiser la santé de son portail. Un responsable marketing aimerait voir si cette portlet de simulation de crédit fonctionne bien ou non… Bref ce qui est très intéressant c’est qu’il faut penser aux différents types d’utilisateur. Liferay propose ainsi un grand nombre de portlets « out of the box », ce qui permet de commencer à s’en servir rapidement. Dans son Control Panel, un onglet permet de voir aussi la charge mémoire du serveur. Patrice Lamarque mentionne l’utilisation de JMX du côté d’eXo Portal, mais je ne me souviens pas avoir vu pour l’instant de Portlets d’administration.
Bertrand Pinel explique aussi que le choix d’un portail doit s’effectuer par rapport aux respects des standards, comme la JSR-168 et la JSR-286 pour les Portlets, mais aussi la JSR-170 pour tout ce qui est Java Content Repository. Au passage concernant les Portlets, il est important de comprendre qu’en terme de rendu, une Portlet ce n’est pas qu’une petite boite avec un bouton « maximiser » et « fermer ». Une Portlet peu être complétement transparente, le rendu ce n’est que du CSS avec un DIV, et le Portail vous permet bien entendu de ne pas afficher la petite boite autour d’une Portlet. D’ailleurs je trouve dommage de voir par défaut un habillage de ce style dans Liferay, c’est trop réducteur.
Donc retenez qu’une Portlet est un proxy du côté du serveur qui est capable de gérer des événements pour les faire passer à d’autres Portlets. Du côté de l’enveloppe c’est le Portail, donc son thème ou sa skin. Et à l’intérieur de la Portlet, c’est vous avec votre technologie Web : Wicket, JSF, GWT ou JSP par exemple. Bien entendu si vous voulez que votre Portlet ait le look de ses voisines, il faut alors utiliser les feuilles de style du Portail. Mais Liferay par exemple est assez bien fait car il est capable d’habiller votre Portlet si vous ne surchargez pas trop les styles. eXo Portal aussi, le résultat est similaire des deux côtés.
Les slides suivants parlent d’architecture. Une Portlet est une mini-application Web embarquée qui ne peut vivre que dans un Portail. Ensuite, il est intéressant de voir que l’on peut soit faire une application complète avec accès à une base de données, soit une Portlet plus simple qui consommerait des services distants (EJB, REST), soit simplement une Portlet de réaffichage d’un contenu HTML distant (clipping, web proxy et WSRP). Quoi tu veux faire une Portlet avec une IFrame ? Oui monsieur, c’est possible. Imaginez un produit en fin de vie qui tourne sur un autre serveur Web. Avec ce système de clipping il est possible d’aller chercher des pages Webs distantes pour les affichers dans le Portail. Bien entendu ce n’est pas très élégant, mais ça marche.
WSRP est une spécification qui permet à 2 portails de s’échanger du contenu. Un portail expose son contenu avec du WSRP et un autre portail consomme ce contenu. L’usage que je vois pour l’instant est le suivant : imaginons que votre architecture est découpée en plusieurs tiers. Une DMZ Internet avec les serveurs Webs et une deuxième DMZ avec les serveurs d’applications. Entre les deux, des EJB. Bref lorsque vous débarquez avec votre Portail, vous voilà bien embêté. Une idée serait d’installer un Portail dans la zone Internet, et un deuxième Portail dans la zone Service, et de faire communiquer les deux via WSRP. Je ne vous cache pas que cette architecture au final ne résout pas la sécurité, mais permet d’alimenter le portefeuille de l’éditeur de logiciel et du constructeur de machine. Mais bon, lorsque l’on ne peut pas réécrire d’anciens services à la sauce EJB 2.1, je dis : pourquoi pas ?
Voyons maintenant le marché des Portails Open-Source :
La suite présente ensuite le projet Jahia qui est un gestionnaire de contenu très bien fait, à la Joomla en PHP par exemple. Je le testerai pour vous en reparler.
JBoss Portal ensuite, est la solution de Portail de RedHat JBoss. Un peu austère, mais avec un moteur technique vraiment très puissant, il manquait à JBoss une couche applicative.
eXo Portal par la société eXo Platform ensuite. Avec une centaine de collaborateurs, eXo est présent sur ce marché depuis de longues années. Membre du JCP sur la JSR-168 et la JSR-286, comme JBoss, les équipes d’eXo proposent en plus des solutions applicatives prêtes à l’emploi et modulaire.
J’ai appris que Sacha Labourey (ex JBoss) avait rejoint le Board of Advisors de l’équipe d’eXo Platform (voir le communiqué de presse ici). Quand on sait qui est Sacha, je peux vous dire que c’est un peu comme si David Beckham venait jouer dans votre club de foot. C’est juste énorme. Il est certain que l’on va entendre parler d’eXo Platform dans les mois qui viennent.
Bertrand Pinel parle ensuite du projet GateIn, qui est le rapprochement des équipes de JBoss Portal et des équipes d’eXo Portal. A priori d’après les rumeurs, la version Beta 2 de GateIn devrait sortir d’ici quelques semaines. Les équipes travaillent en ce moment à fond, et je crois que je le testerai pour vous en reparler un peu plus tard.
Liferay ensuite est présenté. Avec 90 000 téléchargements par mois, c’est clairement un acteur très important, très populaire. Ippon Technologies a une très bonne expertise sur LifeRay, Geoffray Gruel était la semaine dernière en Allemagne au Symposium Liferay. Installation facile, communauté importante, LifeRay manque un peu de présence en France par rapport à eXo Platform, mais se rattrape avec la taille de la communauté. Bref c’est une solution à étudier. Un point où j’émets une réserve, c’est le côté « tout-ou-rien » où l’on installe LifeRay, puis ensuite on découvre un peu les Portlets, mais on ne parle pas de produits. J’ai compris que chez eXo Platform, il y a de réels produits, avec des chefs de produits comme Patrice Lamarque qui était présent. C’est intéressant car cette approche produit est plus ouverte. Là où LifeRay c’est la suite Office, eXo semble proposer des briques selon vos besoins. Bon je jette un peu trop de fleurs sur eXo Platform alors je vais dire un truc négatif : je trouve que LifeRay est mieux terminé au niveau de l’interface utilisateur qu’eXo Portal 2.5. Plus intuitif. Maintenant avec le nouveau GateIn, j’ai aussi l’impression que dans les mois qui viennent, les gens d’eXo vont repasser devant.
Les points forts de Liferay ensuite : seul portail open-source cité en 2008 par le Gartner, sa licence MIT permet de changer le code, sans être tenu de le reverser dans le domaine publique. eXo Portal est distribué en licence Affero GPL. Vous pouvez changer le code, le partager, le distribuer, mais je crois que vous êtes tenu de le faire. Je ne sais pas vraiment la différence, mais Bertrand Pinel semble dire que Liferay vous permet plus de faire ce que vous voulez qu’eXo.
Les cas d’utilisation
Cette partie présente un retour sur expérience avec quelques exemples de projet type réalisé avec des Portails:
– Intranet usine à sites
– Bureau Virtuel
– Internet de Mutualisation
L’intranet usine à sites est un projet orienté contenu, qui vise à faciliter la communication dans l’entreprise, entre différents départements. Le Portail offre la possibilité d’agréger du contenu. Il propose aussi de travailler à plusieurs équipes, de construire du contenu commun. C’est donc un projet piloté par le contenu.
Bertrand rappelle l’importance des comités de pilotage et des équipes d’encadrement. C’est le projet réalisé avec eXo Portal et eXo WCM par les équipes de GlobeCast que nous verrons ensuite.
Le Bureau Virtuel est un projet où l’objectif est de construire un espace de travail pour le collaborateur. Chacun peut piocher des appliquettes dans une liste d’application pour les placer sur son bureau virtuel. Ici c’est la possibilité de personnaliser qui est mise en avant. C’est donc un projet piloté par les services que l’on souhaite offrir. J’aime beaucoup cette idée, où l’utilisateur final se construit son espace de travail. Dans la Finance prenons un opérateur du Front-Office qui traite sur le marché Européen le matin puis les US l’après-midi. Grâce au portail il peut se construire un espace dédié pour sa vue du matin, puis basculer vers un autre environnement l’après-midi. Je me souviens aussi d’une présentation d’Oracle qui, pour la Société Générale, a proposé de construire un bureau virtuel pour les conseillers en Agence. Lorsque vous viendrez en agence, une fois assis le conseiller aura une vue qui se sera personnalisée selon votre profil. Vous avez besoin d’un crédit à la consommation ? Une portlet s’affiche pour que le conseiller puisse vous faire une offre. Et c’est un crédit auto ? Une deuxième Portlet pour l’Assurance voiture apparaît alors… C’est donc un bureau qui s’adapte aussi à ce que vous êtes entrain de faire. J’adore l’idée d’avoir un logiciel qui s’adapte à l’usage. Oui c’est de l’ergonomie, mais c’est un truc qui coûte une fortune avec une application Web classique, bien rigide, et bien incapable de s’adapter nativement à vous, l’utilisateur.
Le troisième type de projet est l’intégration d’applications hétérogènes. Prenez un SI d’entreprise : un moteur Documentum, un annuaire LDAP sur Active Directory Server, un agenda sur Lotus Notes, le Portail est capable d’agréger des contenus différents, provenant de sources diverses. Evidemment, ces connecteurs sont spécifiques à chaque Portail. Mais Documentum propose ses propores portlets standards par exemple. C’est donc un projet plus piloté par l’infrastructure pour le coup.
L’exemple d’un site mutualisé qui regroupe différents départements est pertinent, c’est ce que je fais en ce moment. Comment regrouper sous une même bannière des applications Webs différentes ? Comment proposer plusieurs services à un seul utilisateur final ? Un Portail est donc aussi un moyen de présenter à un seul endroit les services de son SI (voir aussi cet article)
Ce que je retiens c’est que certains projets de Portail permettent aussi de refondre le SI, en pilotant le développement de l’architecture par la couche de présentation. Oui je sais c’est bien capilo-tracté (tiré par les cheveux). Bon si vous voulez que l’on en parle vous m’appelez. Cela me donne envie de préparer une présentation pour l’USI pour 2010 par exemple. Va falloir décanter ces idées pour vous les présenter correctement.
Témoignagnes de GlobeCast et FranceBillet
Pour revenir au séminaire, nous avons ensuite assisté à 2 présentations de 2 clients d’Ippon Technologies. GlobeCast tout d’abord qui est une filliale de France Telecom, a présenté un projet d’Intranet réalisé avec eXo Portal et eXo WCM. La deuxième présentation était un projet de portail LifeRay business-to-business par FranceBillet, la billeterie du groupe Fnac, qui a de grosses références comme le concert de U2 dernièrement par exemple.
Nous avons terminé la matinée par une séance de questions/réponses. J’ai noté quelques questions autour de la sécurité. LifeRay a des failles de sécurité de type XSS connues et donc rapidement corrigées. C’est l’avantage de l’open-source. Mais donc attention avec la sécurité, un monsieur sécurité chez un éditeur ne serait pas une mauvaise idée je pense.
Ensuite concernant GWT j’ai demandé si l’une des 2 équipes avait fait un projet avec du GWT. Bertrand Pinel cite avec LifeRay le projet Vaadin. Après enquête en effet j’ai trouvé un exemple avec une application GWT qui propose un PortletContextListener afin de pouvoir faire suivre sous forme d’événements ce qui vient du monde GWT. Bon, allez je vous vois venir : je ferai un article là dessus un peu plus tard pour présenter ce principe. A vue de nez je pense même qu’il sera possible de faire aussi une version eXo Portal facilement. Voir les articles sur le site de Vaadin sur ce sujet.
Conclusion
Grâce à Ippon Technologies, nous avons eu encore une bonne présentation sur le thème des Portails et des Portlets. Les témoignages ont surtout mis en avant le besoin d’une organisation et d’une structuration pour développer un projet avec un Portail. Autant la première partie était technique, avec une présentation à la JUG, autant j’ai aussi bien aimé ensuite la seconde partie nous expliquant la démarche projet. J’ai rencontré au buffet d’autres personnes qui étudient aussi les portails. Nous avons eu aussi la chance de bien discuter avec Patrice Lamarque d’eXo Platform. La nouvelle version du moteur d’eXo s’appelle GateIn. Fruit du rapprochement entre JBoss et eXo Platform, il est très prometteur. Je pense que nous aurons une nouvelle génération de Portails d’ici quelques mois.
Les Portails version 2010… Je vois bien une révolution où l’utilisateur est mis au centre de la nouvelle architecture de l’information. Pensez au développeur, à l’administrateur, au chef produit, à la responsable marketing, à l’utilisateur final… Le Web sera incontournable, la personnalisation aussi. Il ne manque plus que le Portail Mobile, léger et adapté au format de nos petits écrans, des outils avec une ergonomie très poussée pour que tout le monde puisse s’en servir.
Le premier qui proposera un PortailOS aussi bien que mon iPhone aura juste gagné. Je pense à un OS qui marcherait bien entendu sur mon navigateur standard, pas spécifiquement sur mon mobile.
Le premier qui proposera un site marchand avec des Portlets ou des Gadgets aura aussi gagné. Un annuaire des Gadgets et des Portlets en quelques sortes.
Le premier qui aura des outils d’administration standards pour des administrateurs, des responsables de campagne marketing, des développeurs aussi pour construire des pages rapidement, celui-là aura aussi gagné.
Le premier… on en est pas loin je pense.
Références
Les slides de la présentation sont sur le blog d’Ippon Technologies.
Super article, ça donne envie d’essayer tous ces produits. C’est dommage la présentation manque de comparaison entre produits open sources et éditeurs (Vignette, Open Text, Sharepoint, etc).
sinon en open source il y a aussi ce portail : http://portalpack.netbeans.org/
Merci pour cette description tres pertinente du monde des portails Java. Il semble en effet qu’il n’en reste que deux.
Ce qui est aussi interessant à comprendre c’est l’écosystème qui se construit autour.
Liferay est déjà intégré avec Alfresco (CMS), Sun OpenSSO et Intalio (BPMS). Alfresco et Intalio ont la particularité d’offrir des versions gratuites bien moins finalisées et avec moins de service que la version payante (c’est à savoir). Quand a Sun, qui avait basé son offre sur Liferay, il est presque certains que cela ne continuera pas vu l’argent que met Oracle pour intégrer son portail et celui de BEA.
GateIn, est en fait le portage d’Exo sur l’infrastructure JBOSS. Et la on peut imaginer que les produits RedHat vont s’intégrer très rapidement dans le portail.
Le support Liferay est assez cher, je ne connais pas celui d’exo.
En ce qui me concerne, je considère Liferay comme un framework avancé de portails, organisé pour pouvoir être étendu. Exo est plus un produit avec une vision produit et une découpage basé sur les besoins utilisateurs. Le gros problème d’exo etait son manque de support en dehors de France.
Concernant la licence exo, je crois me rappeler que comme il fabrique un produit, l ne souhaite pas qu’on « modifie le coeur » du produit car il peut rendre la suite instable. Mais bon, ce sont des gens intelligents et ouverts, donc je ne pense pas que cela soit un problême.
Concernant l’intégration, je souhaiterais ajouter à ta vision un produit Français, convertigo, et son mahup server. Se produit se positionne entre le portail et tes applications legacy et transforme en flux XML des données provenant des interfaces graphiques de tes applications. C’est en quelque sorte de l’intégration a niveau le plus haut, au niveau de la GUI. Pas besoin de web service, ou de REST (quoi qu’il sait les gerer), il suffit d’un acces à l’application. Et bien sur, il offre le mashup soud forme de widget. Pour des projets ou il faut aller vite et ne pas dépenser trop, c’est idéal.
http://www.convertigo.com/. En général, ils viennent dans vos locaux et font un widget avec vos applications en 1 heure.
Enfin, je dirais que Liferay n’est pas certifié sur tous les serveurs d’application. En fait, il y a quelques mois, il n’y avait pas de certification du tout. On a eu quelques problemes pour le faire tourner sur du weblogic en cluster.
Enfin, il existe des solutions liferay dans le cloud pour des tarifs tellement bas que je n’ose vous en parler ici.
@William merci pour ton retour. On me dit maintenant souvent que les commentaires sur le Touilleur Express sont aussi intéressants que les articles. Grâce à ta contribution je vais aller regarder Convertigo. Merci
Merci pour ce billet et pour les commentaires.
J’ai néanmoins toujours la meme question n’ayant personnellement jamais mis en oeuvre de projets de portails de portlet.
Bien sur on dit qu’il ne faut pas voir une portlet comme une petite boite mais dans ce poste on dit aussi que l’avantage d’avoir des portlets est de pouvoir faire passer une information d’une portlet à une autre. Hors ce genre d’avantage n’a de sens que si l’ on affiche 2 portlets dans la meme page il me semble (donc en tant que « boite »…)
Sinon j’étais moi meme à cette présentation et j’ai pu discuter avec un des architectes Ippon qui travaille sur Liferay.
Ma question était « dans quel cas est-il recommandé de choisir un portail de portlet de type Liferay » par rapport à faire une application J2EE simple, flexible sachant que faire du SSO c’est pas si complique que ça et qu’ajouter un module métier dans une application J2EE pour appeler un WS ou juste faire un traitement métier n’est pas si compliqué que ça ».
Après discussion et surtout l’exemple du projet sur lequel il bossait, j’ai pour ma part l’avis que l’utilisation d’un portail de type portlet n’ a du sens que si au moins 80% du réel besoin (et non du besoin futur, potentiel etc…) peut être couvert par les portlets fournies et customisées.
Exemple: faire des espaces collaboratifs relatifs à des projets avec échanges de fichiers, avec du CMS…
Mais que si l’on veut faire un « portail » avec des services métiers sur mesure, le gain au niveau authentification/authorisation n’est pas rentable par rapport aux contraintes d’utilisation.
On peut se baser sur du Spring Security et JOSSO ou CAS pour faire la meme chose et on a la main sur tout.
Mais bon apres c’est mon avis personnel n’ayant encore une fois jamais mis en oeuvre de « portails de portlet »
Gilles S
@GillesS Pour ma part, le projet portail s’inscrit dans le cadre d’un projet où 4 équipes différentes, dont 1 à Paris, doivent collaborer et livrer des services différents. La contractualisation des Portlets nous permettra d’échanger des données entre les portlets. Et la possibilité de ne déployer qu’une partie des Portlets pour chacune des équipes facilite le travail de développement. Mais je t’en reparlerai dans quelques mois pour voir si cette idée marche, ou pas. A suivre.
Merci Nicolas!
@GillesS Plutôt d’accord avec le conseil d’Ippon, même si les apports du portail en tant qu’infrastructure (en dehors du catalogue de portlets) ne se limitent pas à la partie authentification/rôles :
– gestion des thèmes
– gestion du layout des pages
– gestion des préférences utilisateurs
– configuration déclarative voire WYSIWYG des pages
– IHM d’admin
…
Et une des idées de base, c’est quand même de créer du contenu et des traitements qui soit réutilisables dans d’autres applis via le standard des portlets. OK, c’est parfois illusoire, mais suivant les archis, ça peut être assez puissant.
Sylvain FRANCOIS
Kalistick
Bon je vais parler en ma qualité de développeur d’une solution mineure sur ce marché du portail (je travaille pour Silverpeas une solution de portail collaboratif opensource).
Je trouve que le portail en tant que tel a vécu et qu’on va vers un monde de convergence des portails (au sens intégration d’applications ou de services du SI), des outils collaboratifs (wiki, ….) et CMS (voire des outils comme la GED). Ce sont d’ailleurs des outils très variés que l’on voit sur ton graphique CMSWatch.
Si je me base sur les demandes de nos clients on voit bien qu’ils veulent un peu de tout ça et c’est dans ce sens qu’on évolue (et tant pis si j’ai dévoilé notre stratégie top secrète). En tout cas après quelques années plutôt tranquilles on sent bien que ce domaine bouge très fort en ce moment.
Emmanuel
Je ne suis pas d’accord avec l’affirmation selon laquelle (je cite) « les portlets sont en quelques sortes des applications légères ».
Si les portlets étaient des applis web, alors les portlets devraient disposer de fonctionnalités proches de celles des modules OSGi, un id, des définitions de dépendances entre modules, une partie publique (API publique) et une partie privée (implémentation). Or, en gros, cela n’est pas le cas.
Je crois que le match entre les portlets et OSGi va finir par se transformer en un remake du match entre les superordinateurs spécialisés faisant état d’une techno ad hoc (~ portlets) et les clusters de PC (~ OSGi). De fait, il y a déjà plusieurs serveurs Java qui permettent de déployer des modules OSGi tout en pouvant faire appel aux API Java EE, comme le serveur Spring et le serveur JOnAS. Il est donc loisible d’imaginer implémenter les portlets comme des modules OSGi.
Certains découpent leur back-office en serveurs pour faire tourner la partie présentation (JSP) et la partie métier (avec une facade EJB ou WS). Toujours dans la même optique, je ne vois pas les portails dans la brique métier, mais dans la brique présentation et par conséquent, je ne vois pas les portlets comme des applications légères.
De fait, par ex, pour un besoin CMS/ECM, je suis plus d’accord avec l’approche Nuxeo qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir ~ approche métier=>présentation.
1) bref, encore une fois, IMHO, les portlets, il s’agit pour moi plus d’intégration graphique que d’intégration métier ; de fait, même la sécurité peut être réglée en dehors des portlets !
1-bis) Et cela m’amène à m’interroger sur l’intérêt d’un portail (coté serveur, donc). Comme j’ai pu l’écrire ici ou là, choisir un portail ressemble un peu à choisir de construire sa maison en bois uniquement parce que… la porte d’entrée est en bois. De fait, seule la page d’accueil d’un portail contient des portlets customisables, pourquoi vouloir utiliser la technologie portlet pour toute une appli web sachant que seule la page d’accueil doit être customisable ? C’est pour le moins étonnant, non ?
2) les portlets ont connu différentes vies et des débuts difficiles.
Je me rappelle des tout débuts, un vendeur m’a indiqué qu’avec les portlets,
– on ne pouvait pas faire de clustering de session http (trop compliqué/lourd),
– on ne pouvait pas utiliser de JSP avec son produit (on devait coder l’IHM en Java dans la portlet, idem les débuts des servlets, avant les JSP).
Dur.
Puis les portlets se sont améliorées,
Puis les portlets ont pris une « claque » avec l’arrivée d’AJAX,
Puis les portlets se sont améliorées (itou).
Puis…
Et bien, les portlets sont encore à la merci d’autres claques (cf. plus bas).
En fait, je me demande si toutes ces évolutions et le pb des portlets ne viennent pas du fait que les portlets se situent au niveau API, mais aussi en bonne partie au niveau d’un design d’architecture (auquel appartient REST par ex), et au niveau framework, comme le suggèrent, par ex, les 2 points suivants de la spec:
# two phases of action processing and rendering in order to support the Model-View-Controller pattern.
# portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate
Dit autrement:
– si on choisit d’abord de faire des portlets, on est souvent embété ensuite par le choix d’un framework web, et son intégration avec les portlets (c’est pourquoi il y a(vait?) des bridges proposés), ce qui est pour le moins énervant alors que les portlets sont là principalement pour designer la page d’accueil.
– une autre manière de faire est de choisir un framework web (autre que les portlets) et de suivre le design d’architecture des portlets (sans utiliser un framework portlet dédié ad hoc) – ce qui est facilité car les frameworks JavaScript apportent déjà pas mal, et par le fait qu’un framework web peut remplir certaines fonctionnalités des portlets de niveau framework.
2-bis) Personnellemment, je suis plutôt preneur de la seconde approche – qui est en accord avec (1) et (1-bis).
Cela me semble en accord, par ex, la vision Nuxeo (qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir)
3) je me demande si la spec portlet n’aurait pas été plus simple en mettant l’accent sur l’approche « convention plutôt que configuration », un peu à la REST.
Cela aurait peut-être plus facilement permis de définir des portlets, sans framework portlet, en laissant la liberté à chacun utiliser son framework web préféré (par ex, en définissant un paramètre jportletid comme il existe un jsessionid) pour implémenter des portlets.
4) Je crois que la prochaine « claque » prise par les portlets pourrait venir de GWT.
Les porlets ont pris une « claque » avec AJAX et se sont mises à la sauce AJAX.
Maintenant, IMHO, on peut diviser une portlet en une partie cliente et une partie serveur. Or, un des frameworks web pour mixer JavaScript/Java et partie client/serveur, c’est GWT qui fait de la traduction Java/JavaScript.
De fait, je me demande, dans le cas où l’on devrait repenser les portlets de zéro, si une approche GWT ne serait pas au centre d’une telle initiative, offrant un conteneur (avec services associés) qui s’étendrait à la fois coté client et coté serveur.
x) Bref, je me demande si la plus grosse difficulté des portlets ne viendrait pas du fait qu’elles ont le cul entre plusieurs chaises, niveau architecture/framework/API, niveau client/serveur, niveau présentation/métier…
De fait, les portlets se « battent » sur tous les fronts ~ semblent en concurrence (à tort ou à raison) avec plein d’autres solutions, et sont sans cesse « bousculées » par les avancées dans les domaines connexes (i.e. l’introduction de AJAX). Et cela amène à évaluer leur ROI par rapport au cout de mise en oeuvre.
IMHO, je pense qu’il y a des cas d’utilisation, mais qu’ils sont la minorité (~ des cas particuliers) plutôt que la majorité, pour toutes les raisons invoquées plus haut = faut pas foncer tête baissée sur les portlets quand quelqu’un prononce le mot portail.
Je ne suis pas d’accord avec l’affirmation selon laquelle (je cite) « les portlets sont en quelques sortes des applications légères ».
Si les portlets étaient des applis web, alors les portlets devraient disposer de fonctionnalités proches de celles des modules OSGi, un id, des définitions de dépendances entre modules, une partie publique (API publique) et une partie privée (implémentation). Or, en gros, cela n’est pas le cas.
Je crois que le match entre les portlets et OSGi va finir par se transformer en un remake du match entre les superordinateurs spécialisés faisant état d’une techno ad hoc (~ portlets) et les clusters de PC (~ OSGi). De fait, il y a déjà plusieurs serveurs Java qui permettent de déployer des modules OSGi tout en pouvant faire appel aux API Java EE, comme le serveur Spring et le serveur JOnAS. Il est donc loisible d’imaginer implémenter les portlets comme des modules OSGi.
Certains découpent leur back-office en serveurs pour faire tourner la partie présentation (JSP) et la partie métier (avec une facade EJB ou WS). Toujours dans la même optique, je ne vois pas les portails dans la brique métier, mais dans la brique présentation et par conséquent, je ne vois pas les portlets comme des applications légères.
De fait, par ex, pour un besoin CMS/ECM, je suis plus d’accord avec l’approche Nuxeo qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir ~ approche métier=>présentation.
1) bref, encore une fois, IMHO, les portlets, il s’agit pour moi plus d’intégration graphique que d’intégration métier ; de fait, même la sécurité peut être réglée en dehors des portlets !
1-bis) Et cela m’amène à m’interroger sur l’intérêt d’un portail (coté serveur, donc). Comme j’ai pu l’écrire ici ou là, choisir un portail ressemble un peu à choisir de construire sa maison en bois uniquement parce que… la porte d’entrée est en bois. De fait, seule la page d’accueil d’un portail contient des portlets customisables, pourquoi vouloir utiliser la technologie portlet pour toute une appli web sachant que seule la page d’accueil doit être customisable ? C’est pour le moins étonnant, non ?
2) les portlets ont connu différentes vies et des débuts difficiles.
Je me rappelle des tout débuts, un vendeur m’a indiqué qu’avec les portlets,
– on ne pouvait pas faire de clustering de session http (trop compliqué/lourd),
– on ne pouvait pas utiliser de JSP avec son produit (on devait coder l’IHM en Java dans la portlet, idem les débuts des servlets, avant les JSP).
Dur.
Puis les portlets se sont améliorées,
Puis les portlets ont pris une « claque » avec l’arrivée d’AJAX,
Puis les portlets se sont améliorées (itou).
Puis…
Et bien, les portlets sont encore à la merci d’autres claques (cf. plus bas).
En fait, je me demande si toutes ces évolutions et le pb des portlets ne viennent pas du fait que les portlets se situent au niveau API, mais aussi en bonne partie au niveau d’un design d’architecture (auquel appartient REST par ex), et au niveau framework, comme le suggèrent, par ex, les 2 points suivants de la spec:
# two phases of action processing and rendering in order to support the Model-View-Controller pattern.
# portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate
Dit autrement:
– si on choisit d’abord de faire des portlets, on est souvent embété ensuite par le choix d’un framework web, et son intégration avec les portlets (c’est pourquoi il y a(vait?) des bridges proposés), ce qui est pour le moins énervant alors que les portlets sont là principalement pour designer la page d’accueil.
– une autre manière de faire est de choisir un framework web (autre que les portlets) et de suivre le design d’architecture des portlets (sans utiliser un framework portlet dédié ad hoc) – ce qui est facilité car les frameworks JavaScript apportent déjà pas mal, et par le fait qu’un framework web peut remplir certaines fonctionnalités des portlets de niveau framework.
2-bis) Personnellemment, je suis plutôt preneur de la seconde approche – qui est en accord avec (1) et (1-bis).
Cela me semble en accord, par ex, la vision Nuxeo (qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir)
[la suite, en dessous]