Tout d’abord, regardons un peu le marché des portails d’intégrations. L’étude « Magic Quadrant for Horizontal Portals » de 2009 est intéressante, car elle donne un état du marché, et quelques indications sur les acteurs du marché. 2 phrases retiennent mon attention : « By 2011, Gartner expects at least 15% of new enterprise portal projects in Global 2000 firms to use open-source horizontal portal frameworks. » et « By 2014, horizontal portal products based on portal containers will be used for no more than 60% of new enterprise portal projects.« .
En 2014, Gartner estime à 60% le nombre de nouveaux projets basés sur les portails d’intégration… C’est dans 5 ans… allo ?

Le marché des portails est actuellement dominé par IBM, Oracle et Microsoft. Cependant, un effet bénéfique de la crise, c’est que les budgets d’investissement pour les portails internes ont connu un sacré ralentissement en 2009. Cela a pour effet de profiter directement à des acteurs comme Liferay, RedHat et eXo Platform. Le rapprochement entre eXo Platform SAS et Red Hat Inc. est certainement un signe fort qu’en 2010, ces deux là viendront perturber le marché avec un objectif à 5 ans très clair : devenir la première solution open-source java de portails d’entreprise. Liferay n’a qu’à bien se tenir.

La semaine passée j’étais en formation à Paris avec Julien Viet, ancien de RedHat et maintenant Lead Developer chez eXo Platform, sur le Portail. La formation s’est déroulée sur 2 jours. Elle permet tout d’abord de comprendre la culture et le positionnement des Portails. Lorsque nous parlons de Portails, certains en ont une vision très Web. Ils imaginent des mashups, une page à la iGoogle. D’autres en ont une vision plutôt orientée middleware/service. Les portails sont des ponts entre différents services et une application Web. Et c’est cette culture qui doit, à mon avis, encore être travaillée. Liferay a quelque chose que son voisin n’a pas encore : une sacré interface prête à l’emploi avec ses quelques 60 petites applications. Son plus gros avantage et aussi son plus gros défaut. Petites applications, pas produits.

Liferay descend du monde du Web, et s’adresse maintenant à l’infrastructure. Au contraire, JBoss Portal est un logiciel qui vient du monde du middleware, avec un socle robuste, un moteur d’exécution proche quelque part d’un serveur d’application. eXo Platform propose une vision plus produit, qui n’est ni du Web Portlet, ni du MiddleWare, mais ce que j’appellerais un moteur d’execution pour applications webs. C’est peut-être le code génétique de GateIn.

GateIn est taillé pour être un moteur d’hébergement d’applications, comme JBoss Portal. Mais il est aussi structuré pour proposer de vrais produits plutôt qu’une boîte à Portlets comme chez Liferay.
GateIn est le moteur de départ sur lequel nous allons déployer d’une part les produits eXo Platform, mais aussi votre propre application portail. Les produits eXo Platform permettent de gérer du contenu (eXo WCM), de gérer des documents (eXo DMS), de configurer finement la validation (eXo Workflow), de créer des forums et des FAQs intelligentes (eXo KS) et propose aussi une suite d’outils collaboratifs (eXo CS). Encore une fois, là où Liferay propose des Portlets, eXo Platform propose de réels produits, avec la documentation et les équipes produits, avec un service plus adapté à l’entreprise.

Maintenant attention, il semble que la bonne pratique est de se baser sur des solutions plus complètes dès lors que les besoins de base ne sont pas couverts par le Portail. Liferay dès le guide de l’utilisateur, vous oriente vers Alfresco si vous souhaitez utiliser une solution de publication de contenu complète (CMS). Et eXo Portal fonctionne aussi d’ailleurs très bien avec Alfresco.

On comprend donc que l’énergie maintenant n’est plus dans le développement d’une application web avec son authentification, sa gestion de la mise en page, son cycle de vie… Non j’ai presque envie de croire que c’est terminé.

