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

Qu'est-ce que l'architecture orientée services (SOA) ?

L'architecture orientée services (SOA) est un modèle de développement logiciel qui rend les services réutilisables et leur permet de communiquer entre différentes plates-formes et différents langages pour former de nouvelles applications. Un service SOA est une unité logicielle autonome conçue pour accomplir une tâche spécifique. Les applications utilisent l'architecture orientée services et des normes d'interface simples pour accéder aux services et créer de nouvelles applications.

L'architecture SOA crée une interopérabilité entre les applications et les services. Elle garantit que les applications existantes peuvent être facilement mises à l'échelle, tout en réduisant les coûts liés au développement de solutions de services aux entreprises.

Les entreprises utilisent également l'architecture SOA pour créer des applications qui nécessitent une interaction efficace entre plusieurs systèmes. Les concepts qui définissent l'architecture SOA sont les suivants :

• La valeur commerciale est plus importante que la stratégie technique.
• Les objectifs stratégiques sont plus importants que les avantages liés à des projets spécifiques.
• L'interopérabilité de base est plus importante que l'intégration personnalisée.
• Les services partagés sont plus importants que les mises en œuvre à des fins spécifiques.
• L'amélioration continue est plus importante que la perfection immédiate.

Comment fonctionne l'architecture orientée services ?

La SOA simplifie les systèmes logiciels complexes en les transformant en services réutilisables auxquels peuvent accéder d'autres applications et utilisateurs, appelés consommateurs de services. Ces services peuvent être utilisés comme éléments constitutifs de nouvelles applications. Chaque service SOA a une tâche spécifique et une interface qui comprend les paramètres d'entrée et de sortie du service ainsi que le protocole de communication nécessaire pour y accéder.

La SOA permet aux services de communiquer à l'aide d'un système de couplage lâche pour transmettre des données ou coordonner une activité. Le couplage lâche signifie que le client d'un service reste indépendant du service dont il a besoin. En outre, le client, qui peut également être un service, peut communiquer avec d'autres services, même s'ils ne sont pas liés. Grâce à ce processus, divers services peuvent être combinés pour créer un logiciel plus complexe que d'autres applications peuvent utiliser comme une unité unique.

Un consommateur ou le propriétaire d'une application envoie des données d'entrée pour demander des informations ou une tâche à un service. Le service traite les données ou exécute la tâche demandée et renvoie une réponse. Par exemple, une personne travaillant dans le secteur des ventes ou du marketing peut effectuer une demande de service SOA à partir d'un système de gestion des relations avec la clientèle, qui permet d'accéder aux données des clients. L'employé peut fournir au service les données pertinentes, telles que le nom d'un client spécifique, et le service renverra la réponse demandée, qui peut inclure l'historique des achats du client.

L'SOA est une mise en œuvre du concept de service ou du modèle de service de l'informatique. Dans ce style architectural, les fonctions et processus commerciaux sont mis en œuvre sous forme de services logiciels, accessibles via un ensemble d'interfaces de programmation d'applications (API) strictement définies et intégrées dans des applications par le biais d'une orchestration dynamique des services.

Composants de l'SOA

L'architecture orientée vers le service (SOA) comporte généralement quatre composants principaux :

1. Le service. C'est le fondement de la SOA. Les services peuvent être privés et accessibles uniquement aux utilisateurs autorisés, ou open source et accessibles au public. Chaque service contient une implémentation de service, qui est le code responsable de l'exécution du service ; un contrat de service, qui décrit les paramètres d'un service ainsi que son coût et sa qualité ; et une interface de service, qui est la couche d'un service qui définit comment communiquer avec lui et gère la communication avec d'autres services et systèmes.
2. Fournisseur de services. Ce composant crée ou fournit le service. La plupart des organisations créent leur propre service ou utilisent des services tiers.
3. Consommateur de services. Le consommateur de services est la personne, le système, l'application ou tout autre service qui adresse des demandes de services au fournisseur de services. Le contrat de service décrit les règles d'interaction entre le fournisseur et le demandeur de service.
4. Registre de services. Également connu sous le nom de référentiel de services, un registre de services est un répertoire des services disponibles. Il est chargé de stocker les descriptions de services et d'autres informations pertinentes sur la manière d'utiliser les services d'un fournisseur de services.

