Les composants s'alignent sur les services web

Dans le monde Java, celui d'une majorité d'éditeurs d'infrastructure, le portail est constitué d'un ensemble de composants, les portlets. Ceux-ci sont exécutés au sein d'un conteneur spécifique. Leur rôle : traiter les requêtes et générer dynamiquement la réponse. Extension du modèle servlet, le portlet en reprend certaines caractéristiques majeures, mais en diffère sur de nombreux points. En effet, n'étant pas censé produire une page entière, il n'est donc pas lié à une URL particulière - lors de la demande d'une page, plusieurs portlets peuvent être activés. De plus, il dispose d'un mécanisme plus sophistiqué que le servlet pour accéder aux informations de configuration. Lorsqu'une requête est transmise au portail, le contrôle de l'opération est transféré à un module servlet. En fonction de la page demandée, celui-ci détermine une liste de portlets devant contribuer à la génération de ladite page ; il les active et récupère le contenu qu'ils auront généré. Enfin, le portail s'appuie sur des pages de type JSP pour y ajouter la structure de l'affichage et l'aspect.

La spécification des portlets dans Java (JSR 168) a été établie en 2003. Avant, l'absence de portabilité et d'interopérabilité obligeait les éditeurs de contenu ou d'applications à les créer sous diverses formes pour les rendre accessibles via différents portails. JSR 168 définit l'interface de programmation du portlet, le conteneur et leur relation. Il prépare aussi l'unité de déploiement, l'application portlet qui inclut un ou plusieurs de ces composants. Menée par Sun et IBM, cette spécification a ainsi été adoptée par BEA, Oracle, Tibco, Vignette, et de nombreuses implémentations open source (Apache Pluto, eXo, JBoss, uPortal, etc.)

' Les portlets en version 1 étaient censés mettre en place le modèle de programmation et aider à gérer les cas d'utilisation les plus simples ', a affirmé Stephan Hepper, architecte de portails chez IBM, lors de la dernière conférence JavaOne, pour décrire la version 2 (la JSR 286). Lancée en fin 2005, la spécification des portlets V2 devrait aboutir à la mi-2007, sous le contrôle d'IBM. Elle résout les principaux problèmes posés par la version initiale, telle l'impossibilité, pour deux portlets, d'échanger des événements ou des paramètres. En outre, la portée de la session peut être étendue à plusieurs applications portlets. Les données seront traitées au sein de la session utilisateur en cours de façon à ce que les applications soient en mesure de partager ces informations. Le conteneur de portlets deviendra ainsi plus dynamique. Ce sera davantage un courtier d'événements, tandis que les portlets sauront spécifier quels événements ils désirent recevoir ou émettre. Par ailleurs, les portlets V2 seront d'office en phase avec le standard WSRP (Web Services for Remote Portlets), défini, lui, par l'Oasis, et qui vise l'intégration de composants distants et la communication au moyen des standards d'échange Soap et WSDL.

L'orientation vers les services web est encore plus nette chez Microsoft. Le portail Sharepoint s'appuie complètement sur les frameworks .Net et ASP.Net, dotés d'interfaces pour exposer des services web ou accéder à des services distants. Le plus proche équivalent .Net du portlet, le Web Part, cible, au-delà du portail, toute une gamme d'applications web réalisées avec des outils simples par les utilisateurs finals.