Si vous avez suivi les sujets du moment sur le Touilleur Express, vous savez qu’en ce moment je travaille sur les Portails Java Open-Source (Liferay, eXo Portal et Jahia). Après quelques articles sur les Portlets et les Portails, j’ai eu la chance de participer la semaine dernière à la formation eXo Portal organisée par Julien Viet. Il est temps de vous parler un peu de GateIn. Dans cet article j’ai essayé d’avoir une vision plus globale de ce que les Portails peuvent nous apporter. Nous reviendrons dans d’autres articles sur GateIn pour toi développeur. Là j’ai envie de parler à toi, le Client final ou le Visionnaire, histoire de vous parler un peu de ce qui nous attend.
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 ?
0 no like
Et en même temps, cette problématique d’utilisation des portails comme mashups se pose depuis au moins 5 ans et on voit bien que ça marchotte plus ou moins bien selon les cas : capacité d’ouverture technique des outils de portails ou des outils métiers, problème de compatibilités selon les version, changement d’ergonomie entres les outils, redondances de données à saisir ou à lire, … C’est plutôt ingrat ce boulot d’intégration ou tu est vachement dépendant de ce que tu assembles.
J’ai l’impression qu’il est plus gratifiant pour ces outils de portails de communiquer et de mettre l’effort de développement sur leurs fonctionnalités applicatives natives, même si c’est souvent plus des preuves de concept qu’autre chose (cf. au hasard le CMS de JBoss Portal), plutôt que sur les capacités d’intégration avec des outils spécialisés. Ca doit être une problématique dure à gérer dans les choix de développement.
NB : tu écris Liferay ‘LifeRay’ comme certains appelaient sournoisement Mitterand « Mit’rand » ou c’est juste une mauvaise habitude 😉 ?
@Sylvain j’ai corrigé LifeRay en Liferay, merci 🙂
A mon avis, c’est bien plus la lourdeur que le tarif des portails IBM et BEA (donc Oracle) qui ont conduit à se tourner vers des alternatives libres plus légères, voire à remettre en cause le besoin d’un portail.
L’avènement des solutions d’intégration côté client à base d’Ajax, à la Netvibes ou iGoogle, a remis en cause au moins partiellement leur modèle d’intégration complète côté serveur, qui avec la personnalisation est forcément un gouffre à ressources…
@Nicolas : oui, d’ailleurs j’ai bossé sur un projet où le client était bloqué avec un WebSphere Portal (lourdeur, manque de fonctionnalités, …) et DANS lequel on avait finalement intégré un Liferay pour gérer un workflow de publication (via une iFrame) !
Bonjour,
Excusez d’avance mon inexpérience il se peut que la question que je vais poser soit déjà traitée dans l’article, mais le dialecte techno/portail m’apparait encore flou.
Je voulais savoir s’il était incohérent de mettre en place un portail dans le cadre d’une application spécifique (donc un et un seul outil – aussi multifonction soit-il).
Je trouve ce rapport du Gartner un peu creux. Ce me fait penser au temps où le Gartner misait tout sur les EAI. J »étais alors chef de projet technique EAI chez Arcelor. Waouuu… Et quelques années plus tard : rien. Le feu de paille a brulé. Et bien, là, j’ai l’impression que c’est la même chose. Je n’y vois pas apparaitre les ruptures d’infrastructure qui s’opèrent en entreprises. iGoogle est tout simplement écarté. Pourtant, sans être pro-Google, leur gadgets, leur Apps Engine, leur sites, leur suite bureautique, tout ça c’est de l’hébergé! A côté de cela, il y a du vmware qui pousse partout. Et bien je vais vous le dire : à mon sens, les entreprises vont se séparer petit à petit de leurs infrastructures informatiques. Pourquoi? simplement parce ce que ce n’est pas leur métier et qu’on est à la veille de leur offrir une qualité satisfaisante en SAS. Donc : oui je crois aux portails horizontaux. Non, je crois de moins en moins aux solutions hébergés en internes. Dommage d’avoir écarté iGoogle.
Argh, le terme « portail » est tjrs synonyme de confusion… confusion, notamment, entre approche intégrée (interface), et suite collaborative (implémentation(s)); et on peut même raffiner l’approche intégrée en sous-catégories : approche portlet ou pas.
Que les entreprises utiliseront d’ici 201X tout ou partie d’une suite collaborative (au sens le plus large) => oui, vraisemblablement.
Que les entreprises utiliseront un portail, au sens de conteneur de portlets (genre, Java portlets) => c’est moins sûr.
Merci pour ce post.
De mon coté, j’ai toujours été septique sur l’utilisation des portails de portlet (portal), par rapport à leur lourdeur d’utilisation au regard de leur réelle valeur ajoutée. En plus tout le coté marketing des portails avec plus de 80 portlets par défaut!!! génial!!! mais bon, les vraiment utiles sont toujours les memes: cms, wiki, blog, espaces de collaboration à la « eroom », mail et encore…
Cette fois-ci le terme « intégration d’applications » m’a vraiment fait reflechir. Cela m’a rappelé une autre citation de 2002 d’une personne qui m’avait dit « le serveur d’application va devenir l’OS du web ». Ca m’avait frappé, mais c’etait pourtant assez vrai.
Cette fois-ci, si l’on considère un portail comme une surcouche du serveur d’application pour « intégrer des applications » cela me semble interessant de voir la valeur ajoutée par rapport au serveur d’application.
Je proposerais donc de faire la grille de comparaison suivante:
Comparer les 3 scénarios suivants pour l’intégration de « modules applicatifs »:
1. Intégrer tous les modules dans la meme application web sans portal
2. Intégrer les modules sous forme de portlet dans un portal
3. Intégrer les modules sous forme d’applications web bien séparées mais avec par exemple un système de SSO en frontal si besoin
Les axes de comparaison pourraient comprendre:
– la flexibilité de maintenance: je dois tout tester et arreter pour faire une mise à jour pour le scénario 1
– la scalabilité: je suis forcé d’avoir toutes mes applis sur chaque noeud de serveur pour les scénarios 1 et 2
– la cohérence de l’IHM
– le partage de données inter modules
– …
En prenant en compte vraiment les vrais fonctionnalités dont on a besoin dans une application d’entreprise. Ainsi la possibilité d’ajouter en live la météo en haut à droite de ma page d’accueil ne doit pas rentrer dans ce comparatif 🙂
(Peut-etre cela pourrait-il faire partie d’un nouveau billet pour relancer la participation Nicolas ?)
En esperant que cela permette par une comparaison de faits plus que d’opinions de fournir un réel avis sur l’utilisation des portals.
Merci d’avance!
Gilles S
Bojan -> tu peux utiliser un portail pour une seule appli,
ça te permet par exemple de ne pas avoir à implémenter
toi même ta gestion utilisateur, t’utilises directement celle
du portail.
@phil le portail gère l’authentification et éventuellement les profils, mais certainement pas les droits applicatifs qui sont par nature spécifiques à chaque application et potentiellement chaque utilisateur ! Les applications métier où seul le profil permet de définir les droits sont peu courantes…
Comme le dit Sylvain, les portails sont déjà morts.
BEA et IBM (à l’époque de l’alilance iPlanet avec Sun) avaient proposé des solutions très lourdes qui n’ont jamais décollé, même si dans les appels d’offre (en particulier les marchés publics) il était demandé (dans les années 2003-2005) d’être compatibles avec des portails d’infrastructure. Aujourd’hui les AMOA et les clients ont compris que les portails d’infrastructures n’étaient pas le bon niveau d’interopérabilité (à cause de la problématiques des navigateurs) et il n’y a plus que JBoss (et encore) et liferay à parler encore de portail d’infrastructure. Les normes JSR-186, JSR-268 sont mortes, WSRP, pas tout-à-fait, mais pas loin. CMIS par contre, permet une interopérabilité à un niveau applicatif beaucoup plus crédible, à mon sens.
IMHO, GWT est en passe de donner un coup de grâce aux portlets, ou pas loin à terme.
Voir mon post « Portlet life looks like EJB, but future sounds like GWT » : http://www.jroller.com/dmdevito/entry/portlet_life_looks_like_ejb
Les portails sans intégration verticale, sans offre métier, vont rapidement se sentir mal, ou ils le sont déjà sans qu’ils le savent encore (déjà morts ?).
Les portails avec intégration verticale se portent mieux, mais comme je ne donne pas cher des portlets à long-terme, leur couche IHM va être impactée aussi par GWT.
On va voir comment le marché des portails va réagir à GWT… Wait and see.
Dominque,
Jette un oeil sur l’étude Gartner, qui parle des portails horizontaux type Liferay et des perspectives. C’est pas si délirant.
Je ne vois pas ce que GWT vient faire ici… C’est une technologie de rendu web. Un portail d’intégration fournit des services comme l’authentification, l’hébergement de portlets, l’échange de messages, la mise en page…
Les gens d’eXo font aussi conteneur de Gadget OpenSocial. Ils peuvent afficher sans problèmes des Gadgets de Google… écrit en GWT.
Non je n’ai pas compris pourquoi tu parles de GWT ici, pour moi cela n’a rien à voir.
Mais sinon ton article est intéressant, je suis allé le lire
🙂
Nicolas
Nicolas,
« »Jette un oeil sur l’étude Gartner, qui parle des portails horizontaux type Liferay et des perspectives. C’est pas si délirant. » »
=> comme je l’ai indiqué plus haut, je me demande s’il n’y a pas confusion dans l’esprit de Gartner entre portail et suite d’applis collaborative. Quoiqu’il en soit, je doute de cette étude Gartner: autour de moi, je ne vois AUCUN projet utilisant un portail ! Et cela fait longtemps que je n’ai pas vu de nouveaux projets utilisant un portail… En fait, les personnes autour de moi ne proposent JAMAIS de portails, sauf s’il y a une forte demande du client.
« »Je ne vois pas ce que GWT vient faire ici… C’est une technologie de rendu web. Un portail d’intégration fournit des services comme l’authentification, l’hébergement de portlets, l’échange de messages, la mise en page… » »
=>
Peut être que j’aurais du plus rentrer dans les détails…
(1) authentification : peut être défini avec un filtre de servlet, donc, c’est pas spécifique aux portlets, et donc, cela peut être réalisé avec GWT
(2) hébergement de portlets ~ en gros, c’est du packaging, sauf que, comme je l’ai indiqué dans mon post, il manque sans doute encore à GWT une certaine modularité pour faire du hot deploy de nouvelles portlets (hot deploy coté serveur), mais bon, cela n’est pas pour moi un point critique-critique.
(3) échange de message : AFAIK, on peut coder avec GWT des échanges de message coté client, entre composant coté client, et coté serveur, IMHO, c’est de l’échange de messages classiques genre SOA.
(4) la mise en page, c’est aussi le domaine de GWT (cf. par ex, le composant de Ext JS).
Donc, en résumé :
– GWT permet d’offrir les fonctionnalités (1), (2) et (4) des portlets, ou dit autrement, GWT offre une bonne partie de ces fonctionnalités.
– GWT ne permet pas (encore ?) d’offrir la fonctionnalité (3) que je juge pas super critique.
Bref, pour moi, GWT est sur le terrain des portlets, et gagne du terrain !
« »Les gens d’eXo font aussi conteneur de Gadget OpenSocial. Ils peuvent afficher sans problèmes des Gadgets de Google… écrit en GWT. » »
=> en gros, comme GWT produit du HTML+JS, cela signifie que dans une page eXo, on peut inclure du HTML+JS – bon, ok.
Vu le peu d’info ici sur ce point, je dirais qu’ils utilisent GWT pour définir un composant unitaire, ce qui est (tjrs) possible, car on peut inclure un fragment HTML+JS dans une page web.
Mais je ne crois pas qu’ils utilisent GWT pour (re)définir une archi portlet-like à la sauce GWT, en utilisant toute la puissance de GWT.
Donc, cela reste des portlets avec un peu de GWT si nécessaire. Et si, comme je le crois, GWT, tout seul, apporte une solution proche des portlets, a une plus grosse commauté que les portlets, ouvre plus de portes que les portlets, etc. alors on retrouve sur un même bateau 2 technos qui cohabitent et qui pourraient faire le job chacune toute seule de son coté. Il risque d’y avoir un mort, quelqu’un va finir par tomber à l’eau, et je ne crois pas que le mort, le noyé, ce soit GWT !
« »Non je n’ai pas compris pourquoi tu parles de GWT ici, pour moi cela n’a rien à voir. » »
=> J’espère avoir été plus clair.
Tu me fait penser qu’il faudrait que j’écrive sans doute un nouveau post dans mon blog pour être plus clair 😉
@Dominique merci pour tes éclaircissements, maintenant c’est plus clair.
Je pense que tu mélanges les deux concepts, et je ne suis pas d’accord lorsque tu dis que l’un peut remplacer l’autre… car ils n’ont rien à voir. GWT est une technologie de rendu Web. Ce n’est pas une spécification normalisée avec différents éditeurs. C’est un moyen pour que les développeurs Java arrivent à utiliser le paradigme de la programmation à la Swing et génère des interfaces riches en HTML+CSS+JS.
Le principe d’un Portail d’intégration tel que Gartner le décrit, est de proposer un moteur d’exécution de Portlets. Tu peux tout à fait écrire des Portlets avec GWT, avec Wicket, avec Tapestry, avec JSP simple, avec ce que tu veux… Le portail se propose de regrouper des services d’infrastructure comme l’authentification. GWT ne supporte pas tout ce qui est SSO comme un Liferay qui fait du CAS, du SiteMinder par exemple… tout simplement car cela n’a rien à voir.
Cela me rappelle le client chez qui j’ai travaillé, qui a développé son portail en GWT. Oui super, en effet nous avons des boites qui se mettent cote à cote, ce qui laisse croire que GWT peut faire ce que fait un conteneur de Portlet…. mais c’est faux. L’échange des événements est fait en Javascript du côté du client pour GWT là où merci les Portlets, les échanges de message entre portlets sont fait du côté serveur.
Et que l’on ne me fasse pas dire que je n’aime pas GWT, je remets à sa place GWT là où il doit être, et je suis vraiment pas d’accord avec ton idée de GWT vs Portail d’intégration, car cela n’a rien à voir.
On peut faire aussi Wicket peut-il remplacer les serveurs Webs et ensuite JSF va-t-il remplacer Hibernate la semaine prochaine….
Bon, je commence par qques points particuliers.
Quel est l’avantage pour les portlets d’être normalisées ?
Oui, CORBA aussi est normalisé, et alors ?
Quelques fois la normalisation, c’est un pansement sur une jambe de bois…
Quant à l’échange entre composants GWT à coup d’évènements uniquement coté client, j’en doute.
Soit une portlet/composant GWT p1 associée au service (coté serveur) s1
idem pour p2/s2.
AFAIK, avec GWT, rien n’empêche p1 d’appeler le service s2 (=> échange de msg entre portlets réalisé du côté serveur).
Autre ex : rien n’empêche p1 d’appeler un service de notification coté serveur pour transmettre un msg aux observateurs (comme s2).
Mais revenons à la discussion générale.
Dire « JSF va-t-il remplacer Hibernate la semaine prochaine… » pour indiquer que GWT ne peut pas remplacer les portlets, c’est un peu fort de café…
JSF et Hibernate opèrent dans des couches différentes,
tandis que les portlets et GWT opèrent dans les mêmes couches…
portail != conteneur de portlets
Mais les portlets ont gravé dans le marbre des API la notion de portail.
Ceci étant, les portails, IMHO, ce ne sont pas que des API, c’est aussi un design, une archi.
Les portlets incitent à penser que la bataille des portails se jouent sur le champ des API, moi, je pense que l’on n’est pas forcément obligé de passer par ces fourches caudines-là et que l’on peut définir un portail autrement, en respectant le design, l’archi d’un portail.
Bref, pour moi, le champ de bataille ‘portail’ avec GWT et les portlets, c’est un peu: « l’esprit (design/archi) et la lettre (= ce qu’est un portail gravé dans le marbre des API) ».
Autrement dit, oui, GWT ne fournit pas un portail (clé en main avec les « bonnes » API),
Ceci étant, GWT est capable d’en respecter le design/l’archi .
Donc, les portlets et GWT ont bien à voir l’un avec l’autre.
Bien sûr, GWT reste un framework web, mais s’il y a un framework web capable de secouer le cocotier des portails (vu uniquement comme conteneurs de portlets), c’est bien IMHO GWT.
Pour différentes raisons, par ex, par la taille de la communauté GWT, par son évolution rapide, et aussi coté technique, par le fait que les composants GWT sont à cheval entre la partie cliente et la partie serveur, exactement comme les portlets !
Je pense qu’il ne faut pas comparer GWT et le Portail.
GWT aujourd’hui est une API web qui sert pour faire des applications riches, avec un maximum de traitement du coté client (Web as a a platform). Et qui di GWT dit programmation.
Le premier objectif du portail était d’éviter de programmer le plus possible. Ensuite, entre un portail e-commerce (type magento), un intranet, un portail de collaboration et un portail d’infrastructure, rien n’est comparable.
Le portail d’infrastructure, type liferay ou GateIn, contrôle de manière plus forte les interactions entre le client et les applications du coté serveurs. C’est un outil d’intégration au niveau de l’interface graphique. On peut y intégrer les portlets, les widgets, les gadgets, etc.
Le portail d’infrastructure est aussi utilisé pour son modèle de gestion des rôles et de la sécurité. De même, si tu utilises Alfresco, alors tu perds l’intérêt du portail, car la sécurité n’est plus unifiée avec le portail. D’où l’intérêt de prendre le CMS du portail.
Enfin, le portail n’est pas vu par les financiers qui gouvernent le monde comme une application. Donc de plus en plus, les entreprises vont chercher a outsourcer leurs portails (quitte meme a utiliser Netvibes). Pour convaincre le management de réécrire une application qui ressemble à un portail en GWT, je vous souhaite bon courage.
Néanmoins, l’essor des framework type GWT, risquent à terme de remettre en cause le modèle du portail. Il faut juste que quelqu’un s’amuse à intégrer le meilleur des deux mondes!
Le mashup, le push de données (via comet), la gestion multi-canal et la communication inter « fenetres » sont des besoins cruciaux.
@William
J’aime bien la fin de ta prose : « Néanmoins, l’essor des framework type GWT, risquent à terme de remettre en cause le modèle du portail. » 😉
Par ailleurs, un sympathique commentateur de mon blog m’a indiqué qu’il avait créé (depuis un certain temps déjà) des portlets-like mais à la sauce GWT :
« We had a the same idea a little while ago and it resulted in ‘GWT Portlets’:
http://code.google.com/p/gwtportlets/
GWT Portlets is a free open source web framework for building GWT (Google Web Toolkit) applications. It defines a very simple & productive, yet powerful programming model to build good looking, modular GWT applications. The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The « portal » is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider. »
Comme quoi, je ne suis pas seul à penser que GWT ressemble fort au futur des portlets…
Je travaille actuellement sur les evalations de portails et de CMS.
Les portails ne sont pas morts. Loin de là. Vous oubliez la nécessité pour les sites privés, voire l’obligation pour les sites publiques d’être accessibles. Les gadgets/widgets sont donc mis a mal car ils nécessitent la présence du javascript. Or, un site accessible a pour principale contrainte de devoir fonctionner sans javascript.
Enfin, la nécessité pour les sites commerciaux d’avoir une réactivité accrue impose l’utilisation d’un CMS (maison ou commercial) en plus de la solution eCommerce utilisée. Le portail sert donc souvent d’intégrateur graphique. Liferay, s’il avait un meilleur CMS serait une solution vraiment intéressante. Malheureusement pour les intégriste du java, aujourd’hui, les meilleurs CMS font partie du monde PHP.
Si je peux me permettre de porter mon grain de sel en tant qu’utilisateur de solution portail d’editeurs…
Ok les portails d’appli apportent une certaines « lourdeur », mais un peu comme tout ce qui donne un cadre : il faut s’y conformer…
Ils ont cependant le grand avantage de standardiser des aspects qui, dans les entreprises, sont souvent traitées de facon complètement hétérogène de projet en projet : authentification, profils, navigation, look n feel…
Pour moi, je vois un peu le portail comme un framework de standardisation de ces services.
Après, biensur, on peut toujours tout faire en GWT, en Wicket en ce qu’on veut…dans le monde JEE, tout est toujours possible de 1000 facons, toutes plus intelligentes et killer les unes que les autres. Mais si on se place au niveau de l’entreprise, il me semble interessant d’adoptier une démarche qui donne un cadre a des services techniques qui sont souvent consommateurs de temps et donc de budget alors qu’ils ne devraient plus l’etre…
@J-Philippe
Perso, pour faire un site accessible, les portails NE me semblent PAS apporter un plus.
Par ex, cf. le point 14 du WCAG1.0 : « S’assurer que les pages sont claires et simples »
Les pages web d’un portail avec pleins de boites à l’intérieur, cela me semble aller à l’encontre de ce point du WCAG1.0. Et cela me semble occasionner aussi de possibles difficultés de lecture.
Note : par ailleurs, WCAG2.0 ne bannit plus JS du poste client.
@MikaFromParis
Je ne vois pas franchement un portail comme un framework de standardisation des services comme authentification, profils, navigation, look n feel…
Ces services sont généralement standardisés en dehors d’un portail (à travers, par ex, un serveur d’identité pour l’authentification et les profils) et un portail se contente d’intégrer /d’utiliser ces services.
Un portail, c’est surtout une affaire d’intégration. Et de ce point de vue, je ne vois pas tellement ce qu’un portail apporte de plus qu’une approche qui serait basée sur GWT (cf. mes arguments plus haut, dans précédents posts).
Un nouvel éditeur de solutions de portail d’entreprise Open Source commence à faire parler de lui. Connaissez-vous Portaneo ? Portaneo se positionne comme un fédérateur d’Intranets. et a conçu un portail professionnel innovant qui unifie l’accès à l’information et aux applications par le biais d’une interface personnalisable et collaborative, complété d’un réseau social interne.
Voir le site http://www.portaneo.com