Présentation de la spécification du portlet, partie 1

Avec l'émergence d'un nombre croissant de portails d'entreprise, divers fournisseurs ont créé différentes API pour les composants de portail, appelées portlets. Cette variété d'interfaces incompatibles génère des problèmes pour les fournisseurs d'applications, les clients du portail et les fournisseurs de serveurs de portail. Pour surmonter ces problèmes, JSR (Java Specification Request) 168, la spécification de portlet, a été lancé pour assurer l'interopérabilité entre les portlets et les portails.

JSR 168 définit les portlets comme des composants Web basés sur Java, gérés par un conteneur de portlets, qui traitent les demandes et génèrent du contenu dynamique. Les portails utilisent des portlets comme composants d'interface utilisateur enfichables qui fournissent une couche de présentation aux systèmes d'information.

Les objectifs de la JSR 168 sont les suivants:

  • Définir l'environnement d'exécution, ou le conteneur de portlets, pour les portlets
  • Définir l'API entre le conteneur de portlets et les portlets
  • Fournir des mécanismes pour stocker les données transitoires et persistantes pour les portlets
  • Fournir un mécanisme qui permet aux portlets d'inclure des servlets et JSP (JavaServer Pages)
  • Définir un package de portlets pour permettre un déploiement facile
  • Autoriser la portabilité des portlets binaires entre les portails JSR 168
  • Exécutez les portlets JSR 168 en tant que portlets distants à l'aide du protocole WSRP (Web Services for Remote Portlets)

L'industrie informatique a largement accepté le JSR 168. Toutes les grandes entreprises du secteur du portail font partie du groupe d'experts JSR 168: Apache, ATG, BEA, Boeing, Borland, Broadvision, Citrix, EDS, Fujitsu, Hitachi, IBM, Novell, Oracle , SAP, SAS Institute, Sun Microsystems, Sybase, TIBCO et Vignette. La liste des supporters officiels est encore plus longue.

Actuellement, la JSR 168 est en cours d'examen public et la version finale est prévue pour septembre 2003.

Dans cet article, nous définissons d'abord les portails et les portlets, puis expliquons les concepts introduits par JSR 168, y compris les objets de base de l'API. Ensuite, nous plongeons dans les fonctions plus avancées du JSR, telles que les informations utilisateur, la localisation et la mise en cache. Nous abordons ensuite les points d'extension qui permettent aux fournisseurs de portail d'étendre la fonctionnalité actuellement définie dans la spécification de portlet. L'article se termine par la description de l'empaquetage et du déploiement d'application de portlet.

Lisez toute la série sur les spécifications du portlet:

  • Partie 1: Mouillez-vous les pieds avec les termes et concepts sous-jacents de la spécification
  • Partie 2: L'implémentation de référence de l'API Portlet révèle ses secrets

Définitions basiques

Dans cette section, nous expliquons les définitions de base utilisées dans la spécification de portlet, y compris l'architecture de base d'un portail, le conteneur de portlet et une page de portail.

Portail

Un portail est une application Web qui fournit la personnalisation, l'authentification unique et l'agrégation de contenu à partir de différentes sources, et héberge la couche de présentation des systèmes d'information. L'agrégation est le processus d'intégration de contenu provenant de différentes sources dans une page Web. Un portail peut avoir des fonctionnalités de personnalisation sophistiquées pour fournir un contenu personnalisé aux utilisateurs. Les pages du portail peuvent avoir différents ensembles de portlets créant du contenu pour différents utilisateurs.

La figure 1 illustre l'architecture de base d'un portail. L'application Web du portail traite la demande du client, récupère les portlets sur la page actuelle de l'utilisateur, puis appelle le conteneur de portlet pour récupérer le contenu de chaque portlet. Le conteneur de portlets fournit l'environnement d'exécution des portlets et appelle les portlets via l'API de portlet. Le conteneur de portlet est appelé depuis le portail via l'API Portlet Invoker; le conteneur récupère des informations sur le portail à l'aide du fournisseur de portlets SPI (Service Provider Interface).

Page

La figure 2 illustre les composants de base de la page du portail. La page du portail elle-même représente un document de balisage complet et regroupe plusieurs fenêtres de portlet. En plus des portlets, la page peut également être constituée de zones de navigation et de bannières. Une fenêtre de portlet se compose d'une barre de titre avec le titre du portlet, les décorations et le contenu produit par le portlet. Les décorations peuvent inclure des boutons pour changer l'état et le mode de la fenêtre du portlet (nous expliquerons ces concepts plus tard).

Portlet

