SOA (Service-Oriented Architecture, Architecture orientée services)

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.

Mais l'architecture SOA reste valable aujourd'hui comme au premier jour. Ses principes nous ont amenés au cloud et prennent en charge les techniques les plus avancées de développement de logiciels cloud actuellement en usage.