Si les portlets étaient des applis web, alors les portlets devraient disposer de fonctionnalités proches de celles des modules OSGi, un id, des définitions de dépendances entre modules, une partie publique (API publique) et une partie privée (implémentation). Or, en gros, cela n’est pas le cas.

Je crois que le match entre les portlets et OSGi va finir par se transformer en un remake du match entre les superordinateurs spécialisés faisant état d’une techno ad hoc (~ portlets) et les clusters de PC (~ OSGi). De fait, il y a déjà plusieurs serveurs Java qui permettent de déployer des modules OSGi tout en pouvant faire appel aux API Java EE, comme le serveur Spring et le serveur JOnAS. Il est donc loisible d’imaginer implémenter les portlets comme des modules OSGi.

Certains découpent leur back-office en serveurs pour faire tourner la partie présentation (JSP) et la partie métier (avec une facade EJB ou WS). Toujours dans la même optique, je ne vois pas les portails dans la brique métier, mais dans la brique présentation et par conséquent, je ne vois pas les portlets comme des applications légères.

De fait, par ex, pour un besoin CMS/ECM, je suis plus d’accord avec l’approche Nuxeo qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir ~ approche métier=>présentation.

1) bref, encore une fois, IMHO, les portlets, il s’agit pour moi plus d’intégration graphique que d’intégration métier ; de fait, même la sécurité peut être réglée en dehors des portlets !

1-bis) Et cela m’amène à m’interroger sur l’intérêt d’un portail (coté serveur, donc). Comme j’ai pu l’écrire ici ou là, choisir un portail ressemble un peu à choisir de construire sa maison en bois uniquement parce que… la porte d’entrée est en bois. De fait, seule la page d’accueil d’un portail contient des portlets customisables, pourquoi vouloir utiliser la technologie portlet pour toute une appli web sachant que seule la page d’accueil doit être customisable ? C’est pour le moins étonnant, non ?

2) les portlets ont connu différentes vies et des débuts difficiles.

Je me rappelle des tout débuts, un vendeur m’a indiqué qu’avec les portlets,
- on ne pouvait pas faire de clustering de session http (trop compliqué/lourd),
- on ne pouvait pas utiliser de JSP avec son produit (on devait coder l’IHM en Java dans la portlet, idem les débuts des servlets, avant les JSP).

Dur.

Puis les portlets se sont améliorées,
Puis les portlets ont pris une « claque » avec l’arrivée d’AJAX,
Puis les portlets se sont améliorées (itou).
Puis…
Et bien, les portlets sont encore à la merci d’autres claques (cf. plus bas).

En fait, je me demande si toutes ces évolutions et le pb des portlets ne viennent pas du fait que les portlets se situent au niveau API, mais aussi en bonne partie au niveau d’un design d’architecture (auquel appartient REST par ex), et au niveau framework, comme le suggèrent, par ex, les 2 points suivants de la spec:
# two phases of action processing and rendering in order to support the Model-View-Controller pattern.
# portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate

Dit autrement:
- si on choisit d’abord de faire des portlets, on est souvent embété ensuite par le choix d’un framework web, et son intégration avec les portlets (c’est pourquoi il y a(vait?) des bridges proposés), ce qui est pour le moins énervant alors que les portlets sont là principalement pour designer la page d’accueil.
- une autre manière de faire est de choisir un framework web (autre que les portlets) et de suivre le design d’architecture des portlets (sans utiliser un framework portlet dédié ad hoc) – ce qui est facilité car les frameworks JavaScript apportent déjà pas mal, et par le fait qu’un framework web peut remplir certaines fonctionnalités des portlets de niveau framework.

2-bis) Personnellemment, je suis plutôt preneur de la seconde approche – qui est en accord avec (1) et (1-bis).

Cela me semble en accord, par ex, la vision Nuxeo (qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir)

[la suite, en dessous]

Si les portlets étaient des applis web, alors les portlets devraient disposer de fonctionnalités proches de celles des modules OSGi, un id, des définitions de dépendances entre modules, une partie publique (API publique) et une partie privée (implémentation). Or, en gros, cela n’est pas le cas.

Je crois que le match entre les portlets et OSGi va finir par se transformer en un remake du match entre les superordinateurs spécialisés faisant état d’une techno ad hoc (~ portlets) et les clusters de PC (~ OSGi). De fait, il y a déjà plusieurs serveurs Java qui permettent de déployer des modules OSGi tout en pouvant faire appel aux API Java EE, comme le serveur Spring et le serveur JOnAS. Il est donc loisible d’imaginer implémenter les portlets comme des modules OSGi.

Certains découpent leur back-office en serveurs pour faire tourner la partie présentation (JSP) et la partie métier (avec une facade EJB ou WS). Toujours dans la même optique, je ne vois pas les portails dans la brique métier, mais dans la brique présentation et par conséquent, je ne vois pas les portlets comme des applications légères.

De fait, par ex, pour un besoin CMS/ECM, je suis plus d’accord avec l’approche Nuxeo qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir ~ approche métier=>présentation.