Liferay et GateIn vous font regarder vers une nouvelle direction, qui me semble plus intelligente pour l’entreprise : l’intégration d’application dans un portail plutôt que l’intégration d’un service dans une application Web. Les produits d’eXo Platform seront tous bientôt compatibles avec GateIn, qui se positionne comme un moteur d’exécution, une plate-forme, et la porte d’entrée vers le monde de l’entreprise.

Pour revenir à l’intégration de solutions existants, prenez SugarCRM par exemple pour la gestion de la relation clientèle. Une fois intégré avec un moteur de publication de contenu, voilà votre site Internet d’entreprise avec son extranet. Si bien sûr votre métier est de développer des applications de gestion, peut-être que cela vous semble abstrait. Mais si votre métier est de développer des solutions webs d’entreprise, et bien cela devrait vous parler.

Quelle entreprise en 2015 pourra se passer d’un site Internet, avec un extranet sécurisé pour ses employés, un outil de gestion de la clientèle, un Wiki, des Forums, et un moteur de publication pour les pages ?
Dîtes-moi qui pourrait se passer de ces outils ?

Rendez-vous maintenant pour construire ensemble pas-à-pas un nouvel écosystème d’applications dans GateIn. Première étape : installer GateIn, faire le tour du propriétaire, puis ensuite commencer à mettre ses premières applications.

A dans 5 ans ? ou à demain ?

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.

Un portail offre un grand nombre de services à une application web
Si vous avez déjà développé des applications webs en Java, vous serez d’accord sur le fait que les besoins fonctionnels et techniques des applications webs sont récurrents. Justement, les Portails d’intégration offrent un ensemble de fonctions standards. Voyons d’abord ce qu’il est possible de faire.

Les services offerts par un Portail sont :
– la gestion de l’authentification des utilisateurs
– l’autorisation afin de déterminer les droits d’accès aux différentes parties de l’application
– la personnalisation afin que l’application web s’adapte au profil du visiteur (P13N)
– la possibilité de personnaliser son interface web facilement
– la gestion de la navigation et sa définition (catégories, pages, sections)
– création des pages de contenu (pages statiques, intégration de pages d’un autre serveur)
– gestion de l’internationalisation (I18N)
– la possibilité d’intégrer du contenu web d’une application distante
– le support sans restriction des frameworks Web
– la possibilité de mettre en ligne des services dans des Portlets rapidement
– la capacité à offrir une version adaptée aux téléphones portables
– l‘offre de composants standards Web 2.0 comme Wiki, Blog, Aggregateur, Mash-ups, etc
– le support des Gadgets à la Google
– la possibilité d’offrir des services de recherche, de gestion de contenu, de gestion électronique de document

Un moteur de Portail open-source du monde Java comme GateIn (JBoss Portal + eXoPortal) ou Liferay est donc un moyen de gagner du temps en évitant de développer ou de devoir gérer des fonctions standards d’une application Web. L’installation est simple : un WAR déployé sur un serveur J2EE léger, et c’est tout.

Si vous disposez d’une application Web Java, le déploiement s’effectue en quelques clics dans le portail. Pour aller plus loin, la création de quelques portlets permet en fait d’exposer les fonctions clés de son application web, afin que le Portail puisse gérer le cycle de vie et l’affichage de votre portlet.
Une chose intéressante à noter : vous êtes libre d’utiliser n’importe quel framework Web : GWT, Wicket, JSF ou autre. De ce fait, la migration d’une application J2EE est donc relativement simple.

