Tout d’abord, je ne suis pas sûr que ce soit un faux débat. On rencontre encore régulièrement des projets qui compliquent inutilement les services, il est toujours bon de faire quelques rappels

Concernant les nombres magiques, même s’ils sont manipulés au travers d’une session, il n’en reste pas moins que pour accéder à la session on utilise des clés. Ces clés sont des nombres magiques. L’utilisation de la session risque aussi de créer une dépendance entre les services qui manipulent les mêmes données de la session.

Au sujet de la complexité cyclomatique, je mettais ici en relief le fait que, puisque le service effectue des traitements différents en fonction de « nombres magiques » passés en paramètre, il cumule en réalité des traitements qui devraient être réalisés via plusieurs services. Le traitement du service devient donc plus complexe à déchiffrer (il faut suivre l’imbrication des if then else). De plus, que le service fasse ce test ou invoque un service qui le fait pour lui, le service reste lié aux données de la session et c’est ça qui pose problème (j’en reparle plus loin).

Concernant votre remarque sur le paragraphe « Que faire quand l’envie nous prend de changer … », il faut, bien évidemment, garder une certaine mesure. Je préconisais de découper le service en deux quand les traitements métiers effectués sont relativement dissociables. Il est clair qu’il ne faut pas tomber dans le travers de créer un service pour chaque valeur possible des paramètres.

A propos de votre remarque sur le paragraphe « Le contexte et la session nuisent à la réutilisation », je parlais ici de l’application appelante. Il ne faut pas effectuer des traitements en fonction de l’application appelante mais bien en fonction du besoin tel qu’il a été (ou devrait être) spécifié.
Voici un exemple :
Le service getContrats() est réalisé pour l’application web de gestion du compte mise à disposition des clients. Il a été décidé que dans cette application web, il ne serait possible de voir que certains types de contrat. Le risque ici est de se dire que le service getContrats() puisqu’il ne va (pour l’instant) être appelé que par cette application web, ne retournera que les contrats du bon type. On commet ici une erreur en rendant le service spécifique au besoin d’une application.

Au sujet de l’exemple, il est probable que le service B n’aie pas besoin de la totalité des données mis en session par le service A, il n’aura probablement besoin qu’une clé ou d’un sous ensemble des données. En lui donnant la possibilité de les passer en paramètre, il peut par exemple mettre ces données en cache à la connexion de l’utilisateur (si c’est une application web).
Le fait est qu’ici on a le choix alors que dans l’approche stateful, il faut obligatoirement passer par l’appel au service A.

Pour finir, il est vrai que les services stateful entraînent bien souvent des problèmes de performance et, dans le cas d’environnement répliqué, de potentiel problème de synchronisation.

Tout d’abord, je voudrais vous remercier pour la pertinence des informations et leur qualité : mon blog préféré pour suivre les nouvelles et solutions SOA.

Voici ma réaction à cet article.

Dans toutes les architectures sur lesquelles j’ai personnellement traou intervenu pour différentes raisons, la notion de service (dénué de toute connotation Web service et/ou SOA) a toujours été une abstraction stateless. Il y a plein d’autres choses en amont qui sont stateful mais jamais les services.

Mais bon, puisque le faux débat est lancé je me permets de faire quelques remarques.

Dans le texte on peut lire:
« Ces conditions sont souvent basées sur ce que l’on appelle des nombres magiques (ou des chaînes de caractères) qui doivent être passés en paramètre par l’appelant. Ceci peut totalement nuire à la lecture du code et à sa maintenance. »

Faux : étant donné que ces nombres ne sont jamais manipulés directement mais au travers d’une abstraction de haut niveau qui expose une API propre et lisible et qu’on appelle une session.

Le texte continue avec : « En effet, un des critères des analyseurs de code … »

Tel que c’est formulé, on peut comprendre que le code va inclure des conditions portant sur ces nombres magiques. Je pense que vous vouliez parler du code qui permet la récupération des données dans la session. Ce code va contenir des conditions pour savoir si les données sont disponibles ou non dans le contexte.

Mise à part la formulation stylistique, cet argument n’est pas correct. Car, chaque service ne va pas dire « si données dispo alors ok sinon appeler le service ad hoc ». Il va tout simplement appeler une méthode qui va le faire pour lui. Les différents services ignorent alors complètement qu’ils dépendent de données en provenance de la session ou suite à un appel de service. L’autre façon de faire est (comme vous l’écrivez) de passer directement les données extraites du contexte comme argument au service.

Remarque sur le paragraphe « Que faire quand l’envie nous prend de changer… »
La solution est possible pour des petits exemples ou pour écrire des bouquins. La réalité est qu’il n’est pas toujours possible d’associer une méthode pour une situation abstraite donnée (combinaison de plusieurs valeurs possibles des données contenues dans le contexte). Car il y aura explosion combinatoire.

Remarque sur le paragraphe « Le contexte et la session nuisent à la réutilisation »
Dans le texte, on peut lire : « Il est donc très important de développer des services qui répondent à un besoin métier et non pas au besoin d’une application. »

Je crois que l’auteur divague et qu’il ne mesure pas la signification de ce qu’il écrit. Je ne sais pas si je dois vous relancer pour faire la distinction entre service métier, service applicatif, service fonctionnel, service technique voire même service logique.

Et pour finir l’exemple est mauvais car le problème qu’il fait ressortir se pose également avec une conception stateless. Je m’explique :

Supposons que le service B n’utilise pas la session pour récupérer ses données mais qu’il les reçoit en paramètre (comme c’est préconisé un peu plus loin). D’après votre exemple, ces données sont fournies par le service A. Donc c’est à la charge de l’appelant de B de les lui fournir en entrée. Comment il faut faire, il faut appeler A. Que cet appelant soit un autre service C ou n’importe qui, ce sera à lui d’appeler A pour les fournir à B.

Le supposé problème existe donc quelque soit la conception envisagée : stateless / stateful.
Mais en réalité, il n’y aucun problème de réutilisation car lorsqu’un service est défini il déclare son contrat et voilà.

Techniquement parlant, le vrai problème des services stateful est la scalabilité.

H. TINE