Principaux objectifs de la SOA

L'architecture orientée vers le service a trois objectifs principaux, chacun d'entre eux étant axé sur une partie différente du cycle de vie de l'application :

• Service. Cet objectif vise à structurer les procédures ou les composants logiciels en tant que services. Les services sont conçus pour être faiblement couplés aux applications, de sorte qu'ils ne sont utilisés qu'en cas de besoin. Ils sont également conçus pour que les développeurs de logiciels puissent facilement les utiliser pour créer des applications de manière cohérente.
• Publication. L'architecture SOA vise également à fournir un mécanisme de publication des services disponibles qui inclut leur fonctionnalité et les exigences d'entrée/sortie. Les services sont publiés d'une manière qui permet aux développeurs de les incorporer facilement dans les applications.
• La sécurité. Le troisième objectif de l'architecture orientée services est de contrôler l'utilisation des services afin d'éviter les problèmes de sécurité et de gouvernance. L'architecture SOA repose sur la sécurité des différents composants de l'architecture, sur les procédures d'identité et d'authentification liées à ces composants et sur la sécurité des connexions entre les composants de l'architecture.

L'émergence de la SOA

Pendant des décennies, le développement de logiciels a nécessité l'utilisation d'éléments fonctionnels modulaires effectuant une tâche spécifique en plusieurs endroits d'une application. L'intégration des applications et les opérations de partage des composants étant liées à des pools de ressources d'hébergement et à des bases de données distribuées, les entreprises avaient besoin d'un moyen d'adapter leur modèle de développement basé sur des procédures à l'utilisation de composants distants et distribués.

Le concept général qui a émergé était l'appel de procédure à distance (RPC). Cette approche permettait à un processus logiciel d'en invoquer un autre comme s'il était local, même si l'autre processus pouvait se trouver dans une application, un ordinateur ou un centre de données différent.

Le problème du modèle RPC était qu'il permettait trop de variations dans la mise en œuvre. Il manquait également certains éléments importants :

• Un ensemble systématique d'outils permettant d'assurer la sécurité des flux d'informations.
• Gouvernance des droits d'accès aux processus d'entreprise concernés.
• Découverte, connexion et formats de messages pour les services eux-mêmes.

Le concept de services introduit par l'SOA fait partie intégrante du cloud computing et de la virtualisation modernes. Cependant, l'SOA elle-même a été largement déplacée.

Qu'est-ce qu'un bus de service d'entreprise ?

La plupart des SOA sont mises en place à l'aide d'un bus de service d'entreprise (ESB). Les ESB sont si souvent utilisés avec les SOA que les termes sont parfois interchangeables. Un ESB est un modèle architectural qui permet aux composants logiciels centralisés de s'intégrer entre les applications. Les ESB transforment les modèles de données, gèrent le routage et la messagerie, convertissent les protocoles de communication et gèrent l'écriture de requêtes multiples.

Un ESB fait de chacune de ces intégrations sa propre interface de service que les nouvelles applications peuvent réutiliser. Sans ESB, chaque application devrait se connecter directement à chaque service et interface de service pour effectuer l'intégration ou la transformation nécessaire, ce qui rend la création de nouveaux logiciels moins efficace.

Mise en œuvre de la SOA

L'architecture SOA est indépendante des fournisseurs et des technologies. Cela signifie qu'une variété de produits peut être utilisée pour mettre en œuvre l'architecture. Le choix du produit à utiliser dépend de l'objectif du système.

L'architecture orientée services est généralement mise en œuvre à l'aide de services web tels que le protocole d'accès aux objets simples (SOAP) et le langage de description des services web (WSDL). D'autres options de mise en œuvre sont disponibles, notamment Windows Communication Foundation, gRPC et la messagerie, par exemple avec Java Message Service ActiveMQ et RabbitMQ.