Qu’est-ce qu’une Portlet ?
Les Portlets 2.0 ont été normalisées en juin 2008. C’est une spécification assez bas niveau, proche des Servlets. Une Portlet est une enveloppe pour votre application web. Elle dispose de différents états : minimisée, normal, maximisée. Il est aussi possible de basculer d’un mode vue à un mode édition pour la configuration. Du côté du code, en attendant que je vous propose d’autres articles, il y a une distinction entre la phase de rendu et la phase d’action. Le rendu est simplement l’action d’afficher la Portlet. La phase d’action permet de gérer les interactions entre l’utilisateur et l’application web. Enfin il est possible d’émettre des événements afin que d’autres Portlets soient notifiées et puissent interagir avec votre Portlet. C’est relativement simple, l’API Portlet 2.0 propose des annotations qui permettent de marquer vos méthodes. Il y a une petite gymnastique à apprendre afin d’adapter vos pages de rendus par rapport à la navigation. Du côté de la gestion des ressources (js,css,images) il est nécessaire que la Portlet gère le chargement de ces ressources, en raison de la gestion de la sécurité et du cache.
Le contenu d’une Portlet enfin peut être caché par le Portail afin d’éviter le rechargement systématique du contenu.

Les portlets offrent en fait un moyen standard et normaliser de déployer son application et d’interagir avec d’autres Portlets. Et il est tout à fait envisageable d’écrire des Portlets standards, sans tomber dans le piège d’utiliser une API propriétaire.

Le modèle de programmation des Portlets (avec l’aide de Julien Viet d’eXo Platform)
Le modèle de programmation natif d’une Portlet est similaire à celui des Servlets. Il se fait via le package javax.portlet. Le modèle de programmation est légèrement différent, comme expliqué au paragraphe précédent. La plupart des équipes de développement n’utiliseront pas directement l’API, pour la même raison que l’API Servlet en général n’est pas utilisée directement mais via un framework.

En effet, la plupart des frameworks modernes proposent un adaptateur pour Portlet (Portlet Bridge). Avec un modèle de programmation bien pensé, l’exécution en mode Portlet ou directement dans une application web ne présente pas de différences pour le framework. Si vous débutez un projet basé sur des Portlets, il sera important de s’assurer de ce support dans votre framework Web avec un adaptateur pour Portlets. Les plus connus possèdent tous un bridge comme Java Server Faces (via la JSR 301 Portlet Bridge Specification), Wicket, Struts2 et Tapestry.

D’autres framework web tel que Spring MVC ne proposent pas une telle portabilité mais néanmoins fournissent un support pour les Portlets en adaptant le framework à l’API Portlet. J’ai codé une Portlet avec Spring MVC sans soucis, grâce à SpringFuse l’outil de Celerio.

Finalement pour de vieilles technologies telles que Struts 1, il existe des bridges mais qui sont gérés à un niveau en dessous avec une émulation de la couche Servlet via une Portlet. En général ce type de bridge a des limitations.

Les Portlets permettent de travailler à plusieurs équipes sur une même application web
Je prends le temps de vous parler de déploiement car le principe des Portlets permet de travailler par modules. Imaginez plusieurs équipes de développement qui travaillent sur un portail web d’entreprise. En se donnant rendez-vous techniquement sur un Portail, vous pouvez donc offrir un moyen pour chaque équipe de travailler de son côté, avec une installation locale de Liferay ou de GateIn, puis de livrer simplement leurs Portlets vers le serveur de production. Un administrateur se chargera alors d’ajouter et de mettre en place les Portlets du premier projet. J’y vois donc un moyen de faciliter le travail de plusieurs équipes. En effet, c’est bien plus souple que d’imaginer livrer un gros WAR constitué de plusieurs projets développés par plusieurs équipes. Imaginez la difficulté pour l’intégration et la mise en production. Un Portail d’intégration est donc un serveur mutualisé sur lequel plusieurs équipes déposent des Portlets, qui constituent au final une application Web complète.
Le portail permet de découpler le cycle de vie du portail et des applications qui le composent. En effet vous pourrez facilement intégrer de nouvelles applications dans le portail à tout moment. Un autre intérêt de ce type d’architecture est l’intégration d’applications basées des technologies hétérogènes. Vous pourriez vouloir intégrer dans votre portail une application développée 2 ans auparavant par une filliale de l’entreprise par exemple.