Comme mentionné ci-dessus, un portlet est un composant Web basé sur Java qui traite les demandes et génère du contenu dynamique. Le contenu généré par un portlet est appelé un fragment, un élément de balisage (par exemple, HTML, XHTML ou WML (Wireless Markup Language)) respectant certaines règles. Un fragment peut être agrégé avec d'autres fragments pour former un document complet, comme illustré à la figure 3. Le contenu d'un portlet s'agrège normalement avec le contenu d'autres portlets pour former la page du portail. Un conteneur de portlet gère le cycle de vie d'un portlet.

Les clients Web interagissent avec les portlets via un paradigme de demande / réponse implémenté par le portail. Habituellement, les utilisateurs interagissent avec le contenu produit par les portlets, par exemple en suivant des liens ou en soumettant des formulaires, ce qui entraîne la réception des actions de portlet par le portail, qui sont ensuite transmises aux portlets ciblés par les interactions de l'utilisateur.

Le contenu généré par un portlet peut varier d'un utilisateur à l'autre en fonction de la configuration utilisateur du portlet.

Conteneur de portlet

Un conteneur de portlets exécute des portlets et leur fournit l'environnement d'exécution requis. Un conteneur de portlets contient des portlets et gère leurs cycles de vie. Il fournit également des mécanismes de stockage persistant pour les préférences de portlet. Un conteneur de portlets reçoit des demandes du portail pour exécuter des demandes sur les portlets qu'il héberge. Un conteneur de portlets n'est pas responsable de l'agrégation du contenu produit par les portlets; le portail lui-même gère l'agrégation.

Un portail et un conteneur de portlets peuvent être construits ensemble en tant que composant unique d'une suite d'applications ou en tant que deux composants distincts d'une application de portail.

Concepts

Cette section explique les concepts de programmation de base dans JSR 168, tels que le cycle de vie, l'interface, les modes et les états des fenêtres d'un portlet, ainsi que l'accès aux sessions, l'accès au stockage persistant et comment inclure les servlets et les pages JSP.

Cycle de vie du portlet

Le cycle de vie de base d'un portlet JSR 168 est:

  • Init: initialisez le portlet et mettez le portlet en service
  • Gérer les demandes: traiter différents types de demandes d'action et de rendu
  • Détruire: mettre le portlet hors service

Le conteneur de portlet gère le cycle de vie du portlet et appelle les méthodes correspondantes sur l'interface du portlet.

Interface de portlet

Chaque portlet doit implémenter l'interface de portlet ou étendre une classe qui implémente l'interface de portlet. L'interface du portlet comprend les méthodes suivantes:

  • init(PortletConfig config):pour initialiser le portlet. Cette méthode n'est appelée qu'une seule fois après avoir instancié le portlet. Cette méthode peut être utilisée pour créer des objets / ressources coûteux utilisés par le portlet.
  • processAction(ActionRequest request, ActionResponse response):pour informer le portlet que l'utilisateur a déclenché une action sur ce portlet. Une seule action par demande client est déclenchée. Dans une action, un portlet peut émettre une redirection, changer son mode de portlet ou son état de fenêtre, modifier son état persistant ou définir des paramètres de rendu.
  • render(RenderRequest request, RenderResponse response):pour générer le balisage. Pour chaque portlet de la page actuelle, la méthode de rendu est appelée et le portlet peut produire un balisage qui peut dépendre du mode du portlet ou de l'état de la fenêtre, des paramètres de rendu, des attributs de demande, de l'état persistant, des données de session ou des données de backend.
  • destroy():pour indiquer au portlet la fin du cycle de vie. Cette méthode permet au portlet de libérer des ressources et de mettre à jour toutes les données persistantes appartenant à ce portlet.

Modes de portlet

Un mode de portlet indique la fonction exécutée par un portlet. Habituellement, les portlets exécutent différentes tâches et créent un contenu différent en fonction des fonctions qu'ils exécutent actuellement. Un mode de portlet indique au portlet la tâche qu'il doit effectuer et le contenu qu'il doit générer. Lors de l'appel d'un portlet, le conteneur de portlet fournit le mode de portlet actuel au portlet. Les portlets peuvent modifier leur mode par programme lors du traitement d'une demande d'action.

JSR 168 divise les modes de portlet en trois catégories:

  1. Modes requis: chaque portail doit prendre en charge les modes Édition, Aide et Affichage. Un portlet doit au moins prendre en charge le mode d'affichage utilisé pour rendre le balisage d'une page. Le mode d'édition est utilisé pour modifier les paramètres par utilisateur afin de personnaliser le balisage du portlet, et le mode d'aide est utilisé pour afficher un écran d'aide.
  2. Modes personnalisés facultatifs: ce sont des modes qu'un portail peut prendre en charge; en mode facultatif, un portlet peut ne pas être appelé. Les modes facultatifs incluent le mode À propos pour afficher un message «À propos»; le mode Config pour permettre aux administrateurs de configurer le portlet; Mode Edit_defaults pour permettre à un administrateur de prérégler les valeurs du mode Edit; le mode Aperçu pour afficher l'aperçu du portlet; et le mode d'impression pour rendre une vue qui peut facilement être imprimée.
  3. Modes spécifiques au fournisseur du portail: ces modes ne sont pas définis dans la spécification et sont donc spécifiques au fournisseur.

