Pour vous assurer que votre architecture SOA est fiable et exploiter au maximum son potentiel, voici 8 règles fondamentales à respecter.
Un contrat standard vous appliquerez
Il est important que les documents WSDL soient standarisés au maximum afin de faciliter les réutilisabilités des services.
Cette standardisation implique par exemple des conventions de nommage standardisées, des types de données standards (types complexes qu’on verra plus tard, etc.).
Un couplage faible vous appliquerez
Vos services doivent êtres indépendants et faiblement couplés aux autres composants du SI. Ceci se concrétise en veillant à ce que tous les échanges de votre service avec le monde extérieur se fassent uniquement via SOAP.
Le fait d’aller interroger directement un service, par exemple, crée une dépendance entre ces deux services. Ainsi si demain le service que vous appelez directement change d’adresse ou est supprimé, votre service n’est plus utilisable non plus. Le seul couplage toléré dans une SOA est celui avec un UDDI contenant vos contrats publiés.
Abstraits vos services seront
Les contrats que vous publiez doivent indiquer le minimum vital nécessaire à l’invocation de votre service. En aucun cas vous ne devez publier des informations sur le fonctionnement interne du service.
Toute information non utile directement à l’invocation du service peut être utilisée par d’autres services et générer des réponses inattendues.
Ceci crée également un couplage fort car les autres services du SI seront dépendants de l'implémentation que vous faites.
Par exemple : imaginez que vous exposez une fonction permettant d’avoir la liste complète des clients. Pour avoir cette liste, vous avez une méthode interne qui prend un paramètre “limit” qui fixé à -1 retourne la liste complète de tous les clients. Le fait de publier cette fonction interne dans votre WSDL peut tenter d’autres services qui veulent avoir juste les 10 premiers clients à appeler votre fonction interne.
Problème : 1 mois plus tard, vous vous rendez compte que cette fonction peut bien fonctionner sans le paramètre “limit” car de toute façon, elle sera toujours amenée à retourner la liste complète des clients, et vous changez donc votre fonction. Ceci aura comme conséquence que tous les services appelant votre fonction interne se retrouvent avec une erreur en guise de réponse à leurs requêtes les empêchant, de ce fait, de fonctionner correctement.
Solution : publiez toujours le strict minimum à l’invocation de votre service.
Des services réutilisables vous développerez
La réutilisabilité d’un service se mesure à son indépendance de la logique de son processus métier.
En d’autres termes, votre service doit retourner les réponses les plus neutres possibles afin que celles-ci soient réutilisables dans différents composants du SI.
Exemple : votre service retourne une liste de produits avec leurs détails : nom, image, description, prix.
Comme vous savez que votre service sera appelé par l’application web qui affichera des promotions pendant la période de Noël, vous pouvez être tenté de retourner le prix final du produit déduction faite des ristournes.
Félicitations, vous venez de manquer au 4e commandement !
Vous avez laissé la logique métier influencer la logique de votre service. Votre service n’est pas réutilisable. Pourquoi ? Imaginez qu’un service qui s’occupe de la vente des produits en gros aux professionnels qui eux ne bénéficient pas des réductions de Noël réservées aux particuliers, souhaite avoir les prix des produits. Votre service n’est pas exploitable dans ce cas car le prix retourné est spécifique à la logique de l’application web et son contexte.
Solution : retournez autant que possible des données neutres. C’est au service appelant d’appliquer sa logique et de manipuler ces données retournées pour les adapter à son cas d’utilisation.
Autonomes vos services seront
Quand vous développez un service web, faites en sorte qu’il soit le plus autonome possible, c'est-à-dire qu’il dispose de ses propres ressources, libraries, containers, etc.
Un bon service web est un service web que vous pouvez packager dans un war ou jar par exemple et le faire fonctionner dans n’importe quelle machine de façon indépendante.
Sans état (stateless) vos services seront
Quand vous développez un service, il faut veiller qu'aucune requête ne dépende de la réponse d’une autre.
Exemple :
Votre service gère le panier dans un e-commerce. Vous pouvez être tenté d’implémenter le fonctionnement suivant :
Un service externe appelle le vôtre en ajoutant un produit A pour le client Robert, puis fait un autre appel pour ajouter un produit B pour le même client.
Vous gardez ensuite en mémoire une session qui gère le panier de cet utilisateur de façon à ce que quand le client souhaite passer la commande, le service externe vous passe la simple requête “commander”. Comme vous avez tout ce qu’il faut en session, il suffit d’enregistrer la commande.
Votre service a donc maintenu une session en état pendant une période assez longue, et le service externe comptait sur cet état précis pour passer la commande.
Un des inconvénients de cette approche est que si vous avez 2000 clients sur la boutique, vous saturez la mémoire vive avec 2000 sessions actives. De plus, votre service doit rester actif pour maintenir les sessions ce qui réduit la scalabilité du système : en d’autres termes on aimerait pouvoir ajouter des instances de votre service et en supprimer en fonction du trafic, sauf que comme votre service a un état, il est difficile de supprimer une de ces instances sans perdre des paniers par exemple.
Solution : quand un service externe demande à ajouter un produit A au client Robert, il suffit d’enregistrer cette donnée dans le système de gestion des données (base de données par exemple) et de retourner l’id du panier. Quand le service externe souhaite ajouter un autre produit ou passer la commande, il est de sa responsabilité de vous passer l’id du panier sur lequel il faut faire l’opération. Ainsi n’importe quelle instance de votre service peut répondre à une telle demande, votre service est donc stateless.
Découvrabilité
Comme on l’a vu plus tôt dans le cours, votre service doit pouvoir être trouvé facilement par les autres services grâce à la publication de son contrat (WSDL) dans un annuaire de type UDDI.
Composabilité
Ce commandement est l’aboutissement des 7 commandements précédents. Vous avez créé un service à couplage faible, abstrait, réutilisable, autonome, stateless et découvrable. Il est temps de profiter de votre dur labeur !
Votre service doit maintenant participer à la composition d’une application ou d’un SI plus large en proposant ses fonctions à différents composants. La réutilisabilité du service doit être exploitée au maximum afin d’optimiser le système final.
Mais avant, dans le prochain chapitre, vous allez aider l’entreprise BUZZ à découper son système en services et dresser le nouveau diagramme du SI flambant neuf sur lequel l’entreprise va reposer!
