Les tendances du marché

Les portails d’intégration (appelés aussi EIP, pour Enterprise Information Portal) étaient traditionnellement l’apanage des fournisseurs de solutions d’infrastructure (IBM, Microsoft, Sun, Oracle, etc.). Il s’agissait à l’origine avant tout de proposer une couche au-dessus du système d’information donnant accès, via une interface Web, aux différents services de l’entreprise (moteur de recherche transverse, bases de données, messagerie, applications métier, etc.) - et tout particulièrement aux applications non Web.

Avec l’arrivée des normes de Portlets (JSR 168, WSRP), des solutions Open Source ont vu le jour (Jetspeed, uPportal, Liferay, etc.), avec une logique un peu différente : centrées sur la notion de portlets (ces mini-applications qui sont agrégées au sein du portail). Ces normes visent avant tout à fournir un cadre pour développer ses propres connecteurs et surtout mettent en avant la notion de personnalisation (à la fois implicite - par profil d’utilisateur - et explicite - directement par l’utilisateur).

Cette logique a été reprise par des éditeurs de solutions de gestion de contenu (Open Source et propriétaires) désireux d’attaquer eux-aussi le marché des portails d’intégration, en ajoutant la possibilité d’insérer au milieu des pages des portlets applicatives (Jahia, Jalios, Kosmos, etc.). A l’inverse, les fournisseurs de portails d’intégration cherchent à étendre les fonctionnalités de leur solution, en proposant des portlets de gestion de contenu (eXo Platform, Liferay, etc.). Les gros éditeurs d’infrastructure adoptent une stratégie plus englobante : en intégrant des applications hétérogènes (souvent issues de rachats), ils parviennent à proposer des suites complètes couvrant à la fois les domaines de la gestion de contenu, des outils collaboratifs et des portails d’intégration (IBM avec Workplace et Websphere Portal ; Microsoft avec Office Sharepoint Server 2007).

Aujourd’hui, une nouvelle tendance, concommittente à la vague du "Web 2.0", remet en question les outils traditionnels d’intégration : les Open API. Il s’agit de la mise à disposition des services de l’entreprise à travers des Web Services légers de type REST. Popularisée par des applications Web très en vogue comme Google Maps, Flickr ou Amazon, l’idée consiste à appliquer les principes d’une architecture SOA sans la lourdeur des Web Services SOAP - qui, contrairement à ce que laisse penser le nom, n’ont rien de simple !

Plutôt que de mettre à disposition des Portlets "clé-en-main" prêtes à être déployées dans un portail (avec une rigidité à la fois dans l’affichage et les fonctionnalités proposées), le fournisseur se contente de donner accès aux fonctionnalités via des interfaces de programmation publiques ; et c’est le consommateur du service qui décide de l’utilisation qu’il va en faire, à travers une Widget. En outre, cela laisse toute liberté au consommateur pour mixer plusieurs applications entre elles (ce qu’on appelle communément les Mashups, les plus célèbres d’entre elles utilisant Google Maps pour faire apparaître des informations localisées sur une carte).

Les portails d’intégration traditionnels tendent à s’adapter à cette évolution, en proposant aujourd’hui d’intégrer des Widgets à côté des Portlets (c’est le cas notamment de Liferay dans le monde Open Source).

Exemples de projets réussis

Le Département du Rhône a lancé un chantier de refonte de son portail intranet en 2005. Destiné à proposer aux utilisateurs à la fois des contenus et des services applicatifs, il repose sur deux technologies Open Source complémentaires : Liferay pour la partie intégration d’applications, et eZ Publish pour la partie gestion de contenu.

Les deux solutions sont juxtaposées : Liferay a en charge toute la partie applicative, tandis qu’eZ Publish est responsable de la délivrance des contenus éditoriaux vers les utilisateurs. A noter qu’il existe également une passerelle permettant de publier des contenus issus d’eZ Publish dans des Portlets Liferay ou vers d’autres sites.

Un schéma d’architecture présentant la solution mise en oeuvre est donné ci-dessous :

Afin de répondre à la charge induite par les 10 000 utilisateurs potentiels du site (agents du département et partenaires), une architecture haute disponibilité reposant sur un cluster JBoss a été choisie pour héberger le portail Liferay. Un autre serveur est dédié à la solution de gestion de contenu eZ publish. La base de données utilisée est MySQL, qui est répliquée afin de garantir la disponibilité.

Une structure financière importante utilise Liferay

Durant le second semestre 2007, nous avons assisté ce client dans la mise en place d’un prototype de portail bancaire pour la Direction Bancaire. Les principaux besoins étaient les suivants :