Chez le client chez lequel je travaille en ce moment, ce sera le moyen pour trois équipes à Paris, une à Londres et une à New-York de construire une plateforme de Prime Brokerage avec la même charte graphique, une seule authentification, la gestion de plusieurs langues, et surtout vous l’aurez compris, la possibilité pour chacune de ces équipes de travailler sur leurs Portlets et de les tester en local avec un Portail open-source avant le passage en production.
Les Portlets ne sont pas révolutionnaires. Par contre, c’est l’utilisation dans votre architecture qui le sera. En effet, si vous avez aujourd’hui plusieurs équipes ayant réalisées chacune une application web, il est possible de repenser le système non pas avec une architecture SOA, mais une architecture Web Portal. Au lieu d’agréger des services différents dans un seul endroit pour construire une seule application web, vous offrez la possibilité à chaque équipe de livrer une tranche verticale qui va de la donnée à la couche web en passant par la couche service. Et quelque part, est-ce qu’une application Web dont l’architecture serait définie par l’interface graphique n’a pas plus de sens qu’une application web construite comme un puzzle de services ?

L’exemple d’Amazon.com
La page d’Amazon.com est construite par 34 équipes différentes. Chacune des parties de la page est une Portlet. C’est assez génial car la mise en production d’une nouvelle version n’est plus un problème : il n’y en a plus !
Terminé la mise en ligne d’une application Web complète.

Alors comment font-ils ?
Lorsqu’une équipe est confiante sur une nouvelle fonction, une nouvelle version de sa Portlet est activée sur le Portail. En cas de problèmes, l’administrateur peut aussi rapidement désactiver une Portlet, voire même recharger une version antérieur. Quand on pense à Scrum, à de l’incrémental, il paraît évident que ce Portail va vraiment devenir votre ami non ?

Une porte ouverte vers une architecture WoPA (Web Oriented Portal Architecture)
Je pense que les applications d’entreprises sont amenées à s’ouvrir de plus en plus. Nous avons pensé un moment qu’une architecture orientée service serait la solution. Ces 5 dernières années en effet, nous sommes passés d’architectures client-serveur (J2EE 1.4 avec les EJB2.1, Corba, RPC) à des architectures où la Donnée a reprit de l’importance avec les architectures REST. Personne ne semble vraiment savoir ce que représente l’architecture orientée service, à part les éditeurs de logiciels très friand d’acronyme dans leurs plaquettes publicitaires.
Une architecture WoPA (copyright N.Martignole) avec un Portail d’intégration, est une application capable de combiner le travail de plusieurs équipes, de plusieurs projets, dans un seul endroit : le Portail Web. Cela remet en avant l’importance des données plutôt que de leur logiciel. Je pense surtout au monde de la Banque, où l’IT est important. Vous n’imaginez pas le nombre d’équipes et de projets chez le client où je travaille en ce moment.

L’idée novatrice est aussi que l’interface Web n’est peut-être pas la partie la plus importante de votre application. A l’extrême, il est dommage de proposer un GUI Web et de ne rien proposer à vos clients afin qu’ils viennent chercher les Données directement. Bref ne pas faire de REST devrait être refusé par la DSI dans un schéma d’architecture.

Pour expliquer cela, pensez à Twitter.com. Il s’avère que l’API de Twitter est utilisée 10 fois plus que le site web de Twitter. Pourquoi finalement votre application ne serait-elle pas utilisée non pas avec votre GUI Web que vous avez développé, mais via un Portail capable de venir chercher de la Donnée ? Est-ce que votre valeur ajoutée est de faire une application Web ou d’exposer de la Donnée de manière intelligente ?

Conclusion
C’est donc via une solution standard comme un Portail d’intégration et les Portlets qu’il semble plus logique de s’orienter, dès lors que plusieurs équipes exposent des données et des services aux utilisateurs.
Je crois à une solution où l’intégration du travail de plusieurs équipes est fait dans un Portail dès lors qu’auparavant, chacune d’elles proposaient une interface Web différente.

