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

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.

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.

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.

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).

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.

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