Les Portails d’intégration et plus particulièrement les Portlets sont des briques d’architecture qui offrent des services techniques, mais qui permettent aussi à plusieurs projets de se rejoindre et de travailler ensemble. Plutôt que de parler de SOA, nous verrons que le concept de WOPA (Web Oriented Portal Architecture) est une solution d’architecture pour les applications Webs.
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
0 no like
Bonjour,
J’apporte 2 bémols sur cette présentation :
– il existe très peu de portails techniques actifs, i.e. orienté socles d’application comme tu le mentionnes. Avant, il y avait exo Portal et JBoss Portal, désormais, il n’y aura plus que GateIn. La plupart des autres portails se focalisent plus sur l’utilisateur final, et ça se ressent souvent sur le socle technique (je pense à Liferay et Lutèce que je connais pas trop mal).
– je suis convaincu de l’intérêt des portails pour construire des applis web, c’est d’ailleurs ce sur quoi repose notre Cockpit Kalistick dont tu avais parlé ici-même, mais il faut aussi être conscient des inconvénients :
* l’API des portlets est très rigide et très différente du modèle classique Servlet/JSP. Ce qui demande donc une vraie montée en compétences, et ce qui oblige parfois à sortir du modèle quand on souhaite réaliser certaines fonctionnalités avancées (communication inter-portlets, AJAX, …).
* la gestion des sessions est assez particulière. Notamment parce que le moteur du portail vit dans une webapp indépendante de la (ou des) webapp(s) de ton application
* comme tu l’as précisé, les portails proposent déjà un ensemble de services techniques : authentification, i18n, thèmes, … Or on a souvent besoin de personnaliser certains de ces services. Maintenant t’as pas toujours l’impression que ça a été pensé pour ça, ce n’est pas la philosophie framework (je pense à celui qu’on utilise) ; tu te retrouves alors vite à dupliquer les implémentations existantes, donc en introduisant des dépendances vers les API propriétaire du fournisseur.
* par rapport à l’aspect universel dans JEE, un portail comme JBoss Portal ne fonctionne que sur un serveur JBoss…
Tout ça pour dire que j’abonde sur le fond, mais qu’il faut avoir conscience que le portail a un effet sables mouvants : une fois qu’on y a mis le pied, dur d’en sortir…
Sylvain FRANCOIS
Directeur R&D
Kalistick
IBM et SUN n’ont pas participé à portlet 2.0 et n’ont pas de portail ? 🙂
Amazon.com construit à base de portlet, au sens de la norme du monde java? J’ai mes doutes… Une source pour confirmer/infirmer.
Il faut quand même noter que les portlets se font de plus en plus bouffer par les « widgets » ou gadgets à la google bien plus simple à construire et à intégrer.
@alexismp en effet, ce n’est pas faute de ne pas vouloir en parler, c’est simplement parce que l’étude sur laquelle je bosse ne portera que sur ces 3 produits (ce n’est pas moi qui décide dans l’histoire)
J’aurai cependant dû aussi citer les autres moteurs de Portail les plus utilisés qui sont :
– IBM propose IBM Websphere Portal,
– SUN Microsystems propose Glassfish Web Space Server qui est basé sur Liferay
– VIgnette Portal 8
Et aussi la référence de la JSR 168 et 286 à savoir Apache Pluto (http://portals.apache.org/pluto/)
Concernant l’offre de Sun, elle est basée sur celle de Liferay et aujourd’hui personne ne sait ce qu’elle va devenir dans le futur. Donc ton oubli n’en était pas vraiment un. De plus, Sun n’offre quasiment aucun support sur ce portail.
Par contre, vu l’effort actuel pour unifier les produits Oracle et BEA, Webcenter semble être un portail a suivre de pret.
IBM est un portail eeennnoooorrrrmmmmeee. ET il faut adopter toute la stack IBM. A recommender aux schtroumps …
Quand on n’a pas d’argent et qu’on veut faire du Java, il reste Liferay et exo. Exo est très peu utilisé et peu connu en dehors de la France et éventuellement de l’europe. En s’adossant à RedHat, ils ont gagné en notoriété, mais on perdu en indépendance. Ca c’est le probleme de la France, incapable de soutenir des projets super.
Le choix d’un portail n’est donc que le début, un socle. Ensuite, il faut choisir son socle pour la gestion des identités, construire des outils autour du portail pour automatiser les taches (essayez de construire des hiérarchies de sites qui héritent des propriétés des uns et des autres).
Ensuite, voulez-vous un portail pour un usage intranet ou pour du e-commerce? La encore, ca
La encore ca fait une sacré différence.
Enfin, est-il possible de déployer pour pas cher sur le cloud? Pour Liferay, oui .. Pour les autres ….
Le probleme du portail, c’est qu’on passe beaucoup de temps à faire de l’intégration au lieu de se concentrer sur l’application. Peu de business sont capables de penser mashup et information. Donc, il faut éviter de laisser l’IT se faire plaisir et construire un portail pour le plaisir. Dans le domaine du voyage en ligne, tres peu utilise un portail, ou alors utilisent liferay car il offre un bon compromis fonctionnalité/ouverture.
L’architecture qu’Amazon a mis en place ces dernières années pour l’ ‘aggregation’ des services ainsi que le rendering des pages n’a rien de comparable avec des solutions plus monolithiques comme liferay ou exo/jboss portal.
Pas d’amalgame svp… 🙂
L’architecture Front-end mise en place par Amazon met en avant une approche qui n’est pas directement transposable/naturelle dans le monde liferay ou exo/jboss portal. P.ex:
* couche front-end spécialisée dans le rendering et le caching des pages, ‘tout le reste’ est délégué à d’autres couches du système distribué.
* ‘scalabilité’ horizontale sur des serveurs à faible coût
* focus sur le page delivery en moins de 2 secondes
* TCO (total cost of ownership) maîtrisable pour le client
* …
La question à creuser…: « (bien que très séduisante à première vue pour l’IT manager…), que résoud réellement une solution de type portail à-la-jsr168/286 ? »
Quelques liens dèjà anciens mais toujours bon à relire (in English):
* Amazon’s Dynamo – http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
* http://highscalability.com/amazon-architecture
Bonjour,
Je trouve dommage que votre article soit à ce point orienté théorie et normes.
Dans la pratique, la norme JSR-168 n’est pas capable de satisfaire les besoins du client. La norme JSR-286 est un « fixe » de la précédente. Et a grand renfort de marketing est souvent couplé à JSR-170.
Les normes et standard (lego) rassurent et sont fantastiques si la théorie est raccord avec la pratique. Mais ce n’est pas toujours le cas.
En réalité ce sont des webdesigners qui designent des pages web et qui ont besoin d’avoir la main sur l’applicatif. Les portlets métier JSR-286 sont en général très dépendantes de leur environnement (Java, Portail, SSO, WebService, AppServer, DataBase…). Lorsqu’il faut faire des choses un tout petit peu évolué cela devient très vite compliqué et il faut accéder aux couches sous-jacentes.
Dans le Portail, crée en 2003, du produit Jalios JCMS c’est le choix qui a été fait: permettre aux développeurs ou webdesigner de faire des « Portlet » (JSP) très simplement et isolé sans se soucier de l’infrastructure. Bon j’arrête là, je ne suis pas ici pour faire de la pub.
Enfin bref, attention a ne pas mélanger théorie marketing et réalité fonctionnelle.
Je reconnais le besoin de développer des portails.
Par contre, je suis assez dubitatif sur l’intérêt des portlets.
Y a toujours eu un truc qui m’a chiffonné dans les portlets et les développements à base de portlets, bien que j’avoue sans ambage que je ne connais pas ses dernières évolutions.
Initialement, on avait des difficultés à utiliser notre framework web préféré car ce dernier n’avait pas forcément de pont avec la spec portlet.
Puis les (premières) portlets plutôt « rigides » ont été bousculées par l’arrivée de AJAX (exit les portlets de papa-maman similaire aux EJB 1.0), et les portails ont du prendre le train en marche.
Maintenant, quand j’ai lu la partie suivante du présent post :
« »
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.
[…]
Lorsqu’une équipe [de Amazon] 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.
« »
A la lecture de ces phrases, j’ai pensé à OSGi qui offre une techno de modules particulièrement éprouvée.
Franchement, je ne vois pas les conteneurs de portlets concurrencer les conteneurs OSGi et devenir plus populaires que ces derniers !
Sans doute va-t-on voir créer un pont, encore un (!), qui va permettre de définir un conteneur de portlets au-dessus d’un conteneur OSGi…
De fait, la prochaine vague qui va bousculer le monde des portlets, c’est OSGi.
J’avoue aussi ne pas comprendre la fin du post :
« »
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 ?
« »
Pour moi, portlet = rendu web et API = archi orientée service.
Bref, en lisant ces paragraphes, l’accès est mis sur une offre d’API, pour moi, synonyme d’une archi orientée service, alors qu’une telle archi m’a semblé mise un peu à l’écart par le début du post pour mettre en avant une archi à base de portlet…
Je pense qu’un des sous-entendus de ce post (il y a tjrs pleins de sous-entendus avec les portlets… chacun voit midi à sa porte) est que portlet est synonyme de module.
Perso, je pense qu’en termes d’archi modulaire, avec l’essor de OSGi coté serveur, OSGi a plus la cote pour définir une appli à modules que les portlets !
De fait, les portlets sont bousculées de toute part:
– coté authentification, celle apportée par les portlets est bousculé par l’authentification en partie généralement réalisée coté serveur frontaux (Apache par ex), et/ou par des filtres de servlets,
– coté composants graphiques, les portlets subissent aussi la concurrence des gadgets,
– coté approche modules, les portlets vont subir de plein fouet la concurrence roulot compresseur de OSGi…
– etc.
De fait, il y a un pb de positionnement des portlets.
Quand on vante le fait qu’une portlet peut être minimisée, normal, maximisée, et qu’il soit possible de basculer d’un mode vue à un mode édition pour la configuration, c’est très bien, mais…
mais cela concerne principalement la page d’accueil d’une portail !
Et coté développeur, utiliser ensuite la techno portlet pour tout développer une appli web, c’est un peu comme choisir de construire sa maison en bois parce que la porte d’entrée est en bois !
Cela ne veut pas dire que les portails soient inutiles, il y a pleins de types d’applis (comme le reporting ou le management) où cela peut être utile.
Simplement, je suis dubitatif sur le fait de foncer tête baissée sur l’utilisation de portlets (qui semblent en chantier constant).
Merci à tous pour vos commentaires qui vont enrichir la réflexion autour des portails.
Concernant Amazon mon article laisse penser qu’ils utilisent les Portlets, ce qui est faux. Et j’aurai dû par contre développer qu’en effet, Amazon utilise une couche de découpage fine qui peut s’apparenter à des Portlets.
J’aime bien finalement le retour de Sylvain François qui a visé exactement là où nos besoins se situent en ce moment. J’ai rêvé et je continue de croire, que plutôt que de regarder du côté d’OSGi, une application web construite par plusieurs équipes devrait être hébergé dans un Portail, construite avec des Portlets
Merci pour vos retours, on sent que le sujet aurait besoin d’être discuté, à un Java BarCamp par exemple.
@Dominique De Vito
tout a fait d’accord avec ta conclusion. Pour moi ce qu’on appel Portlet n’est qu’un Fragment JSP + un Objet Contextuel (que des gens se sont amusé à normaliser). Ce fragment attaque idéalement un Service REST ou l’API sous-jacente.
Par contre je ne suis pas d’accord avec ta vison du « Portail »: boite avec ouvert/fermé. La plupart de nos clients grand compte utilisent un/plusieurs « Portail » (donc structuré en « boites ») mais qui ont un look de site « normal » et généralement créés par un graphiste. D’ailleurs une Portlet est souvent une DIV avec de l’information dedans.
@Nicolas Martignole
>
> une application web construite par plusieurs équipes devrait être hébergé dans un Portail
>
Attention, il y a les portails « infrastructure » et les portails « intranet/extranet ».
– Dans le premier cas, dans les années 2000, les produit proposaient une horrible page découpé en Frame (je ne citerais pas de nom ;)) puis ce cloisonnement s’est transformé en Gadgets, Portail à la NetVibes, … L’idée est vraiment de séparer les applications très riches. Et de fédérer le tout avec un SSO.
– Dans le deuxième cas, l’intégration est plus fine, le portail attaque un Web Service REST, SOAP (aie) ou tout simplement un flux RSS. C’est pour ce second besoin que JSR-168 puis JSR-286 est nés mais malheureusement en Javaisant trop les besoins. (Les intégrateur/webdesigner code des JSP pas des Servlet)
Enfin Il y a des problématiques techniques ultra simple qui permettent de faire la différence entre les 2 approches: JavaScript et CSS. Pour avoir un Portail homogène celui-ci doit fédérer la charte graphique donc appeler des services qu’il va habiller. Sinon a l’inverse il doit être ultra-générique et non intrusif pour agréger des « Gadget » qui viendront avec leur look/css.
Bonjour et merci pour cet article,
J’ai déjà eu l’occasion de participer à quelques projets portail : essentiellement du Websphere Portal et de l’ExoPlatform. A chaque fois suivi de ce sentiment amer : « tout cet effort pour ça ? ». Je n’ai jamais autant eu envie de refaire du PHP que lors de projets portails web.
Je trouve que Java / JEE est une technologie déjà lourde et cette lourdeur atteint son paroxysme au travers des portails : socle lourd, standards à n’en plus finir, packaging et déploiement complexe, productivité encore diminuée (d’un point de vue tps de démarrage serveur, débuggabilité …).
Au final j’ai maintenant plus envie de croire en de simples applications Tomcat, une couche de Mashup par dessus tout ça pour faire l’aggrégation et un peu de SSO pour coller le tout. Si besoin de collaboratif il y a, alors il existe de nombreux outils spécialisés pour y pallier.
Bonjour tout le monde,
J’ai participé à un portail – ce qui m’en a donné une plutôt mauvaise opinion mais pas sûr que cette opinion soit assurée . On diraitque pour faire un portail, il faut Bien le faire – et notamment avoir un travail préalable d’architecture et de POF. Pour pouvoir partager des données métiers, communiquer entre les portlets , préparer des solutions à tous les soucis qui pourraient advenir. Et surotut , des bonnes pratiques! A développements hétérogènes, résultat incohérent.
Puis par la suite sont apparus les widgets à la netvibes (ou à la extjs si vous préférez). Il me semble que la solution de widgets web 2.0 résout un problème que les portlets avaient essayé de poser et de résoudre de manière un peu lourde – et que les appels ajax règlent le problème de l’état général de la session pour une application. Plus besoin de « tout un bouzin » pour redessiner quelques bouts de pages, il suffit par ajax de redessiner uniquement un bout de page…
Mais encore une fois, je pense qu’un portail bien fait peut être vraiment une solution puissante – notamment pour déployer à chaud des portlets et pour gérer l’authentification. Mais, quel est le cas d’utilisation? Et surtout, beaucoup de risques de se tromper amha.
Je ne comprends pas très bien dans ton article le pont que tu jettes entre une API de services et un portail. Pour moi c’est même un peu des solutions opposées, non? Ou alors est -ce que tu serais pas en train de proposer que le portail ne déploie également des services rest/rest-xml/soap ?
Ah si tout de meme j’ai une question, à l’époque on avait un souci d’intendance tout simple, c’est que le serveur mettait un temps fou à se lancer se déployer, il fallait de temps en temps le relancer… Et tout cela sur des bêtes de course (pour l’époque, il y a 3-4 ans). Est-ce que cet aspect est toujours vrai ou peut-on maintenant déployer aisément son war. (j’imagine que cela dépend du portail. mon expérience était sur ibm portal, ceci explique certainement beaucoup le souci…)
Sinon, un avis intéressant, celui d’un afficionado du Rest, Stefan Tilkov, qui dit « non » mais (lui aussi) de manière peu assurée :
http://www.innoq.com/blog/st/2009/09/q_should_you_use_a_portal_serv.html