Merci à Julien Viet de la société eXo Platform pour sa relecture et ses corrections.

Ressources
Liferay est un portail open-source lancé en 2000 qui est compatible avec les standards Javas comme la JSR-168 (Portlet 1), JSR-286 (Portlet 2), JSR-170 (JCR)

GateIn est un portail open-source constitué par la fusion de JBoss Portal et d’eXo Portal. Avec une interface très puissante, le support des standards (JSR-168,286,170), la possibilité d’ajouter des Gadgets facilement, c’est l’un des portails les plus en vogue en ce moment.
http://www.jboss.org/gatein et http://www.exoplatform.com

Oracle Weblogic Portal 10g est la version actuelle du portail d’Oracle. La version 11 devrait sortir à la fin de cette année avec le support de la JSR-286.

Présentation de Dion HINCHCLIFFE sur Web Oriented Architecture

ProgrammableWeb est un annuaire d’API et de Mashup

Démonstration de la fonction Mashup d’Oracle Weblogic Portal

La JSR-301 est la Portlet Bridge Specifications for JSF, en cours de finalisation.

La JSR-286 est la spécification des Portlets 2.0 à laquelle eXo Platform, Liferay et Oracle ont participé

La JSR-170 est la spécification Java Content Repository, implémentée par le moteur d’eXo Portal et de Liferay.

(Liens ci-dessous ajoutés suite à la remarque d’Alexis)

IBM propose IBM Web Portal http://www-01.ibm.com/software/fr/info1/websphere/

SUN Microsystems propose GlassFish Web Space Server basé sur Liferay http://www.sun.com/software/products/webspace/index.xml. Il y a une bonne présentation de 20 minutes très intéressante ici

Vignette propose Vignette Portal 8 http://www.vignette.com

J’ai oublié de citer l’implémentation de référence de la JSR-168 et de la JSR-286 : Apache Pluto

La spécification des Portlets 2.0 est sortie en juin 2008. Thomas nous donne un retour un an après de la conférence. Lui-même contributeur depuis 2004 sur JBoss Portal, une année sur JBoss Seam, il est aujourd’hui le responsable du projet JBoss Portal chez RedHat.

L’agenda de sa présentation sera :
- Quelles sont les nouvelles fonctionnalités de la version Portlet 2.0
- Adoption par les vendeurs
- La portabilité
- Portlets versus Gadgets

Dans un premier temps, retour sur la JSR-286 Portlet 2.0 sortie l’an passé. Tout d’abord l’une des innovations les plus importantes est ce qu’il appelle « Resource Serving ». L’objectif est de permettre l’envoi de données vers le navigateur qui ne font pas partie du portail, comme un fichier PDF ou Excel par exemple, tout en conservant les fonctionnalités d’une portlet. Cette spécification vise donc à offrir un accès au contexte afin d’assurer le support de la sécurité et de l’accès aux données par exemple.

Il montre ensuite l’interaction entre les portlets avec une RemoteCommandPortlet sur une démonstration fonctionnant avec JBoss Portal. Une fenêtre HTML détachée permet d’envoyer des commandes à une autre portlet, la gestion de l’asynchrone est très simple.
A ce propos, il explique que les améliorations du support d’Ajax dans la spécification Portlet 2.0 permettent à des frameworks comme ICEFaces ou RichFaces de fonctionner correctement dans des portlets.

Les Portlets 2.0 peuvent maintenant partager leurs paramètres avec d’autres produits ce qui permet de faire communiquer les portlets entre elles. Thomas Heute montre l’exemple d’une portlet Google Map et d’une portlet Weather qui recoivent toutes les deux en paramètre le code postal d’une ville américaine.

Une portlet peut aussi déclencher une événement, les autres portlets peuvent être notifiées et se mettre à jour. Il conseille de ne s’en servir que pour de la mise à jour de l’interface.