Les implémentations SOA peuvent utiliser un ou plusieurs protocoles et peuvent également utiliser un outil de système de fichiers pour communiquer les données. Les protocoles sont indépendants de la plate-forme et du langage de programmation sous-jacents. La clé d'une mise en œuvre réussie est l'utilisation de services indépendants qui exécutent des tâches de manière standardisée sans avoir besoin d'informations sur l'application appelante ou sans que l'application appelante ait besoin de connaître les tâches exécutées par le service.

Les applications courantes de l'SOA sont les suivantes :

• Les forces armées utilisent l'SOA pour déployer des systèmes de connaissance de la situation.
• Les organismes de santé l'utilisent pour améliorer la prestation des soins de santé.
• Les applications et les jeux mobiles utilisent l'architecture SOA pour accéder aux fonctions intégrées d'un appareil, telles que le système de positionnement global.
• Les musées utilisent l'architecture SOA pour créer des systèmes de stockage virtualisés pour leurs informations et leur contenu.

Avantages de l'architecture orientée services

L'architecture orientée vers le service (SOA) présente plusieurs avantages majeurs :

• Normalisation. L'architecture SOA utilise le modèle RPC couramment utilisé dans la programmation structurée. Elle normalise la façon dont les processus d'entreprise sont automatisés et utilisés d'une manière qui préserve la sécurité et la gouvernance.
• Réutilisation. Les services peuvent être réutilisés pour créer de multiples applications. Les services SOA sont conservés dans un référentiel et reliés à la demande, faisant de chaque service une ressource disponible pour tous, sous réserve des contraintes de gouvernance. La réutilisation des services permet aux organisations de gagner du temps et de réduire les coûts de développement associés.
• Facilité de maintenance. Comme tous les services sont indépendants, ils peuvent être facilement modifiés et mis à jour sans affecter les autres services. Cela permet de réduire les coûts d'exploitation d'une organisation et d'accélérer la mise sur le marché des applications en cours de développement.
• Promotion de l'interopérabilité. L'utilisation d'un protocole de communication standardisé permet aux plateformes de transmettre facilement des données entre les clients et les services, indépendamment des langages sur lesquels elles sont construites.
• Haute disponibilité. Les installations SOA sont accessibles à toute personne qui en fait la demande.
• Fiabilité accrue. L'architecture SOA génère des applications plus fiables car il est plus facile de déboguer de petits services qu'un code volumineux.
• Évolutivité. L'architecture SOA permet aux services de fonctionner sur différents serveurs, ce qui accroît l'évolutivité. En outre, l'utilisation d'un protocole de communication standard permet aux organisations de réduire le niveau d'interaction entre les clients et les services. Avec un niveau d'interaction plus faible, les applications peuvent être mises à l'échelle sans ajouter de pression supplémentaire.

Limites de l'architecture orientée services

L'une des principales limites de l'architecture SOA est que le modèle des services web n'est pas largement accepté ou adopté. Cela s'explique en partie par sa complexité. Elle est également due à l'incompatibilité entre l'approche des services web et le modèle de transfert d'état de représentation (RESTful API) de l'internet. L'internet et le modèle cloud ont mis en évidence des problèmes spécifiques liés à l'architecture SOA et aux services web, et l'industrie a adopté d'autres modèles. Cela dit, de nombreux experts continuent de penser que l'architecture SOA est toujours utile.

Les autres inconvénients de la SOA sont les suivants :

• La mise en œuvre de la SOA nécessite un investissement initial important.
• La gestion des services est compliquée car les services échangent des millions de messages difficiles à suivre.
• Les paramètres d'entrée des services sont validés à chaque fois que les services interagissent, ce qui diminue les performances et augmente la charge et les temps de réponse.
• L'évolutivité est limitée lorsque les services doivent se coordonner avec diverses ressources partagées.
• Les systèmes SOA complexes peuvent développer des dépendances entre plusieurs services, ce qui rend les modifications et le débogage difficiles.
• Les SOA utilisant des ESB créent un point de défaillance unique, ce qui rend impossible la communication entre les clients et les services en cas de défaillance d'un ESB.

Services web et modèles WSDL de l'architecture SOA

Initialement, les implémentations SOA étaient basées sur les technologies RPC et de courtier d'objets disponibles vers 2000. Depuis lors, deux modèles SOA ont vu le jour :

