Un projet OpenSource (initié par Ippon) qui semble aller plus loin que le projet PortletBridge, implémenté dans la portelt WebProxy de Liferay.
En gros il s'agit d'une portlet permettant de "proxyfier" (néologosime) une application web existante, même distante. A ne pas confondre avec le principe de l'IFrame qui n'est qu'un artifice de présentation au sein du navigateur.
Présentation
Le portlet d’intégration web, ou Web Integration Portlet (WIPortlet), est un portlet basé sur la spécification JSR 286 et réalisé sous la forme d’un projet Maven 2. Il a été développé pour répondre au besoin d’intégration d’une application web distante ou d’un contenu web quelconque dans un portail, quel que soit la technologie utilisée.
Le portlet se comporte comme un proxy web positionné entre le portail et l’application. La configuration minimale ne requiert que l’URL ciblée. Initialement, cette URL permet de requêter l’application distante depuis le portlet. La réponse est traitée, en particulier les liens dans le code retourné sont réécrits en URL de portlet, avant d’être redirigée vers le portail.
Un mécanisme de clipping permet de modifier le contenu récupéré pour l’adapter aux besoins du portail. Des mécanismes d’authentification, de gestion des cookies et de mise en cache sont également implémentées.
Intérêt de l’intégration dans un portlet et difficultés
Face à un portlet de ce type, une question revient régulièrement: quel est l’intérêt par rapport à un portlet de type iframe ?
La réponse est simple : l’intégration réalisée avec le WIPortlet consiste en une réelle intégration de l’application dans l’environnement du portail alors qu’un iframe se contente d’intégrer le document HTML dans son intégralité sans communication avec le portail.
En effet, dans le cadre du WIPortlet, les requêtes vers le serveur de l’application distante sont réalisées depuis le portail. Cela donne la possibilité de manipuler la réponse avant qu’elle soit retournée. En particulier, le contenu est extrait des balises body, et les scripts et feuilles de styles sont extraits des balises head. Ensuite, les liens sont réécrits pour que la navigation se fasse dans l’environnement du portail.
Un autre avantage de taille est le mécanisme de clipping qui offre davantage de liberté vis à vis de l’application à intégrer. Par exemple, on peut choisir de n’intégrer que certaines parties du contenu distant.
L’inconvénient de ce type de portlet est l’augmentation du temps de réponse dû aux traitements effectués par le portlet, même s’il peut être améliorer à l’aide du mécanisme de cache implémenté.
D’autre part, l’intégration de l’application distante peut s’avérer compliquée, notamment à cause de conflits pouvant exister avec les scripts et les feuilles de style déjà présent dans le portail. La configuration du portlet apporte des solutions pour remédier à ses difficultés. Enfin la gestion des requêtes AJAX nécessite une configuration précise et parfois une personnalisation du code du portlet pour l’adapter à l’application.
Utilisation
Le portlet a été développé sous la forme d’un projet Maven. Dans les sources, le fichier pom.xml de Maven définit plusieurs profils permettant de s’adapter aux différents portails et/ou serveurs. Par exemple pour compiler le portlet pour un portail Liferay fonctionnant avec Tomcat, la commande Maven sera:
1 | mvn -P liferay-tomcat package
|
Une fois le WAR déployé, une ou plusieurs instances du portlet peuvent être ajoutées au portail.
L’onglet « Préférences » permet de configurer le portlet en précisant notamment l’URL de l’application distante. La configuration est séparé en plusieurs catégories: configuration générale, cache, réécriture HTML, réécriture CSS, réécriture Javascript et clipping. L’utilisateur à également la possibilité de sauvegarder ses configurations puis de les réutiliser.
Le projet Web Integration Portlet (WIP) est aujourd’hui donné à la communauté Open Source sous licence LGPL et est accessible sur la plateforme github à l’adresse suivante :
https://github.com/ippontech/wip
