Découper et calibrer correctement les services

Vincent Berdot, Alain Clapaud et Thierry Jacquot

01 Informatique

le 05/12/2007 à 07h00

envoyer
par mail

imprimer
l'article

sommaire

SOA : des architectures pas conçues pour les métiers

Imposer des outils de gouvernance

Découper et calibrer correctement les services

Le long chemin vers la normalisation de larchitecture

Des plates-formes intégrées encore jeunes

Les spécialistes de linfrastructure visent les métiers avec SOA

Les éditeurs de plates-formes cohabitent avec les spécialistes

Yves Caseau (Bouygues Télécom): éditeurs de solutions, adressez-vous mieux au métier

Voir tout sommaire  

Comment calibrer ses services ? La question est complexe, mais essentielle. Comme le souligne le Gartner Group, les principes d’urbanisation ne donnent que peu d’indications sur le mode de découpage des composants en services. Difficile de décréter a priori ce que devrait être le découpage idéal. Chaque projet est un cas particulier et exige de rechercher le meilleur compromis entre des considérations antagonistes portant sur la taille (et donc le nombre) des services, leur réutilisation et leur maintenance. Cette problématique a un impact direct sur la gouvernance SOA.

Dans ce contexte, il n’est pas surprenant que les méthodes de conception SOA (SOMA et Praxeme, par exemple) se penchent sur cette question du dimensionnement. La SSII Octo Technologies, distingue quatre typologies de services sur la base de leur taille (unitaire ou globale) et de leur nature (infrastructure ou métier). Les plus réutilisables sont les services unitaires. Ils sont soit techniques (un compteur de pages web), soit métier (une opération de crédit de compte bancaire). Les services globaux d’infrastructure (une gestion de Single Sign-On) sont plus difficiles à mettre en œuvre. Ils peuvent néanmoins générer des économies d’échelle s’ils sont consommés par plusieurs applications. Quant aux services métier à “ gros grains ” (gestion des prêts bancaires), ils doivent surtout être évalués pour leurs capacités d’interopérabilité. Car plus ils seront gros, plus ils embarqueront de fonctions, et plus ils seront spécialisés, et donc moins réutilisables. L’opérateur Completel a ainsi mis plusieurs années avant de trouver la bonne granularité pour réutiliser ses développements SOA.

A noter que le choix de l’extrême finesse des services est tout aussi risqué que l’approche privilégiant les “ gros grains ”. Dans le cadre d’un projet BPM, la banche Distribution du groupe EDF a dû revenir à une logique de “ macroservices ”. La trop forte granularité ayant conduit à une multiplication anarchique de services parfois redondants. Quant aux coûts de maintenance, ils explosent nécessairement puisque l’on gère une multitude de services.

Trouver la bonne granularité

Les méthodes architecturales SOA commencent à répondre à cette problématique de dimensionnement. Soma d’IBM, par exemple, s’appuie sur des techniques telles que l’analyse de domaine et le “ goal service modeling ”, pour déterminer les tailles optimales de services. Soma recommande par ailleurs de ne pas se contenter d’exposer des objets élémentaires (classes Java ou C++, par exemple) en tant que services. Mais de construire des services basés sur des classes d’interfaces masquant un assemblage d’objets. En évitant une multiplication abusive de services, on contribue à optimiser la performance des applications. Car on minimise le nombre d’appels entre services et par conséquent le poids des communications asynchrones sur le bus d’entreprise.

Selon Soma, le service doit être considéré comme une unité de travail complète. Il atteint sa bonne granularité dès qu’il est calé sur un “ cas d’utilisation ”, au sens UML. Il décrit alors la réaction d’un système (un composant, par exemple) soumis à une action extérieure d’un ou de plusieurs “ acteurs ”, et qui doit répondre à un “ but ”