Emergence de l'architecture SOA

Pendant des décennies, le développement logiciel s'appuyait sur des éléments fonctionnels
modulaires qui exécutaient une tâche précise en plusieurs endroits de l'application. A
mesure que les opérations d'intégration d'applications et de partage de composants se sont
liées à des groupes de bases de données distribuées et de ressources d'hébergement, les
entreprises ont eu besoin d'un moyen d'adapter leur modèle de développement à base de
procédures vers l'utilisation de composants distribués et distants. Si les modèles simples
comme l'appel de procédure à distance (RPC, Remote Procedure Call) montraient la voie,
ils présentaient des lacunes fonctionnelles quant à l'indépendance vis-à-vis des données et
à la sécurité nécessaires aux opérations véritablement ouvertes et distribuées.
Pour résoudre ce problème, on a transformé l'ancien modèle de fonctionnement en une
collection plus large et plus clairement structurée de services que des composants logiciels
entièrement distribués iront fournir à une application. L'architecture qui agence ces
services en mécanismes pour une utilisation ouverte en toute sécurité et sous gouvernance
stricte est dite orientée service (SOA). Née à la fin des années 1990 sous la forme d'un
simple ensemble de principes ou de besoins, elle a fait l'objet en moins de dix ans de
plusieurs mises en oeuvre pertinentes.
Principaux objectifs de l'architecture
orientée services
On dénombre trois grands objectifs de l'architecture orientée services,
chacun axé sur une partie distincte du cycle de vie applicatif.

Le premier vise à structurer sous forme de services les procédures ou

composants logiciels. Ces services sont conçus pour être faiblement
couplés aux applications : ils ne servent qu'en cas de besoin. Ils sont
prévus pour que les développeurs, tenus de standardiser la création de
leurs applications, les utilisent facilement.
Le deuxième objectif est de fournir un mécanisme de publication des services
disponibles qui comprend la fonctionnalité et les besoins d'entrée/sortie (E/S ou I/O).
Les services sont publiés de manière à faciliter leur intégration aux applications.

Le troisième objectif de l'architecture SOA est de contrôler l'utilisation de ces services

pour éviter tout problème de sécurité et de gouvernance. La sécurité de cette SOA est
surtout axée sur la sécurité des composants individuels en son sein, sur les procédures
d'authentification et d'identification en lien avec ces composants, et la sécurisation des
connexions entre les composants de l'architecture.
Modèles WS et WSDL

Au départ, les mises en oeuvre SOA dérivaient des technologies RPC, notamment celles
orientées objets, disponibles aux alentours de l'an 2000. Mais elles se sont bientôt
scindées en deux camps. Le premier, celui des services Web, représente la gestion
formalisée et hautement structurée de procédures et composants distants. Le second, le
camp du transfert d'état représentatif (REST, REpresentational State Transfer), correspond
à l'utilisation des technologies d'Internet pour accéder aux composants d'applications
hébergés à distance.

Dans le modèle WS de l'architecture SOA, le langage WSDL sert à connecter les

interfaces aux services, et le protocole SOAP à définir les API des composants ou des
procédures.
 Les principes des services Web appliqués à la liaison d'applications par un bus de
services d'entreprise (ESB, Enterprise Service Bus) ont permis aux entreprises d’intégrer
leurs applications, de renforcer l’efficacité et d’améliorer la gouvernance des données.

Les géants du secteur, IBM et Microsoft en tête, ont développé et promu toute une série
de normes WS, cadre à la fois flexible et sûr pour scinder un logiciel en une série de
fragments distribués. Toutefois, ce modèle s'est révélé difficile à utiliser et a souvent
causé une surcharge considérable dans les workflows qui passent entre les composants
d'une application.

Le modèle WS de l'architecture SOA n'a jamais atteint les niveaux d'adoption que ses
partisans lui prédisaient. A la place, il est entré en concurrence avec un autre modèle à
composants distants et reposant sur Internet : REST. Les interfaces de programmation
d'application compatibles REST, ou API RESTful, n'ont pas besoin de grosses capacités et
sont faciles à comprendre. Plus Internet intégrait d'applications, plus les API RESTful
apparaissaient comme la solution d'avenir.
Architecture SOA et microservices

La tension entre les deux visions, ensemble de principes et mise en oeuvre logicielle
spécifique, culmine avec l'arrivée de deux phénomènes : la virtualisation et le cloud
computing. Combinés, ils vont pousser les développeurs à concevoir des applications à
partir de composants fonctionnels plus petits. Les microservices, une des tendances
logicielles aiguës du moment, ont été l'apogée de ce modèle de développement. Plus il y a
de composants, plus il faut d'interfaces et plus la conception logicielle se complique : la
tendance a mis au jour la complexité et les défauts de performance de la plupart des mises
en oeuvre SOA.
 Finalement, les architectures logicielles à base de microservices ne sont que des mises en
oeuvre actualisées du modèle SOA. Les composants logiciels sont conçus comme des
services à exposer via des API, comme l'exige la SOA. Un broker d'API fait
l'intermédiaire : il donne accès aux composants et garantit l'observation des règles de
sécurité et de gouvernance. Par des techniques logicielles, il assure la correspondance
entre les différents formats d'E/S des microservices et les applications qui les utilisent.