États de la fenêtre

Un état de fenêtre indique la quantité d'espace de page de portail qui sera affectée au contenu généré par un portlet. Lors de l'appel d'un portlet, le conteneur de portlet fournit l'état actuel de la fenêtre au portlet. Le portlet peut utiliser l'état de la fenêtre pour décider de la quantité d'informations qu'il doit afficher. Les portlets peuvent modifier leur état de fenêtre par programme lors du traitement d'une demande d'action.

JSR 168 définit les états de fenêtre suivants:

  • Normal: indique qu'un portlet peut partager la page avec d'autres portlets. Il s'agit de l'état de la fenêtre par défaut.
  • Maximisé: indique qu'un portlet peut être le seul portlet sur la page du portail ou que le portlet a plus d'espace par rapport aux autres portlets de la page du portail, et peut donc produire un contenu plus riche que dans un état de fenêtre normal.
  • Minimisé: indique que le portlet ne doit afficher qu'une sortie minimale ou aucune sortie du tout.

En plus de ces états de fenêtre, JSR 168 permet au portail de définir des états de fenêtre spécifiques au fournisseur.

Un portlet peut être appelé dans l'un de ces trois états de fenêtre, mais est libre de produire le même balisage pour les trois états.

Magasin persistant

Le portlet peut stocker des données persistantes pour un utilisateur spécifique à l'aide de l' PortletPreferencesobjet. Les préférences peuvent être lues et écrites dans la phase d'action, et lues dans la phase de rendu. Le mode préféré pour écrire les préférences est le mode d'édition, qui fournit à l'utilisateur un écran de personnalisation. Les préférences peuvent être des chaînes ou des valeurs de tableau de chaînes associées à une clé de type chaîne. Les préférences peuvent être prédéfinies avec des valeurs par défaut dans le descripteur de déploiement.

Les préférences et la définition du portlet dans le descripteur de déploiement définissent ensemble un portlet, parfois appelé entité de portlet.

Séances

Le concept de session du JSR 168 est basé sur la HttpSessiondéfinition des applications Web. Les applications de portlet étant des applications Web, elles utilisent la même session que les servlets. Pour permettre aux portlets de stocker des données temporaires privées dans un portlet, l'étendue de session par défaut est l' étendue du portlet . Dans cette étendue, le portlet peut stocker les informations nécessaires pour les demandes des utilisateurs et spécifiques à une entité de portlet. Les attributs stockés avec cette étendue sont préfixés dans la session par le conteneur de portlets pour éviter que deux portlets (ou deux entités de la même définition de portlet) ne se remplacent mutuellement.

En plus de l'étendue de session de portlet, JSR 168 prend en charge l' étendue de session d' application Web . Dans cette étendue, chaque composant de l'application Web peut accéder aux informations. Les informations peuvent être utilisées pour partager un état transitoire entre différents composants de la même application Web (par exemple, entre des portlets ou entre un portlet et un servlet).

Y compris les servlets / pages JSP

Pour prendre en charge le modèle Model-View-Controller, le portlet doit pouvoir inclure le contenu généré à partir des servlets et des pages JSP. De cette façon, le portlet peut agir comme contrôleur, remplir un bean avec des données et inclure une page JSP pour rendre la sortie.

Dans JSR 168, le mécanisme d'inclusion pour les servlets et les pages JSP est le même pour l'API Servlet. Via le contexte du portlet, un répartiteur de requêtes est récupéré pour un chemin donné; la include()méthode est alors appelée sur cet objet request-dispatcher:

PortletRequestDispatcher rd = getPortletContext (). GetRequestDispatcher (editJSP); rd.include (portletRequest, portletResponse);

Alignement avec WSRP

WSRP regroupe le contenu produit par des portlets exécutés sur des machines distantes qui utilisent différents environnements de programmation, tels que J2EE (Java 2 Platform, Enterprise Edition) et .Net. Les services WSRP sont des services Web orientés présentation, orientés utilisateur, qui se connectent aux portails ou à d'autres applications. Ils permettent aux entreprises de fournir du contenu ou des applications sans nécessiter aucune adaptation manuelle du contenu ou de l'application en utilisant les portails; Les portails peuvent facilement agréger les services WSRP sans effort de programmation.

Le groupe d'experts JSR 168 a soigneusement aligné les concepts entre JSR 168 et WSRP. La liste suivante présente dans quelle mesure les principaux concepts ont été alignés entre les deux normes: