Evolutions technologiques. Nouvelles orientations pour le développement.

Plan Portlets La norme JSR-168 Qu'est-ce qu'une Portlet ? uPortal et les Portlets Pluto : l'implémentation de référence Communication Portail / Portlet Cycle de vie d'une Portlet Impacts sur le développement Avantages et inconvénients 23/06/2006 Mathieu Larchet

Plan Spring Notion de conteneur léger Injection de dépendance – Hollywood Principle Modules Spring Développement en couches Bilan 23/06/2006 Mathieu Larchet

Les Portlets

Qu'est-ce qu'une Portlet ? Une portlet est une application web embarquée dans un portail Par extension, une portlet est une application web respectant la norme JSR-168 Historiquement une Portlet est une application s'exécutant à l'intérieur d'un portail. Depuis l'apparition de la norme JSR-168, on appelle Portlet toute application respectant cette norme. Dans uPortal, il est impossible de distinguer au premier coup d'œil un canal d'une Portlet, seuls les liens sont spécifiques. 23/06/2006 Mathieu Larchet

uPortal et les Portlets v2.x.x Canaux uPortal Adaptateur Portlets uPortal v3.x.x Portlets Canaux uPortal Adaptateur Actuellement avec uPortal 2.5.x : Nativement le portail exécute des canaux Un adaptateur est utilisé pour l'exécution des Portlets  Cela signifie qu'une Portlet hérite d'une classe Java qui implémente l'interface IChannel Dans la future version 3.0 d'uPortal Nativement le portail exécutera des Portlets Un adaptateur sera fourni pour l'exécution des canaux  Cela signifie que les canaux hériteront d'une classe Java qui implémentera l'interface Portlet 23/06/2006 Mathieu Larchet

Pluto Pluto est l'implémentation de référence de la norme JSR-168 Il peut être utilisé de plusieurs façons : Embarqué dans un portail sous la forme d'une librairie En mode autonome afin de procéder à des tests Très léger L'API Portlet est très similaire à l'API Servlet Pluto est l'implémentation de référence d'un moteur de Portlet. On peut faire le parallèle avec Tomcat qui est l'implémentation de référence d'un moteur de Servlet. Cela signifie que toute nouvelle implémentation d'un moteur de Portlet devra impérativement avoir un comportement identique à Pluto pour tous les aspects de la norme qui ne seraient pas forcément complètement définis. Pluto est une librairie Java (un fichier JAR) qui s'intègre dans Tomcat (couplage relativement important entre les deux) afin de pouvoir exécuter des Portlets. En réalité, la couche d'exécution de la Portlet est implémentée sous une couche d'exécution Servlet, les deux normes étant assez proches, Pluto se contente de traduire des HttpServletRequest en PortletRequest et des PortletResponse en HttpServletResponse. Pluto peut-être utilisé en mode portail afin de tester des Portlets. Le mode portail est très léger et n'est en aucun cas destiné à un environnement de production. 23/06/2006 Mathieu Larchet

Communication Portail / Portlet Modèle de fonctionnement logique Tomcat uPortal Portlet Pour un utilisateur accédant à une Portlet dans uPortal, le fonctionnement apparent est exactement le même que pour un canal. La Portlet apparaît comme embarquée dans le portail, celui-ci traitant l'ensemble des requêtes en provenance de l'utilisateur. 23/06/2006 Mathieu Larchet

Communication Portail / Portlet Modèle de fonctionnement réel Pluto Portlet uPortal Tomcat En réalité, le fonctionnement est quelque peu différent. Une Portlet est déployée dans un contexte différent de celui du portail Lors de sa publication, on fourni au portail un identifiant de Portlet qui permettra de connaître le contexte dans lequel elle est déployée. Dès que l'utilisateur accède au contenu d'une Portlet, uPortal interroge Pluto afin de traiter la requête. A l'aide de l'identifiant de Portlet, Pluto réalise un appel inter-contexte dans Tomcat afin d'envoyer la requête à la Portlet. En façade de la Portlet se trouve une Servlet Pluto qui se charge d'effectuer les traductions nécessaires. Le rendu de la Portlet est retourné via le même chemin. Il est parfois nécessaire d'embarquer dans une Portlet une ou plusieurs servlets afin de communiquer directement avec le client, par exemple pour le téléchargement de fichiers. 23/06/2006 Mathieu Larchet

Cycle de vie d'une portlet L'utilisateur clique sur une URL de type 'action' La Portlet ciblée traite la requête Une requête de type 'render' est envoyée à chacune des Portlets de la page qui rafraîchissent leur affichage 23/06/2006 Mathieu Larchet

Impacts sur le développement Choix du type d'URL pour chaque lien de notre application Programmation 100% multi-thread A l'opposé de la programmation d'un canal uPortal Réfléchir à tous les blocs critiques du code Synchronized n'est pas un remède miracle Il est impératif d'utiliser les objets de session fournis par l'API pour stocker les informations propres à un utilisateur Penser à utiliser les styles CSS pour les portlets (indépendance vis-à-vis du portail utilisé) 23/06/2006 Mathieu Larchet

