> Comment
définir la notion de portlet ?
On entend par portlet
un composant applicatif conçu pour donner accès
- depuis l'interface utilisateur d'un portail - à
des applications de travail tierces, à un logiciel
de messagerie ou encore aux modules d'un progiciel de
gestion intégrée. Ce concept a vu le jour
début 2000, à l'initiative d'IBM notamment.
Rappelons qu'un portail d'entreprise a pour but de fournir
au personnel un point d'accès unique à diverses ressources
informatiques existantes. Il peut s'agir à la fois de
logiciels (métier) mais également de sources de contenus.
Le tout de façon personnalisée en fonction des rôles et
des responsabilités de chaque utilisateur. Le portlet
constitue par conséquent l'un des dispositifs centraux
d'une telle solution.
>
Les Portlets sont-ils comparables à des connecteurs
EAI ?
Les portlets ne
sont pas des connecteurs interapplicatifs à proprement
parler. Ils ne cherchent pas à faire dialoguer
deux composants entre eux (un outil de gestion de paie
avec un module de gestion comptable par exemple) comme
c'est le cas pour dans le monde de l'EAI. Leur objectif
est plutôt d'assurer des appels de composants au
sein d'un écran Web, et ceci de façon personnalisable
(en termes de graphisme, d'agencement, etc.).
>
Un portlet peut-il permettre d'invoquer un processus métier ?
Potentiellement,
cette couche peut effectivement assurer la publication
de processus métier, qu'ils proviennent d'un ERP...
ou même directement d'un EAI. Dans ce cas, l'orchestration
des différentes fonctions exploitées au
sein du processus est prise en charge par ces environnements.
Certains éditeurs, tels que IBM, Oracle ou encore
Sun, tentent de répondre à cet enjeux en
proposant des plates-formes multi-niveaux combinant à
la fois infrastructure de portail, serveur d'applications
et système d'intégration (EAI).
>
Comment les offres de portlets ont-elles évolué
depuis leur apparition ?
Depuis 2001, la
plupart des éditeurs de solutions de portail d'entreprise
proposent des bibliothèques de portlets. Dans un premier
temps, ces boîtes de composants se sont limitées
à la couverture des bases de données les plus utilisées
(SQL Server, DB2, etc.) et aux principaux ERP, tels SAP,
PeopleSoft ou même Siebel par exemple. Avec le temps,
elles ont été étendues à la prise en compte d'autres applications,
des outils de reporting et de travail collaboratif notamment.
Dès l'origine, les acteurs ont tenu à accompagner
ces collections d'interfaces de programmation (API) permettant
de disposer dans la même fenêtre de fonctions d'invocation
d'applications plus spécifiques, basées sur ses
systèmes centraux par exemple.
>
Cette solution est-elle mure ?
L'univers des portlets
souffre cruellement d'un manque de standardisation. Les
infrastructures de portail s'adossent encore trop souvent
à des technologies propriétaires pour mettre
en oeuvre leurs modules. Au total, ce cadre pour le moins
rigide rend assez difficile la réutilisation de
portlets existants ou le développement de nouveaux
portlets.
En attendant, ce constat pourrait
être amené à évoluer dans les prochains mois. Il semble
en effet que les fournisseurs de portails soient sur le
point de s'entendre autour de deux propositions de standards.
Basée sur le langage XML, l'une (WSRP) a été ratifiée
il y a quelques semaines par le consortium OASIS, en version
1.0. En phase de finalisation (au sein du JCP), l'autre
se place dans le monde des environnements Java (JSR 168).
Déjà, plusieurs éditeurs
majeurs ont indiqué qu'ils supporteraient les deux normes
d'ici peu. Parmi eux figurent rien moins que BEA, IBM,
Sun, SAP et Vignette. Certains fournisseurs, tels que
Plumtree, les auraient d'ores et déjà intégrés à leur
offre.
|
[