• Proposer une architecture de portail permettant d’intégrer des portlets liées à des applications bancaires,
• Intégrer des contenus produits par un outil de gestion de contenus externe (CMS SPIP)
• Proposer de la personnalisation implicite, par de l’intégration de contenus ou de services en fonction du profil de l’utilisateur,
• Proposer de la personnalisation explicite ; l’utilisateur ayant la possibilité de personnaliser le contenus de certaines portlets
• Proposer une solution d’authentification et d’autorisation compatible avec l’architecture en place

Pour la réalisation le portail d’intégration Liferay a été choisi, lequel propose nativement des fonctionnalités de personnalisation, ainsi qu’un cadre pour le développement d’applications transactionnelles. Les travaux ont été découpés suivants les phases suivantes :

1. Intégration avec l’outil de gestion de contenu SPIP : des portlets spécifiques traitent des flux provenant de l’outil de gestion de contenu, puis leur appliquent des styles afin de les présente dans le portail en accord avec la charte graphique définie
2. Intégration d’une brique SSO reliée au système d’information : Une solution customisée de SSO a été mise en place, avec notamment l’intégration d’un module spécifique d’authentification (X509)
3. Intégration de portlets surfaciques, en charge de restituer de l’information en lecture seule : les portlets surfaciques ont été réalisées : celles-ci sont de simples portlets en charge de restituer du contenus externe (par exemple, la localisation d’agences, via Google Maps. Ces portlets simples ne présentent pas de logique d’enchaînement de pages.
4. Intégration de portlet transactionnelles reliées à des applications métier : une portlet transactionnelle a également été réalisée afin de valider le processus d’interfaçage avec une des applications métier.
5. Mise en place de l’administration du portail : le Back-Office d’administration du portail a été réalisé, afin de pouvoir personnaliser le portail de chaque profil utilisateur.

La réalisation de ce prototype a très nettement répondu aux attentes client, qui a décidé par la suite de poursuivre plus avant sur la base de ce qui avait été ainsi mis en place.

Architectures types

Architecture traditionnelle d’un portail d’intégration

Dans un portail d’intégration traditionnel, les applications sont rendues accessibles via des Portlets. Ces portlets peuvent être fournies avec le portail, mise à disposition par les éditeurs de progiciels (de plus en plus le cas avec les normes telles que JSR 168 et WSRP) ou bien encore développées spécifiquement. Tous les traitements (récupération des données, mise en forme) s’effectuent côté serveur.

Architecture à base d’API

Dans une architecture à base d’OpenAPI, le portail est un conteneur léger qui n’assure que la couche de présentation (celle-ci s’exécutant principalement dans le navigateur, au moyen de code Javascript). Les Widgets sont des morceaux de code Javascript utilisant la fonction XmlHttpRequest pour récupérer via des appels asynchrone (de type Ajax) les données à distance et faire la mise en forme (en utilisant des feuilles de style CSS).

Les critères de choix

Avant de choisir un portail d’intégration, il convient de qualifier l’opportunité de mettre en place une telle infrastructure. Selon le niveau de maturité du système d’information, il pourra éventuellement être plus opportun de mettre en place une architecture de type REST avec des OpenAPI pour accéder aux différents services de l’organisation.

Les principales questions à se poser avant de lancer un tel projet sont :

• Moteur de recherche : Le portail a-t-il vocation à fédérer les recherches au sein du SI ? Doit-il se connecter sur un moteur de recherche transverse existant ? Etc.
• Authentification : Un annuaire d’entreprise est-il présent ? Y a-t-il une solution de Single Sign On déployée au sein de l’organisation ? Ou bien le portail doit-il apporter cette fonctionnalité ? Comment gérer l’authentification avec les applications auxquelles va se connecter le portail (serveur d’authentification, Reverse Proxy, magasin de mots de passe...) ? Etc.
• Connecteurs applicatifs : Quelles sont les applications à intégrer au sein du portail ? Disposent-elles de connecteurs déjà prêts (JSR 168, WSRP...) ? Est-il nécessaire de développer des connecteurs spécifiques ? Quelle souplesse souhaite-t-on avoir dans l’intégration (paramétrage, présentation...) ? Le SI est-il prêt pour une architecture orientée services ? Etc.
• Personnalisation : Souhaite-t-on laisser la possibilité aux utilisateurs de personnaliser l’interface (affichage et positionnement des Portlets, choix de la mise en page, changement du thème...) ? Cette fonctionnalité doit-elle être réservée aux administrateurs fonctionnels du portail ? Est-il envisagé de mettre en place de la diffusion sélective d’informations (en fonction du profil de l’utilisateur, en fonction de données issues du SI...) ? Etc.
• Gestion de contenu : Quels sont les besoins en matière de gestion de contenus (interface de contribution, workflow de publication, mise en forme...) ? Doit-on s’intégrer avec un CMS existant ? Est-il prévu de mixer Portlets applicatives et Portlets de contenus ? Etc.