Pour comprendre et assimiler les notions d'architecture orientée services (SOA), nous allons suivre tout au long de cette partie une petite entreprise fictive du nom de BUZZ qui fabrique et vend des jouets électroniques.
Créée au début des années 1990, cette entreprise a connu une croissance continue jusqu’à nos jours. Son catalogue a évolué au fil des années et ses clients se sont diversifiés.
L’entreprise a donc été amenée à faire évoluer son SI afin de s’adapter à cette croissance et aux nouveaux canaux de vente comme Internet.
Comment faisions-nous avant ?
Jusqu’à la fin des années 1990, les entreprises exploitaient dans leurs systèmes d’informations (SI) des mainframes qui s’occupaient de toutes les opérations.
Ainsi, notre entreprise BUZZ avait commencé par mettre en place un mainframe, une sorte de grand ordinateur central très puissant (pour l’époque) et qui pouvait traiter un très grand nombre de requêtes, voire faire tourner plusieurs sessions d’un système d’exploitation.
Les développeurs déployaient alors leurs programmes dans cet ordinateur unique. Comme le système était unifié et que tous les programmeurs travaillaient plus ou moins dans le même environnement et avec les mêmes technologies, tout fonctionnait dans une joyeuse harmonie !
Revenons à notre entreprise. Au début des années 2000, BUZZ a rencontré un problème : les procédés dans l’entreprise s’étant informatisés de plus en plus, il a fallu intégrer au SI de plus en plus de logiciels externes à forte valeur ajoutée.
Par exemple, les dirigeants souhaitaient :
intégrer un ERP de gestion du service après vente (SAV),
mettre en place un e-commerce grâce à un CMS pour vendre les produits en ligne et profiter de l'essor de ce secteur,
automatiser la gestion des commandes des clients professionnels (les grossistes) afin de rester dans la course face à une concurrence de plus en plus performante, rapide et informatisée.
Chacun de ces systèmes à ajouter avait besoin d’un environnement adapté : système d’exploitation, capacité de stockage et de calcul, configuration spécifique (ports, par-feu, etc.).
La solution était d’abandonner le bon vieux mainframe, devenu très limitant, et de le remplacer par plusieurs ordinateurs (serveurs) munis d'environnements adaptés à chaque système.
Ainsi BUZZ se retrouvait alors à exploiter :
un serveur pour gérer la boutique en ligne,
un serveur pour l’ERP du SAV,
un serveur pour les grossistes et la gestion des commandes,
un serveur pour un ERP de comptabilité.
BUZZ se trouvait ainsi confronté à un gros problème : comment faire communiquer tous ces différents systèmes ?
La réponse semblait simple : faire appel à chaque système dans le format qu’il comprend.
Ainsi, quand l’ERP, écrit en COBOL, doit appeler la boutique en ligne, écrite en PHP, pour obtenir la dernière commande d’un client, la requête doit être envoyée dans un format X compatible PHP. L'ERP reçoit alors de la boutique une réponse dans un format Y qu’il doit transformer en quelque chose de compatible avec COBOL avant de l’exploiter.
Ces transformations sont réalisées par des adaptateurs. Chaque logiciel dans le SI doit avoir un adaptateur pour communiquer avec un autre.
Au final, à mesure que le système grandissait, on se retrouvait avec les problèmes suivants :
Le système devenait trop complexe : chaque logiciel devait gérer des dizaines d’adaptateurs pour communiquer avec des dizaines d’autres logiciels, qui eux-mêmes disposaient d’autres adaptateurs.
Flexibilité limitée : changer la moindre fonctionnalité dans un logiciel du SI impliquait des changements en cascade dans tout le SI : les adaptateurs à mettre à jour, un redéploiement de l’ensemble, etc.
Scalabilité difficile.
Coût de maintenance trop élevé dû à la complexité du système et à l'interdépendance forte entre les composants du SI.
La solution grâce à la SOA
Avec l’arrivée du XML, l'architecture orientée services a fait son apparition.
L’idée est simple : organiser les SI de façon à ce qu’ils soient composés de briques indépendantes appelées services. Chaque service a un nombre de fonctionnalités cohérentes et est indépendant des autres services.
Ces services vont communiquer entre eux grâce à un protocole standard, connu et compris de tous. Le protocole qui s’est largement imposé est le SOAP basé sur le XML. On y reviendra en détail.
Et concrètement ?
Pour bien comprendre le concept, analysons une implémentation de la SOA sous forme d’un web service.
Imaginez que vous développez un web service qui doit permettre de gérer les clients d’une banque.
Ce web service va avoir les fonctionnalités suivantes :
Récupérer un client grâce à son ID.
Mettre à jour les informations d’un client.
Récupérer ses mouvements de compte.
Vous développez le service en Java qui ira interagir avec les bases de données de la banque pour accomplir les fonctions citées plus haut.
Une fois mis en production, votre service va être appelé par un autre service qui s’occupe de l’application mobile. Il a besoin de faire appel aux informations que propose votre service pour afficher une page de compte à l’utilisateur final.
1er problème
Comment indiquer au service mobile où trouver votre service, les fonctionnalités qu'il propose et comment les appeler ?
La réponse est simple : il faut établir un “contrat” entre les services qui explique clairement comment fonctionne chaque service.
Ce contrat a le plus souvent le format d’un document XML appelé WSDL. Sa structure est standard et connue de tous les services.
Vous rédigerez donc un document WSDL dans lequel vous décrirez l’URL où on peut trouver votre service, quelles fonctions vous proposez et quels paramètres sont requis pour chaque fonction. Le service mobile n’a plus qu’à consulter ce document pour pouvoir faire appel à votre service en toute fluidité.
2e problème
Comment les autres services peuvent-ils trouver votre document WSDL pour consultation ?
La solution est de centraliser tous les documents WSDL dans un serveur qui tient un annuaire de ceux-ci. Les différents services connaissent l’URL de ce registre. Ils le consultent pour découvrir les nouveaux services et lire les WSDL afin de communiquer ensemble. Ils ont ainsi l’URL du service, ses fonctions et le type de réponse qu’il va renvoyer.
Ce type d’annuaire est appelé UDDI (Universal Description Discovery and Integration).
3e problème
Comment faire communiquer des services écrits dans des langages différents et utilisant des technologies variées ?
Le XML est la solution, un langage standardisé, extrêmement flexible et personnalisable. SOAP s’est donc imposé comme un protocole qui fixe les règles et les bonnes pratiques pour l’utilisation du XML dans les échanges de messages entre services.
Le service mobile dans notre exemple enverra alors un fichier XML grâce à une requête POST via HTTP vers votre service de gestion des clients. Ce fichier contient des instructions conformes à votre contrat WSDL.
Il vous suffit de parser ce fichier et de renvoyer une réponse SOAP.
4e problème
Comment faire pour créer des messages SOAP conformes afin d'appeler des services ou y répondre ?
Bien que vous devriez comprendre la structure et le fonctionnement des fichiers XML qui répondent aux normes SOAP, vous n’aurez dans les faits jamais à en créer un vous-mêmes !
En effet, la plupart des langages disposent de leurs propres librairies pour vous épargner la peine de formater des fichiers XML complexes à la main.
En Java, la librairie par défaut est JAX-WS. Elle va vous permettre de :
Générer les WSDL : décrire les classes spécifiées dans votre service dans un fichier WSDL à publier, comme vu plus haut, dans un serveur UDDI.
Invoquer un service : il vous permettra de récupérer les fichiers WSDL et d’en générer des Class “proxy” que vous appellerez depuis votre code comme n’importe quelle Class. Jax-WS générera ensuite les messages SOAP et gérera le parsing des réponses.
Huh ? J'ai rien compris ?
Ce n'est pas grave ! Vous allez vous frotter à tous ces concepts et formats de fichiers quand vous créerez un vrai service dans la deuxième partie de ce cours. Tout finira par s'éclaircir !
Résumons
La SOA définit les concepts qui permettent de mettre en place des SI articulés autour de services et communiquant de façon standardisée.
Un contrat WSDL est un document XML qui explique les fonctionnalités d’un service, comment l’appeler, où le trouver et quels types de réponses il renvoie.
UDDI est un serveur qui centralise tous les contrats des services.
Les services doivent communiquer via SOAP : un protocol XML standard.
En Java, on utilise des librairies comme JAX-WS pour générer les documents WSDL et les messages SOAP.