1) bref, encore une fois, IMHO, les portlets, il s’agit pour moi plus d’intégration graphique que d’intégration métier ; de fait, même la sécurité peut être réglée en dehors des portlets !

1-bis) Et cela m’amène à m’interroger sur l’intérêt d’un portail (coté serveur, donc). Comme j’ai pu l’écrire ici ou là, choisir un portail ressemble un peu à choisir de construire sa maison en bois uniquement parce que… la porte d’entrée est en bois. De fait, seule la page d’accueil d’un portail contient des portlets customisables, pourquoi vouloir utiliser la technologie portlet pour toute une appli web sachant que seule la page d’accueil doit être customisable ? C’est pour le moins étonnant, non ?

2) les portlets ont connu différentes vies et des débuts difficiles.

Je me rappelle des tout débuts, un vendeur m’a indiqué qu’avec les portlets,
- on ne pouvait pas faire de clustering de session http (trop compliqué/lourd),
- on ne pouvait pas utiliser de JSP avec son produit (on devait coder l’IHM en Java dans la portlet, idem les débuts des servlets, avant les JSP).

Dur.

Puis les portlets se sont améliorées,
Puis les portlets ont pris une « claque » avec l’arrivée d’AJAX,
Puis les portlets se sont améliorées (itou).
Puis…
Et bien, les portlets sont encore à la merci d’autres claques (cf. plus bas).

En fait, je me demande si toutes ces évolutions et le pb des portlets ne viennent pas du fait que les portlets se situent au niveau API, mais aussi en bonne partie au niveau d’un design d’architecture (auquel appartient REST par ex), et au niveau framework, comme le suggèrent, par ex, les 2 points suivants de la spec:
# two phases of action processing and rendering in order to support the Model-View-Controller pattern.
# portlet modes, enabling the portal to advise the portlet what task it should perform and what content it should generate

Dit autrement:
- si on choisit d’abord de faire des portlets, on est souvent embété ensuite par le choix d’un framework web, et son intégration avec les portlets (c’est pourquoi il y a(vait?) des bridges proposés), ce qui est pour le moins énervant alors que les portlets sont là principalement pour designer la page d’accueil.
- une autre manière de faire est de choisir un framework web (autre que les portlets) et de suivre le design d’architecture des portlets (sans utiliser un framework portlet dédié ad hoc) – ce qui est facilité car les frameworks JavaScript apportent déjà pas mal, et par le fait qu’un framework web peut remplir certaines fonctionnalités des portlets de niveau framework.

2-bis) Personnellemment, je suis plutôt preneur de la seconde approche – qui est en accord avec (1) et (1-bis).

Cela me semble en accord, par ex, la vision Nuxeo (qui est, d’abord CMS/ECM, ensuite portail si un besoin de présentation/intégration se fait sentir)

3) je me demande si la spec portlet n’aurait pas été plus simple en mettant l’accent sur l’approche « convention plutôt que configuration », un peu à la REST.
Cela aurait peut-être plus facilement permis de définir des portlets, sans framework portlet, en laissant la liberté à chacun utiliser son framework web préféré (par ex, en définissant un paramètre jportletid comme il existe un jsessionid) pour implémenter des portlets.

4) Je crois que la prochaine « claque » prise par les portlets pourrait venir de GWT.
Les porlets ont pris une « claque » avec AJAX et se sont mises à la sauce AJAX.
Maintenant, IMHO, on peut diviser une portlet en une partie cliente et une partie serveur. Or, un des frameworks web pour mixer JavaScript/Java et partie client/serveur, c’est GWT qui fait de la traduction Java/JavaScript.
De fait, je me demande, dans le cas où l’on devrait repenser les portlets de zéro, si une approche GWT ne serait pas au centre d’une telle initiative, offrant un conteneur (avec services associés) qui s’étendrait à la fois coté client et coté serveur.

x) Bref, je me demande si la plus grosse difficulté des portlets ne viendrait pas du fait qu’elles ont le cul entre plusieurs chaises, niveau architecture/framework/API, niveau client/serveur, niveau présentation/métier…
De fait, les portlets se « battent » sur tous les fronts ~ semblent en concurrence (à tort ou à raison) avec plein d’autres solutions, et sont sans cesse « bousculées » par les avancées dans les domaines connexes (i.e. l’introduction de AJAX). Et cela amène à évaluer leur ROI par rapport au cout de mise en oeuvre.

IMHO, je pense qu’il y a des cas d’utilisation, mais qu’ils sont la minorité (~ des cas particuliers) plutôt que la majorité, pour toutes les raisons invoquées plus haut = faut pas foncer tête baissée sur les portlets quand quelqu’un prononce le mot portail.

Et une des idées de base, c’est quand même de créer du contenu et des traitements qui soit réutilisables dans d’autres applis via le standard des portlets. OK, c’est parfois illusoire, mais suivant les archis, ça peut être assez puissant.

Sylvain FRANCOIS
Kalistick

Mais bon apres c’est mon avis personnel n’ayant encore une fois jamais mis en oeuvre de « portails de portlet »

Gilles S