La deuxième édition de l’ouvrage de référence sur les architectures orientées services présente les concepts et les usages, ainsi que la démarche de mise en œuvre.
L’affaire est entendue : les problématiques d’intégration entre des applications par nature hétérogènes constituent un challenge aussi vieux que l’informatique. Pour les auteurs, consultants chez Sqli, « on a tenté par le passé de les résoudre par diverses méthodes et technologies : scripts pilotés par batch, échanges de fichiers par ftp, middleware orienté message, EAI…
Avec Corba, on a essayé d’apporter une réponse standardisée à la problématique mais sans rencontrer de réel succès décisif ». Voilà pour le constat. Résultat de toutes ces (vaines) tentatives : une « situation de blocage des systèmes d’information vis-à-vis des exigences métiers », résument les auteurs, pour qui « les DSI doivent trouver un moyen d’organiser et de maîtriser cette hétérogénéité. Ils doivent aussi rationaliser la mise en commun d’informations transverses à l’entreprise (les fameux référentiels) ».
Les architectures orientées services (SOA : Services Oriented Architectures) apportent une solution de déblocage. De quoi s’agit-il ? Un service, au sens SOA, « met à la disposition d’acteurs (humains ou logiciels) intervenant dans les processus métiers un accès vers une ou plusieurs fonctions métiers.
Un service concrétise le lien entre la couche métier (constituant le côté consommateur) et les implémentations dans le système d’information (constituant le côté fournisseur) en prenant à sa charge un contrat (réalisé par le côté pourvoyeur) », définissent les auteurs. De fait, un service SOA dialogue avec ses consommateurs sous une forme standardisée, tant sur le plan technique que sur le plan métier. Avec une exigence primordiale : « Vu du consommateur, le service doit offrir une valeur ajoutée ainsi qu’une garantie de qualité du service rendu. »
La notion d’agilité est donc importante dans la mesure où, face aux métiers, le système d’information doit, simultanément, s’adapter rapidement à une fusion ou à une réorganisation des équipes, permettre de déployer rapidement des processus sur la base d’un modèle fourni par les métiers, faire coexister des socles techniques hétérogènes, offrir des interfaces pour les clients et les fournisseurs, des indicateurs, et pérenniser les briques existantes.
SOA, le guide de l’architecte du SI, par X. Fournier-Morel, P. Grojean, G. Plouin, C. Rognon, Dunod, 2008, 350 pages.
Loin de l’effet de mode
Mais, attention, préviennent les auteurs : la SOA n’est pas une technologie, c’est « d’abord un ensemble de concepts constituant un modèle cohérent d’architecture pour faciliter la flexibilité du système d’information, via l’émergence de services intégrant/réutilisant des applicatifs existants ». Il ne s’agit pas non plus « de l’orienté objet avec un peu plus de marketing », et la SOA ne se réduit pas à la mise en place d’un EAI.
Ce n’est enfin pas un remède miracle : « La SOA n’est pas une solution clé en main, ni un dogme générique universellement applicable, elle nécessite un effort continu, hors de tout effet de mode », assurent les auteurs. Plus précisément, la SOA ne résout pas les problèmes existants dans les implémentations (avec un code vieillissant ou trop monolithique), ni la gestion des performances en production.
« La SOA nécessite un langage métier commun et est une affaire de compromis », rappellent les auteurs, notamment entre la centralisation des services ou leur clonage, entre un langage pivot généralisé ou des langages locaux, entre l’ouverture du système d’information et la prise en compte des contraintes de sécurité.
La SOA est donc, avant tout, une affaire de méthode, qui repose sur quatre phases. La première consiste à définir la cible. « Pour cela, on raisonne en général en termes de besoin, et de réponse à ce besoin en termes d’application : application de gestion des commandes, de gestion du catalogue produit, de centre d’appels… »
Les auteurs expliquent qu’une application est à la fois une unité métier (c’est une réponse à une attente de une ou plusieurs entités métiers), une unité organisationnelle (un projet, un budget, une équipe dédiés), une unité technique (une application, une architecture) et une unité au sein de la direction de la production (une application, une infrastructure matérielle et logicielle)
Deuxième phase : la modélisation des services, avec l’objectif de mettre en place des services réutilisables et/ou interopérables. Il convient, d’abord, de distinguer les services métiers et les services techniques. Les premiers peuvent être « soit des services d’accès à des informations, soit des services de calcul et de vérification de règles métiers, soit une composition des deux ».
Les seconds sont génériques et non liés à une ressource particulière, mais à une catégorie de ressources. Exemple : un service d’impression n’est pas lié à une imprimante mais à une catégorie d’imprimantes. Et un service métier peut s’appuyer sur plusieurs services techniques pour exécuter ses traitements. Seconde question à se poser : quelle est la granularité des services ? « L’importance de la typologie et de la granularité ne saurait être sous-estimée dans la réussite de la mise en place d’une architecture orientée service », préviennent les auteurs.
La troisième phase consiste à modéliser les processus. « Celle-ci repose sur un dialogue étroit entre maîtrise d’œuvre et maîtrise d’ouvrage. Ce dialogue doit être guidé par les quelques questions fondamentales que pose cette modélisation : granularité des services, traitement des exceptions métiers, traitement des exceptions techniques et qualité de services… », précisent les auteurs qui insistent sur « la place fondamentale des acteurs humains dans ces processus automatisés. »
Enfin, la quatrième phase concerne la modélisation des « applications composites interactives ». Les auteurs remettent en question le modèle traditionnel MVC (Modèle – Vue – Contrôleur, modèle architectural de référence pour concevoir des applications graphiques interactives) et proposent les concepts de « transaction longue et de gestion de contexte », notamment pour gérer le cas où deux utilisateurs travaillent sur le même objet métier.
« Il y a un risque bien réel de collision entre deux utilisateurs : ce problème n’est pas apparu avec l’émergence de SOA, mais l’adoption d’une démarche SOA fera immanquablement apparaître cette problématique », avertissent les auteurs.
De la planification à l’outillage
L’organisation d’un projet SOA repose sur une planification, une organisation, un outillage et une industrialisation. La planification va consister, de manière classique, à établir un plan d’urbanisme, spécifier l’architecture SOA, développer une solution métier et un service réutilisable, adapter le système existant, mettre en place le framework et l’infrastructure SOA et intégrer dans le système d’information.
L’organisation concerne les acteurs, les responsabilités de chacun, la coordination et la communication. L’outillage repose sur le framework SOA « outil de base pour concevoir et développer les solutions et les services », et sur des ateliers logiciels (modélisation production, composition, homologation). Quant à l’industrialisation, les auteurs proposent un modèle de maturité SOA : PSAUMM (Practical, Services-oriented Architecture, Unified Maturity Model) reposant sur cinq axes : gouvernance, flexibilité, productivité, réutilisation et interopérabilité.
Le dernier chapitre, intitulé « Tous vers Soa » met en exergue le fait que « la communauté des prétendants est immense » puisque l’on trouve à la fois les fournisseurs de SOA généralistes (IBM, Microsoft, Sun Microsystems…), des spécialistes SOA fournisseurs d’infrastructures (BEA, Tibco, Progess/Sonic Software, Software AG/webMethods…), sans oublier les éditeurs de solutions métiers commerciales (SAP, Oracle..) et les généralistes Open Source (Apache, Red Hat, ObjectWeb/OW2). Même si, pour les auteurs, « l’unanimité des acteurs ne doit pas cacher l’étendue du chemin restant à parcourir pour la grande majorité des offres ».
Les idées à retenir
- Le regroupement de fonctions doit avoir un sens sur le plan métier : le consommateur du service n’a pas à se préoccuper de la façon dont ces fonctions sont implémentées et a fortiori des technologies sous-jacentes.
- L’approche SOA implique de gérer le concept de contexte, qui n’est pas uniquement transactionnel mais aussi métier.
- La SOA est d’abord et avant tout une démarche architecturale et organisationnelle : le choix des technologies et des outils reste secondaire.
- L’orientation services peut s’appliquer à des fonctions liées à des concepts métiers aussi bien qu’à des concepts techniques.
- Un accord d’engagements de services est nécessaire dès lors que pourvoyeur et consommateur du service n’appartiennent pas à la même entreprise ou en cas de facturation interne.
- Le concept d’application n’est plus adapté au contexte SOA, il est préférable de parler de solution métier.
- La vision MOA d’un processus SOA ne fait pas directement émerger les services à orchestrer : pour résoudre ce problème, il faut regrouper les activités du processus pour faire apparaître les services fonctionnels.
- L’équipe intégration doit être rattachée au responsable du programme SOA, pour lui permettre de vérifier le bon avancement des travaux de tous les intervenants.
- Le déploiement de solutions SOA repose sur une infrastructure complète : il est important de bien comprendre le rôle et la place de chacun des composants de cette infrastructure.
- Si le marché est loin d’être aujourd’hui parvenu à maturité, une tendance à la spécialisation reste prévisible.