Les 10 pièges de la SOA : 07 – Mauvaise granularité des services

De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.

Le quatrième de ces pièges porte sur la mauvaise granularité des services (on entend par mauvaise granularité qu’un service couvre trop ou trop peu de fonctionnalités).

Une mauvaise granularité de services dans une SOA peut conduire à :

• De mauvaises performances ;
• De faibles capacités de réutilisation ;
• Des services sans valeur ajoutée métier.

Les principales causes de ces travers sont :

• Un design full top down ou full bottom up (Cf. « Mise en œuvre d’une SOA : Les clés du succès« ) ;
• Une perspective trop étroite (adoption d’une vision projet plutôt qu’entreprise).

Dans ce billet, nous examinerons de plus près ces symptômes et leurs causes. Puis nous verrons pourquoi la solution réside dans l’adoption d’un point de vue business lors de la conception de services.

Les symptômes annonciateurs d’une mauvaise granularité de services dans une SOA

• Personne n’est en mesure d’expliquer aux gens du métier (par exemple ventes / marketing) ce que font les services. Ceux-ci ne s’intègrent pas dans leur compréhension du métier de l’entreprise. Ces services sont donc à un niveau de détail qui n’est pas pertinent d’un point de vue métier.
• De nombreux services sont nécessaires pour réaliser quelque chose de valeur dans le métier de l’entreprise.
• L’utilisation des services au sein de la SOA conduit à énormément de petites interactions entre les systèmes ce qui impacte dramatiquement les performances de l’ensemble.
• Les services sont des variantes des opérations de base CRUD (Create, Read, Update, Delete) et n’y apportent aucune valeur fonctionnelle.
• La définition des services décrit la façon dont ils sont implémentés (par exemple, il est possible de déduire de la définition d’un service que celui-ci s’appuie sur une base de données).
• La plupart des services disponibles sont définis de telle façon qu’ils ne sont utilisés (utilisables) que par une seule (ou quelques) application(s).
• La propriété (responsabilité) des services n’est pas clairement définie. Plusieurs entités pensent qu’elles doivent être responsables d’un même ensemble de services.
• La SOA utilise beaucoup de couches de services composites. Ainsi, le plus haut niveau de service expose peut-être la bonne granularité, mais ce sont les services composés (des couches sous-jacentes) qui n’ont pas la bonne granularité. Cette mauvaise granularité est souvent causée par l’un des symptômes présentés ci-dessus et des couches supplémentaires de compositions sont mises en place pour le compenser.

Quels sont les pièges qui mènent à ces symptômes ?

Nombre de ces symptômes sont causés par une conception full Bottom Up.
Par exemple, lorsqu’un système existant est relié à une SOA, il est tentant de prendre telles quelles les APIs de ce système et d’exposer ses opérations en tant que services au sein de la SOA. Facile à faire, mais les services ainsi introduits n’auront pas de sens métier et seront potentiellement d’un grain trop fin (l’exemple le plus évidant étant les services de type CRUD). Certains parleront ici de SOA de surface.
Dans le cadre d’une démarche full Bottom Up, il peut également arriver que plusieurs entités (ou projets) travaillent sur les mêmes fonctionnalités sans le savoir, ou pire, sans souhaiter utiliser les travaux connus d’autres entités (un cas typique du syndrome « Not Invented Here »). Ainsi, chaque entité ou projet se contente de considérer son propre point de vue ce qui conduira à de multiples implémentations des mêmes services.

D’un autre côté, un design full Top down n’est pas le remède à une conception full Bottom Up, loin de là.
En effet, lorsque les services sont conçus de façon Top Down et décomposés sur les niveaux inférieurs, on arrive souvent à une myriade de services qui ne sont utilisables que dans le cadre de leur arbre de décomposition. De plus, différentes branches de l’arbre de décomposition peuvent contenir les mêmes services et les services d’une branche sont fortement couplés aux autres services de leur branche.

La conception théorique de services est un autre piège menant à une mauvaise granularité de services : des architectes ou concepteurs « tour d’ivoire » définissent des services sans liens concrets avec les projets ou processus métiers. Cela conduit à des services qui sont tellement génériques qu’aucun projet ne peut les utiliser sans les adapter. Ainsi, chaque projet va décliner ses propres variations des mêmes services.

Quel est le bon niveau de décomposition de services ?

Trouver la bonne granularité de services n’est pas aussi simple que de suivre une recette. Trouver le bon équilibre exige des connaissances, de l’expertise et l’expérimentation de différentes options. Voici cependant quelques lignes directrices qui permettent d’éviter certains travers (sans pour autant les éradiquer à coup sûr) :

• Les services devraient être décomposés en ensemble de « plus petites unités réutilisables », chacune de ces unités devant rester compréhensible par les gens du métier (« business owners »). De plus, un service ne doit pas être une composition de services à grains plus fins qui ne sont pas disponibles en tant que services distincts (Les exposer laisse ouverte la possibilité de composer d’autres services).
• D’autre part, il est important que la responsabilité (ownership) d’un service soit clairement définie. Or, si les services sont définis avec un grain trop fin, il sera très difficile de les assigner à un propriétaire.
• Enfin, un service doit rester aussi autonome que possible. Si quelqu’un veut utiliser un service, il ne doit pas être contraint à utiliser d’autres services connexes (ce qui n’empêche pas le service en question de faire appel à d’autres services).

Quoi qu’il en soit, l’important est d’itérer. Il serait utopique de vouloir arriver au bon découpage du premier coup. Au fur et à mesure des itérations, si les symptômes évoqués ici apparaissent, il est possible d’y remédier par refactoring (d’autant plus simplement qu’ils sont détectés tôt).

Traduction libre du billet « Top 10 SOA Pitfalls: #7 – Incorrect granularity of services » publié par Gero Vermaas.