• Le modèle des services web. Cette approche utilise une gestion hautement architecturée et formalisée des procédures et des composants distants. Elle utilise également le WSDL pour relier les interfaces aux services et le SOAP pour définir les API des procédures ou des composants. Les principes des services web relient les applications via un ESB, ce qui aide les entreprises à intégrer leurs applications, à garantir l'efficacité et à améliorer la gouvernance des données. Cette approche ne s'est jamais imposée et n'a plus la faveur des développeurs.
• Modèle REST. Le modèle de transfert d'état "représentationnel" représente l'utilisation de la technologie Internet pour accéder à des composants d'applications hébergés à distance. Il a attiré l'attention parce que les API RESTful ont une faible surcharge et sont faciles à comprendre.

Quelle est la différence entre SOA et microservices ?

REST et l'internet ont supplanté l'architecture SOA avant qu'elle ne gagne en importance, la confinant aux applications patrimoniales, souvent construites autour de l'ESB. La pensée RESTful a converti la notion plus large de services en processus logiciels plutôt qu'en processus d'entreprise. Cette vision centrée sur le logiciel est devenue connue sous le nom de microservices, qui est le terme utilisé aujourd'hui.

Le terme "services web" est toujours utilisé dans le cloud, où il désigne l'ensemble des services packagés offerts par les fournisseurs cloud pour faciliter le développement d'applications basées sur le cloud. Il existe des dizaines de ces services disponibles chez tous les fournisseurs de clouds publics, et ils sont tous accessibles via des interfaces REST.

Les microservices sont la dernière évolution du concept de services. Il s'agit de petits composants logiciels auxquels on accède par l'intermédiaire d'une interface REST. La pratique moderne consiste à appliquer la sécurité et la gouvernance en dehors du service et des API de microservices, généralement en utilisant un courtier de services qui agit en tant qu'intermédiaire pour authentifier les droits d'accès.

Avec cette approche, la découverte de type SOA et les référentiels de services ne sont pas pertinents car les processus logiciels et les microservices construisent des applications, et les composants d'application sont explicitement liés et ne sont pas invoqués en fonction des flux de travail. La découverte et la liaison des microservices sont plutôt définies pour prendre en charge l'évolutivité sous charge et la résilience, l'une des huit caractéristiques clés de l'informatique cloud.

Les microservices peuvent être partagés entre les applications, et les fournisseurs de cloud peuvent proposer des architectures de microservices sans serveur, payées à l'utilisation, pour l'hébergement. Dans ces cas, il peut y avoir un contrat commercial formel de microservice ou de service pour décrire les garanties de performance spécifiques et les conditions de paiement. Même les microservices internes peuvent faire l'objet d'un contrat si l'organisation informatique facture l'utilisation aux départements.

Quelle est la différence entre SOA et SaaS ?

Le logiciel en tant que service (SaaS) est une forme de cloud public dans laquelle un fournisseur de services ou un fournisseur de cloud public offre une application commerciale complète via une API RESTful à partir du cloud.

Le SaaS est un autre développement de l'informatique dématérialisée qui a eu un impact sur la SOA et qui, d'une certaine manière, revient aux principes originaux de la SOA. Le SaaS pourrait être plus correctement appelé application en tant que service, car l'objectif est de fournir un support complet pour un processus commercial dans le cloud. Étant donné que le service est un processus commercial, le SaaS s'apparente à l'SOA. Il s'apparente également à certaines formes de microservices dans la mesure où le SaaS est proposé conformément à un contrat de service qui décrit les niveaux de service et la tarification.

Les services SaaS offriront presque toujours des API pour soutenir l'intégration du travail SaaS avec d'autres processus commerciaux toujours hébergés dans le centre de données ou même dans un autre cloud. Toutefois, ces interfaces obéiront aux conventions modernes relatives aux microservices et aux API, et non aux conventions relatives aux SOA et aux services web.

Découvrez les technologies et les outils disponibles pour le développement d'applications logicielles dans cet aperçu des moyens de sécuriser le développement de logiciels.