Développement dans le portail ou application tierce spécifique ? Les méthodes ne manquent pas pour gérer ses données. Mais où coder quoi ? Et si Liferay venait proposer une réponse ?
Titre volontairement tendancieux pour cet article, d'autant que ceux qui me connaissent savent que je suis très attentif au respect du périmètre d'une application. En effet, j'ai trop souvent vu dans mes missions de produits détournés de leur fonction, avec souvent de lourdes conséquences techniques, fonctionnelles et donc financières. Qu'il s'agisse d'un outil de GED dont la brique BPM sert à construire une plateforme de workflow, de CMS dont le plugin calendrier sert d'outil de gestion de projet, ou de portail utilisé comme serveur de SSO d'entreprise, les tentations sont aussi nombreuses que les risques.
Le constat : des outils lourds pour des besoins légers ?
Bien souvent, ces "erreurs" de conception partent de la même décision : aller au plus rapide car on n'a "pas le temps". Pas le temps de bien faire, pas le temps de comprendre une solution architecturée avec des briques spécialisées. La réalité projet est souvent complexe et ces décisions sont bien compréhensibles, d'autant plus qu'elles s'accompagnent quasiment toujours de la volonté de "mieux faire plus tard". Hélas cet espoir d'amélioration est souvent vain.
Pourtant quelques constats montrent que faire vite et bien est possible. Bien souvent, de nombreux modules d'un projet de portail se limitent techniquement à des actions simples : la lecture et l'écriture d'un modèle de données avec gestion des droits . Quelques exemples classiques :
- Un calendrier évènementiel
- L'inscription à une newsletter
Par rapport à ces besoins, il n'existait encore récemment que deux options industrielles :
- Développement spécifique à partir d'un framework : ce qui donne une forte maîtrise du développement, mais nécessite de coder l'accès aux bases, la pile de gestion de droits...
- Détournement des fonctionnalités d'un outil type ECM : ce qui nécessite des compétences spécifiques à l'outil, mais présente l'avantage de pouvoir réutiliser les composants de base du produit.
La réponse Liferay
Dans cette perspective, Liferay 6 apporte une solution industrielle intégrée pour répondre à des problématiques locales :
- Liferay Service Builder : à partir d'un fichier XML, Liferay génère les entités de stockage ainsi que les services d'accès (CRUD) et configure l'indexation pour les rendre accessibles par le moteur de recherche. L'ensemble est intégré comme une ressource dans la pile de gestion de droits classique de Liferay.
- MVC Portlet Development : Liferay propose également un ensemble d'APIs pré-packagées pour développer les portlets. Pour mettre en musique les services développés plus haut, il suffit de coder les actions et enchainements de vues dans la classe portlet et d'utiliser les outils de management d'exceptions intégrés. L'ensemble est rendu accessible par Liferay via les frameworks d'affichage de Liferay, AUI par exemple.
Liferay permet donc de développer rapidement un service métier avec son stockage, sa gestion de droits et ses interfaces d'accès et d'administration. Si simple et si rapide qu'on pourrait être tenté de généraliser le cas à tous les développements métier rencontrés. D'autant que l'ensemble est désormais parfaitement intégré dans Eclipse. Vous m'aurez anticipé, il est bien entendu hors de question de tout faire avec le Service Builder. Alors, comment choisir ?
Quand l'utiliser ?
J'ai passé un certain temps à échanger sur le sujet avec les développeurs et architectes Liferay durant le dernier Symposium International Liferay fin 2010 à Offenbach. Notre avis sur la question est assez simple. Liferay Service Builder (SB) n'est pas la réponse définitive à l'hébergement du besoin métier. Liferay SB existe avant tout afin de permettre à des TPE / PME n'ayant pas les moyens ou le temps de créer une application métier dédiée de pouvoir quand même adresser leur besoin dans un budget raisonnable. Toutefois, il est évident que, dès que le besoin grandit, il faut sortir le modèle de Liferay et construire une application dédiée. Les principales raisons sont les suivantes :
- Si les volumes augmentent, la consultation augmente. Trop d'accès à cette ressources peuvent être une source de congestion du portail
- Quand une application fonctionne, ses données prennent de la valeur. De nombreux besoins adjacents émergent, comme par exemple des tableaux de reporting, l'intégration à des applications tierces, la mise à disposition d'APIs de consultation (base référentielle). Tous ces besoins deviennent lourds et couteux à mettre en place tant que les données et services restent dans le giron Liferay
- D'un point de vue architecture, Liferay a pour métier l'assemblage de vue. On ne sort jamais une solution de son périmètre
En résumé, l'analyse
Liferay Service Builder est une solution réellement avantageuse de développement rapide permettant de manipuler un jeu de données simple. Il offre un avantage décisif à la solution lorsqu'il s'agit de choisir dans l'offre pléthorique des portails commerciaux. Les services développés sont robustes et permettent de mettre en ligne rapidement et à moindre frais les portlets simples que réclament souvent le métier et qui assurent l'acceptation du portail comme outil de travail.
Attention toutefois, développer certain services métier via le Service Builder peut induire l'effet inverse : coûts d'entretien importants, allongement des développement de nouvelles fonctionnalités.
Pour trancher entre le Service Builder et un développement spécifique "from scratch", la valeur est un facteur déterminant. Quelle est la valeur de chaque jeu de données concerné par le développement envisagé ? S'agit-il de données essentielles et à haute valeur pour mon activité ? Dans ce cas, l'option d'un développement spécifique est souvent préférable pour ses avantages en termes de maintenance et de souplesse d'évolution. Dans le cas contraire, le Service Builder devient une alternative rentable. Dans un projet de portail complexe, le choix du mode de développement pourra être mixte entre développement spécifiques et Service Builder.
Liferay Service Builder est donc doublement bénéfique. D'une part il permet de réaliser des développements économiques sur une plateforme de haut niveau D'autre part, il constitue un tremplin pour des données à fort potentiel en leur offrant une visibilité immédiate à coût réduit et en démontrant leur importance stratégique. Globalement, Liferay Service Builder contribue donc à maximiser la valeur des données d'un projet de portail en gardant la maîtrise du budget alloué.
Patrick NERDEN
Commentaires