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 '
Votre opinion