Vous voilà embauché par BUZZ pour faire évoluer leur système vieillissant vers une nouvelle architecture SOA moderne.
Nous n’allons pas faire ici le travail des architectes logiciels mais plutôt essayer de comprendre la logique du découpage d’un système en services.
À quoi tout cela va me servir ? MOI VOULOIR CODER !
Eh bien si vous travaillez sur un SI existant d’une entreprise par exemple, imaginez qu’on vous demande de créer un service de gestion des stocks. Il vous revient de déterminer les limites et les fonctionnalités de votre service pour qu’il réponde aux 8 commandements qu’on a vu précédemment et qu’il soit un service web IRA :
I : Interesting R : Reusable A : Atomic
Si vous ne savez pas découper les fonctionnalités qu'on vous demande en services dignes de ce nom, vous n'arriverez jamais à l'étape : coder. :p
Rappel du système de départ
Comme vous vous souvenez (puisque vous suivez assidûment bien sûr), BUZZ dispose d’un système vieillissant dans lequel tous les composants communiquent ensemble directement grâce à une armada d’adaptateurs pour convertir, traduire et reformater les messages entre chaque application.
Revenons en détail sur les différents composants.
ERP SAV Il s’agit d’un logiciel clé en main propriétaire acheté par l’entreprise. Le protocole de communication de ce logiciel est fixé par le constructeur. Dans ce cas, il s’agit du format JSON via HTTP.
En d’autres termes, si le composant “boutique en ligne” voudrait récupérer les détails d’un incident relatif à un client afin d’afficher le suivi de son traitement à celui-ci, il faut que la boutique en ligne envoie une requête au format JSON, elle recevra également une réponse au même format qu’elle devra comprendre et traiter.
ERP Comptabilité
Ce logiciel est également propriétaire. Le protocole de communication proposé par celui-ci est CSV via FTP.
Boutique en ligne
Il s’agit d’un CMS de type Prestashop qui fournit une boutique clé en main. Le protocole de communication ici est XML via HTTP.
Commandes Grossistes
Ce module est le nouveau web service que vous allez devoir développer.
Ne vous inquiétez pas, nous allons voir comment nous allons pouvoir harmoniser tout cela grâce à un ESB.
Définir les web services
Vous allez d’emblée éliminer : “la boutique en ligne”, “ERP comptabilité” et “ERP SAV” de la liste des composants à découper car ce sont des systèmes indivisibles voire propriétaires ou fermés.
Il reste le nouveau venu : le composant des commandes des grossistes.
Étape 1 : Définir les fonctionnalités du composant
La première étape consiste à établir clairement une liste des fonctionnalités qu’on attend du composant à développer, celles-ci nous aideront plus tard à les assembler en services.
Vous serez souvent amené à dresser cette liste de fonctionnalités à partir d’un descriptif du fonctionnement du composant.
Voici le descriptif du module “Commandes Grossistes”
Le composant devra recevoir des fichiers CSV par FTP dans lesquels des grossistes auront dressés la liste des produits à commander et leurs quantités.
Ce fichier est ensuite stocké dans un répertoire. Les grossistes doivent pouvoir le mettre à jour ou le supprimer tant que la commande n’a pas été traitée.
Votre module doit passer à des heures fixes (10h et 16h) pour relever les fichiers et passer les ordres des commandes.
Il doit ensuite créer un fichier CSV de réponse à mettre dans le même répertoire FTP et qui contient le suivi des commandes : acceptée, traitée, expédiée, annulée, etc.
Les grossistes reçoivent un email quand leurs commandes passent à certains états : traitée, annulée.
Vous allez maintenant définir une liste de fonctionnalités à partir de ce descriptif :
Fonction d’upload et de suppression de fichiers de commandes CSV via FTP
Fonction de validation des fichiers CSV (bon format et contenu)
Fonction de récupération à heures fixes des commandes
Fonction de passage des ordres des commandes
Fonction de suivi des commandes : vérification du statut et mise à jour du CSV de suivi
Envoi des emails en fonction des statuts des commandes
Maintenant que nos fonctionnalités sont clairement définies, on va pouvoir créer un découpage des web services, le plus optimisé possible. Allons-y ! :ninja:
Étape 2 : Découper le composant en web services
Découper un composant logiciel en web services est une tâche bien plus délicate que ce que l’on peut penser.
Dans notre cas, plusieurs solutions sont possibles. La plus intuitive serait :
un service qui s’occupe de tout ce qui est opérations sur les CSV : upload, validation, etc. ;
un service qui s’occupe des commandes.
Ceci paraît clair et propre, mais ce genre de découpage est exactement ce qu’il faut éviter.
Pour vous aider à découper vos web services de manière à ce qu’ils soient compatibles avec une SOA, il faut respecter les 2 règles suivantes :
Votre web service doit être IRA.
Votre web service doit respecter les 8 commandements.
Qu’est-ce qu’un web services IRA ?
I : Interesting
R : Reusable
A : Atomic
Interesting :
Les fonctionnalités de votre web service doivent être intéressantes non seulement pour servir la finalité du composant que vous développez mais potentiellement intéressantes pour l’ensemble des web services du système.
Exemple : Un service qui met à jour un champ dans une table de base de données dès qu’une commande est ajoutée est totalement inintéressant, car il s’agit d’un service qui traite du fonctionnement interne du processus de commande (par exemple dans la boutique en ligne). Aucun autre web service ne sera intéressé par la mise à jour d’un champ obscur dans une table aux tréfonds de la base de données d’un CMS !
Reusable :
Votre web service doit être réutilisable dans d’autres contextes et scénarios. Il ne doit pas être lié à la logique du processus dans lequel il intervient.
Exemple : un web service qui renvoie les 10 derniers produits ajoutés au stock n’est intéressant que dans un cadre précis (par exemple pour afficher les nouveautés dans une page de la boutique), alors qu’un web service qui renvoie n’importe quel nombre de produits qu’on lui demande est potentiellement intéressant pour beaucoup d’autres web services. Par exemple l’ERP Comptabilité peut faire appel à ce web service pour récupérer l’ensemble des prix des produits dans le catalogue !
Atomic :
Faites une seule chose et faites-la bien! Atomic veut dire indivisible et élémentaire. Évitez les fonctions dans vos web services qui par exemple passent les commandes, gèrent les retours, suppriment les produits et font le café. Évitez aussi une trop grande atomicité, on ne va pas créer un web service pour récupérer le nom d’un produit et l’autre sa description par exemple. Le tout est que celui-ci soit un bloc naturel et élémentaire.
Exemple : Un service qui a une fonction qui renvoie toutes les informations sur tous les grossistes et leurs commandes depuis la création de leurs comptes. Ce web service n'est clairement pas atomic : il sera composé d'une dizaines de composants qui iront chercher les infos des grossistes, les commandes, les prix, les infos sur les produits de chaque commandes, etc. Un web service atomic serait plutôt celui qui aura des fonctions séparées : une pour renvoyer la liste des grossistes, une autre la liste des commandes, etc. La logique étant que si nous voulons toutes ces informations, il suffit d’appeler chacune de ces fonctions et d'agréger les résultats.
Maintenant que vous avez pris le temps de réfléchir au problème, voici une proposition de découpage.
Service 1
Reçoit un fichier en entrée et l’upload dans un répertoire. Il peut également supprimer un fichier ou le remplacer.
Intéressant ? Bien sûr, beaucoup de composants peuvent être intéressés par la récupération et l’upload de fichiers divers et variés.
Réutilisable ? Absolument. Il n’est lié à aucune logique en particulier ni à aucun format de fichier, n’importe quel composant peut le réutiliser.
Atomic Oui. Le service ne fait que uploader des fichiers, c’est une fonctionnalité tout à fait fondamentale et indivisible.
Service 2
Reçoit des fichiers dans des formats populaires (CSV, XML, etc.) et les valide.
Intéressant ? Tout à fait. La plupart des composants sont amenés à utiliser des fichiers de ce type et doivent les valider.
Réutilisable ? Bien sûr. Un service qui centralise la validation des fichiers selon des critères établis à l’avance, sera appelé par tous les composants au besoin et évitera que chacun réécrive la logique de validation de chaque fichier.
Atomic Oui. La validation est un processus indivisible.
Service 3
Reçoit en entrée un fichier CSV puis place les ordres de commandes.
Reçoit en entrée une information de mise à jour de commande, puis met à jour le CSV de suivi des commandes.
NOTE Ici on a un web service qui offre plusieurs fonctionnalités. C’est souvent ce genre de web service que vous allez rencontrer. Les règles dans ce cas s’appliquent fonction par fonction.
Intéressant ? Oui. Avoir un moyen de placer des commandes et d'assurer leur suivi via un simple fichier CSV pourrait intéresser plusieurs composants et entrer dans plusieurs cas d’utilisation.
Réutilisable ? Oui. Fonction 1 : Plusieurs composants pourraient se servir de ce service pour placer des commandes très simplement via CSV. Par exemple, un service qui s’occupe des ventes privées ou groupées, pourrait l’utiliser pour passer les commandes sans avoir à recréer l’ensemble de ce que nous mettons en place pour les commandes des grossistes.
Fonction 2 : Absolument ! Tous les composants du système qui entrent dans le traitement de commande feront appel à cette fonction pour mettre à jour le statut des commandes. Exemple : les systèmes de paiement, de gestion de stock, d'expéditions, de retours, etc.
Atomic Oui. Le processus de passage de commande est un processus cohérent, extrêmement interconnecté et qui se fait en un seul bloc.
Vous aurez donc compris la logique de découpage, je vous donne les 2 derniers services nécessaires et je vous laisse vérifier s’ils sont conformes aux règles :
Service 4 : Un service de mailing qui sera appelé par le service de commande pour envoyer des emails aux grossistes pour les notifier de l’évolution de leurs commandes. Bien entendu, ce service peut être utilisé par n’importe quel autre composant pour envoyer des emails.
Service 5 : Un service qui implémente une fonction de type CRON, qui pourra appeler à intervalles réguliers d’autres services. Dans notre cas, il servira à appeler le service 3 pour qu’il récupère les CSV à des heures précises.
Bravo ! vous venez de découper l'application de gestion des commandes des grossistes en plusieurs services et vous avez justifié votre découpage.
Cependant, tout cela ne sert à rien si vos services ne peuvent pas communiquer avec les autres composants du SI. Comment allez-vous faire si vous voulez passer les détails d'une commande à l'ERP comptabilité pour prise en compte ? Ou si vous voulez demander à la boutique en ligne s'il n'y a pas des commandes en attente sur un stock pour pouvoir le vendre de votre côté à un grossiste qui en a fait la demande ?
Eh oui! Je vous rappelle que vos services ne parlent pas encore la même langue ! Regardons comment remédier à cela.
Faire communiquer les composant "Non SOAP" grâce à un ESB
1, 2, 3, 4... Je vois que je n'ai perdu encore personne en route ... n'est-ce pas ? :diable: Si ce qu'on a vu jusque-là vous parait trop théorique, tenez bon quand même, dans la prochaine partie on écrira du code et vous allez voir, ça ira mieux !
Quel est notre problème ?
Notre problème réside dans le fait que nous avons un système incluant plusieurs composants (logiciels, services, etc.) qui ne communiquent pas via les mêmes protocoles, qui ne sont pas écrits dans les mêmes langages et qui sont malgré tout extrêmement dépendants les uns des autres.
Une solution serait d'écrire des bouts de code qui traduisent les messages de chaque composant en quelque chose de compréhensible par le composant à appeler.
Par exemple, si vous voulez que votre service 3 envoie à l'ERP comptabilité le résumé de chaque commande afin que les mouvements rentrent dans les comptes, il vous faudra communiquer avec lui via CSV/FTP. Or votre service communique uniquement en SOAP (via des fichiers XML). Donc la solution évidente est d'écrire du code qu'on appellera "adaptateur" qui générera un format CSV plutôt que XML. Puis vous l'enverrez via FTP à l'ERP en question.
Malheureusement ce n'est pas si facile que ça. Imaginez maintenant que vous êtes dans un SI plus grand et que vous devez communiquer avec une centaine de logiciels et services. Allez-vous écrire une centaines d'adaptateurs ? Les autres logiciels devront en faire autant ? Qu'en est-il des logiciels propriétaires qu'on ne peut pas modifier ? Vous allez certainement créer d'autres adaptateurs de votre côté pour comprendre leurS messageS, par exemple pour interpréter une requête via CSV reçue de l'ERP compta.
Tous cela commence à ressembler sérieusement à... un plat de spaghetti. ;)
L'ESB à la rescousse
Un Enterprise Service Bus (ESB) est un composant central qui se positionnera comme un interlocuteur unique pour tous les composants du SI. Ainsi, quand vous voudrez appeler un composant X, vous n'irez plus jamais lui parler directement. Vous ne saurez même pas quel protocole il accepte, ni son URL ! Il suffira d'envoyer une requête dans votre protocole préféré (dans notre cas SOAP) à l'ESB. Celui-ci s'occupera ensuite de faire le nécessaire pour transformer votre message et l'adapter avant de le transférer au composant demandé. Il fera ensuite la même chose pour la réponse avant de vous la servir sur un plateau d'argent, reste plus qu'à déguster !
Euh... l'ESB n'a pas de pouvoirs magiques, il faudra bien lui fournir des adaptateurs ?
Vous avez parfaitement raison, il faudra bien écrire des adaptateurs à fournir à l'ESB afin que celui-ci sache comment traduire les messages.
Sauf que l'énorme avantage ici, c'est qu'on n'aura plus une architecture en plat de spaghetti. Vos adaptateurs seront tous centralisés au même endroit. De plus vous n'avez plus besoin de dupliquer vos adaptateurs entre différents composants.
Par exemple, dans l'exemple précédent, si 10 autres services ont besoin aussi de communiquer avec l'ERP Comptabilité, vous allez tout simplement leur fournir votre adaptateur. Vous vous retrouvez avec 10 copies de votre code éparpillées dans le système. Imaginez qu'il y ait un bug à résoudre ? Aïe ! Il faudra appeler tous les développeurs responsables des différents services pour leur demander de faire les changements. Certains d'entres eux seront peut-être obligés d'arrêter le service pour intégrer votre modification, mettant en péril le fonctionnement de tout le SI. Pas joli joli tout ça.
Maintenant que vous mesurez l'importance d'un ESB, regardons à quoi ressemblera notre SI.
Vous sentez déjà que c'est plus propre et carré, n'est-ce pas ?
Maintenant quand vous écrivez un adaptateur, il n'en existera qu'une seule copie placée dans l'ESB. Vous pouvez le modifier et l'améliorer à volonté en toute transparence.
Pour compléter notre survol de l'ESB, voici les avantages qu'il offre :
Couplage faible : les composants de votre SI n'ont plus à se connaître pour communiquer. Chaque service ne communique plus qu'avec l'ESB. Vous pouvez donc remplacer à votre guise un service par un autre, et gagner en liberté dans le choix des langages et des environnements.
Standardisation : quand vous créez un nouveau service, il n'est plus nécessaire de passer des semaines à l'intégrer et le faire communiquer avec les composants du SI. L'intégration est très simple et se fait uniquement avec l'ESB. Ceci va aider également l'entreprise à établir des standards dans les développements des services vu qu'il n'y a plus de contraintes d'intégration. Tous les services à terme se ressembleront dans leurs structures et modes de fonctionnement, ce qui simplifie grandement la maintenance, l'interchangeabilité des postes des développeurs et bien sûr le coût !
Scalabilité : il est maintenant beaucoup plus facile d'avoir plusieurs instances de votre service pour répondre par exemple à un trop grand nombre de requêtes (période de Noël pour BUZZ !). Ainsi, si votre service est en surcharge et ne répond plus, l'ESB pourra rediriger les requêtes vers une autre instance de celui-ci permettant ainsi au système de continuer à fonctionner sans ralentissement ou interruption.
Routage : l'ESB va vous permettre de rediriger les requêtes très finement en fonction des paramètres de votre choix. Imaginez que vous avez décidé de créer une V2 de votre service avec des améliorations significatives qui impliquent des changements dans la façon de l'appeler. Grâce à l'ESB, vous allez rediriger les requêtes arrivant à votre service vers la bonne version de celui-ci selon si elles sont compatibles V1 ou V2.
Résumons
Quand vous découpez un composant en service, veillez à ce que chaque service soit IRA et respecte les 8 commandements.
L'ESB est un composant central qui va se positionner comme un interlocuteur unique pour tous les autres composants, éliminant de fait les problèmes de communication et donnant au système une vraie consistance.