Sur le slide suivant il dresse un état de l’implémentation de la spécification par les différents acteurs du marché :

La JSR-286 Portlet 2.0 est en version finale depuis le 12 juin 2008.
- JBoss Portlet Container 2.0 est sorti le 13 juin 2008 puis inclus dans JBoss Portal 2.7.0 en octobre
- eXo Portlet Container 2.0 est sorti le 18 juin 2008, mis dans eXo Portal le 1er juillet 2008
- Liferay portal a sorti sa version le 17 juillet 2008
- Apache Jetspeed assez tardivement le 27 mai 2009 dernier
- IBM Websphere portal 6.1 a été disponible sept 2008
- Oracle Portal (BEA () + Oracle (2) + Sun(1)) ?

Concernant le support des frameworks WEB il existe 2 spécifications
JSF Support:
– JSR-301 specification addresses JSR-166
– JSR-329 addressing JSR-286 (JBoss Portlet bridge on the way)

De ce qu’il a pu voir sur les forums, les pages :
Wicket support -> mostly there with support for events
Sruts 2 plugin for JSR-286
Spring MVC also support JSR-286
WebWork

A propos de la portabilité : attention la spec ne dit pas comment on fait un portail mais une portlet.
La notion de page n’est pas définie.
La communication entre portlet:
– UI Level
– Le mécanisme événementiel n’est pas un remplacement par JMS, ne pas abuser de ce mécanisme.
– Doit-on se coordonner à travers les pages ?
– Portlets aren’t a template mechanism per se

Rester à une gestion des événements entre portlet qui sont sur la même page si vous ne voulez pas avoir de soucis.

Slide suivant qui m’a fait sourire : Portlet vs Widget vs Gadget (vs Toilet ?)
Thomas Heute explique tout d’abord en quoi consiste un Gadget, tel que l’on peut le voir sur Facebook. C’est un affichage déporté dans un autre site web d’une fonctionnalité hébergée sur un serveur primaire. Une portlet est plutôt la représentation locale d’un service distant, c’est une composition gérée par un portail, afin d’assurer des services communs (authentification, autorisation, communication, etc) dans un seul endroit.

Il cite différentes initiatives autour des Gadgets :
Google OpenSocial, OpenAjax Alliance (OBM, Google, Sun, Red Hat, Oracle, Microsoft) -> Widget proposal

L’avantage des Portlets par rapport à un Gadget/Widget:
-> Fait pour des applications plutôt complexes.
-> Vous pouvez utiliser votre framework en général,
-> L’état des portlets est gardé lorsque la page se rafraichie.
-> propagation de l’identité, de la sécurité, interaction avec un portail, visuel.

Les gadgets ont l’avantage d’être développable rapidement, comme pour consommer par exemple un flux RSS. Facile pour l’intégration du côté client, facile pour partager de l’information. On pense au Gadget Twitter que j’ai sur mon blog par exemple.

Il termine par un slide sur ses idées pour l’avenir
> We could use more annotations a la Servlet 3.0 or JSF 2.0 @Portlet (no portlet,xml)
> We could all benefit from a PORTAL specification
– more aware of the environment, communication with the portal itself
– Portal object management
– Federated search/index

Enfin il revient sur l’annonce du parternariat entre JBoss Portal et eXo Portal. Il résume cela par
« JBoss builds the platform, eXo Platform builds the solution, We are hiring ! »

Réflexions et conclusion
Présentation intéressante, je crois que les Portlets 1.0 ne doivent plus être utilisées. Je travaillerai cet été à l’étude de différents portails pour le client avec lequel je travaille, le sujet est donc d’actualité. Mon souci du moment : comment proposer l’étude d’alternative à la politique d’achat qui voudrait que l’on prenne Oracle Portal, sans savoir si celui-ci correspond à nos besoins ? Mais c’est une autre histoire…