Une introduction simple à SOA

Cet article est traduit de l'anglais. Vous trouverez l'article original ici.

Les entreprises utilisent des systèmes informatiques afin d’améliorer leurs opérations, en terme de productivité, de justesse, de sécurité, de coût, etc. (bien sûr, certains de ces points ne sont pas interdépendants). Mais le problème est qu’il n’y a rien de prédéfini sur la manière d’utiliser ces systèmes. Et si les logiciels ne sont pas utilisés correctement, vous n’en verrez jamais le bout ou vous rendrez vos opérations plus complexes et inefficaces.

Ce qui arrive fréquemment c’est que ce sont des parties individuelles et isolées du business qui seront automatisées en utilisant un système informatique. Ca peut aussi être des parties étrangères comme la relation client, le management RH, l’inventaire, tout comme des parties plus petites et plus spécifiques. Les entreprises peuvent utiliser des systèmes commerciaux comme les CRM, SCM et les systèmes de contrôle d’inventaire pour automatiser certaines de ces parties. Elles peuvent utiliser des systèmes développés en interne ou externalisés pour des tâches business plus spécifiques. A la fin, on obtient des systèmes indépendants qui fonctionnent isolément pour exécuter des tâches propres à l’entreprise. Cette méthode fonctionne bien et peut très bien introduire des améliorations dans le processus métier. Mais si on y réfléchit bien, il y a un fort potentiel pour plusieurs améliorations, qui ne peuvent être atteinte qu’en allant une étape plus loin. C’est d’intégrer les systèmes existants en les faisant interagir.Comment peut-on en arriver là ? Il existe beaucoup de systèmes développés par différents éditeurs ainsi que des systèmes propres, concus pour un besoin particulier. Eventuellement, ils ont des interfaces différentes et différents formats de donnée. Comment pouvons-nous établir un flux de contrôle/données parmi les systèmes pour les faire fonctionner entre eux. Attendez, c’est la qu’SOA peut vous aider! Alors, comment SOA peut être utilisé dans un environnement particulier qui varie selon la nature du problème, les besoins d’évolutions et bien d’autres facteurs. D’une manière simple, il n’y a aucune règle fixe sur la manière de l’utiliser. Mais, nous allons utiliser un exemple simple pour expliquer comment appliquer SOA. Considérons une librairie en ligne. Elle a un site web pour parcourir et commander des livres, un inventaire, un système d’expédition, de paiement, etc. Une façon simple de concevoir ce système de vente de livres est de créer un programme orienté web (on pensera aux JSP/servlets), qui accèdera aux systèmes externes et exécutera les opérations métiers. L’un des problèmes de cette approche est que le programme orienté web doit accéder à chacun des systèmes en utilisant une interface spécifique, qui requiert des modules client séparés pour chacun de ces systèmes. Et s’il y a besoin d’effectuer un simple changement sur une opération, il faut faire des modifications et redéployer l’application. La pire des parties arrive bientôt. Considérons que nous voulions créer un autre processus qui utilise l’application. Alors, il faut en écrire une nouvelle application. Même si, nous étions parti sur une application de type 3 tiers, en séparant l’interface de la logique métier, il n’y aura aucune différence. Cette Situation est illustrée ci-dessous.

Comment SOA peut faire évoluer ce scénario ? A la première étape d’SOA, nous avons besoin d’identifier les unités de fonctionnement de notre systèmes afin d’en faire des services. Pour simplifier, on peut dire que chaque système (inventaire, paiement, etc…) est un service simple. Mais dans la vie courante, on pourrait identifier plusieurs services au sein d’un seul ou, exposer des fonctionnalités de plusieurs systèmes comme un seul service. Une fois les services identifiés, on doit les implémenter comme des services standards. Une façon de faire, la plus recommandée, serait de créer des web services. Il existe beaucoup de produits qui vous aideront à créer et déployer des web services et à automatiser ce processus à plusieurs niveaux. WSO2 Web Services Application Server peut être très utile dans cette phase d’implémentation de SOA. Ces web services devraient remplacer l’ancien système (en cachant leur complexité interne) et exposer, les fonctionnalités attendues ainsi que leur définition. Une fois cette étape franchie, nous disposons d’un ensemble de services, dont la définition des fonctionnalités est connue (en utilisant WSDL) et qui communique en utilisant des protocoles connus (comme SOAP).

La prochaine étape est de les faire marcher ensemble pour exécuter des opérations métier. Pour cela on peut utiliser les Business Process Management Systems (BPMS). Un processus métier se définit en spécifiant comment contrôler le flux entre les différents systèmes (et utilisateurs) et les données utilisées en entrée et sortie de chaque système. Une fois que le processus métier est défini, on peut le déployer dans un BPMS qui l’exposera en tant que service. Donc, la seule chose que notre interface web a à faire est d’appeler le web service dans notre BPMS avec les paramètres requis. De plus, il existe plusieurs solutions de BPMS, qui peuvent être utilisés pour mettre en place cette solution. Particulièrement, le WSO2 Business Process Server fournit nombre de fonctionnalités pour simplifier le déploiement et la gestion des processus métier.

Maintenant, examinons comment cette approche basée sur SOA améliore le processus par rapport aux anciennes méthodes. Premièrement, nous avons standardisé les interfaces de chacun des systèmes. Cependant, d’autres systèmes peuvent communiquer avec les notre grâce au même protocole (même modules client). Et leur fonctionnalités sont définies dans un format prédéfini (WSDL), donc n’importe quel système externes peut comprendre ce qu’ils font. Puis, nous avons bougé la logique métier vers un BPMS. Les processus sont définis en utilisant des fichiers plats (fichiers textes) dans le BPMS. Il est donc très facile de changer et redéployer les processus métier selon les demandes de changements. La plupart des BPMS disposent d’interfaces graphiques pour amplifier la simplification de ce processus. L'introduction d'une nouvelle activité économique est également plus simple dans cet environnement. Il faut seulement écrire un nouveau processus et le déployer dans le BPMS. Il sait déjà de quelle manière communiquer avec les systèmes existants (puisque ce sont des webservices) et toute l’infrastructure déjà en place. Ceci est décrit dans le diagramme ci-dessous.

C’est un exemple simple de la manière dont SOA peut vous aider à améliorer vos opérations. Comme il est dit plus haut, l’application d’SOA varie selon des scénarios et des conditions.