Avantages & inconvénients Déploiement dans un contexte séparé Pas de collision des librairies Mutualisation possible des ressources Rechargement du contexte indépendant de celui du portail Le développeur peut utiliser les outils qu'il souhaite pour le développement (indépendance) Difficile de rester indépendant du portail et / ou du moteur (Pluto) Pas de notion de 'servant' Quelques difficultés pour l'envoi / téléchargement de fichiers 23/06/2006 Mathieu Larchet

Spring

Notion de conteneur léger A l'opposé de la philosophie J2EE : Indépendance vis-à-vis de l'environnement (serveur d'application, Servlet, Portlet, application Swing etc.). Tests unitaires très faciles à réaliser. Peu ou pas du tout de dépendance avec le conteneur (au choix du développeur). Léger (un seul fichier JAR à ajouter au projet) Nombreux modules optionnels permettant au développeur de se consacrer à ce que fait son application et non plus comment elle le fait. La définition d'un conteneur léger est à l'opposé de J2EE considéré comme un conteneur lourd. Les composants d'une application J2EE sont dépendants d'un serveur d'application. Il est relativement difficile d'être totalement indépendant de l'implémentation du serveur d'application (JBoss, WebSphere, Jonas etc.) Il est également très difficile de réaliser des tests unitaires d'une application J2EE puisque son exécution ne peut se faire qu'à l'intérieur du serveur d'application. Un conteneur léger garantit plusieurs choses : Indépendance vis-à-vis du type d'application Indépendance vis-à-vis du conteneur (le développeur peut choisir de devenir dépendant afin d'accéder à des fonctionnalités particulières du conteneur). Tests unitaires faciles (en utilisant directement une portion de l'application ou en réalisant des implémentation factices de certaines dépendances). De plus Spring apporte en plus de la notion de conteneur des modules optionnels permettant au développeur de s'affranchir de certaines tâches fastidieuses afin de se consacrer pleinement à la partie 'métier' de celle-ci. De nombreuses passerelles sont proposées vers des frameworks dédiés à certains aspects de la programmation. 23/06/2006 Mathieu Larchet

Injection de dépendance Principe d'Hollywood : Ne nous appelez pas, nous vous appellerons. Spring généralise le principe définit par le patron de conception 'Abstract Factory'. Spring se charge de l'instanciation de tous les objets de l'application et de la résolution des dépendances entre eux. 23/06/2006 Mathieu Larchet

Injection de dépendance Approche classique : Objet A Objet B Objet C Objet D Objet E Objet F Objet G H I J M K L N O P Q R 23/06/2006 Mathieu Larchet

Injection de dépendance Spring Objet A Objet C Objet B Objet D Objet E Objet F Objet G H I J M K L N O P Q R 23/06/2006 Mathieu Larchet

Modules Spring AOP Spring AspectJ ORM Ibatis – Hibernate – JDO Web JSP – PDF – Excel Tiles – Velocity MVC Spring Struts JSF Tapestry DAO Spring JDBC – LDAP Context JNDI – Remoting – EJB Spring Core Injection de dépendance 23/06/2006 Mathieu Larchet

Développement en couches Spring permet de structurer le développement d'une application en couches (architecture 3 tiers) : Couche présentation (MVC, Swing etc.). Couche métier Couche d'accès aux données Spring va permettre a chaque couche de s'abstraire de sa ou ses couches inférieures (injection de dépendance) : Le code de l'application est beaucoup plus lisible. Le maintient de l'application est facilité. Les tests unitaires sont simplifiés. 23/06/2006 Mathieu Larchet

Bilan

Bilan Portlets : Il est important que tous les nouveaux développements soient envisagés sous forme de portlets. Certains points sont à approfondir comme la communication inter-portlet, la notion de servant, et tout ce qui concerne les services offerts par uPortal. Spring : Facilite et structure le développement. Permet la focalisation sur les aspects métier. S'intègre avec de nombreux outils externes. Portlets : Il est important que les nouveaux développements soient faits sur des Portlets (roadmap uPortal). Il serait intéressant que des personnes s'investissent sur les points qui coincent (communication inter-portlets, notion de servant, upload / download). Spring : Facilite et structure le développement d'une application Permet de se focaliser sur les aspects métier d'une application S'intègre avec un grand nombre d'outils extérieurs pour des problématiques aussi diverses que l'accès à des bases de données, la supervision d'application, l'appel de web services, le développement d'application web au travers d'un MVC. 23/06/2006 Mathieu Larchet

Bilan L'utilisation de technologies standard permet : Une maintenance des applications facilitée Une plus grande communauté de support Un travail collaboratif plus efficace La reprise d'applications développées par d'autres personnes De nombreuses entreprises ont fait le choix de Spring et / ou des portlets (Cap Gemini, AMUE, Ministère des Finances etc.). 23/06/2006 Mathieu Larchet