L'architecture orientée services (SOA), qu'est-ce que c'est ?

L'architecture orientée services (ou SOA, Service-Oriented Architecture) est un modèle de conception qui rend des composants logiciels réutilisables, grâce à des interfaces de services qui utilisent un langage commun pour communiquer via un réseau.

Un service est une unité autonome de fonctionnalité logicielle, ou d'un ensemble de fonctionnalités, conçue pour réaliser une tâche précise comme récupérer des informations ou exécuter une opération. Il contient les intégrations de code et de données nécessaires pour exécuter une fonction métier distincte et complète. Vous pouvez y accéder à distance, et interagir avec lui ou le mettre à jour de manière indépendante.

En d'autres termes, l'architecture SOA permet à des composants logiciels déployés et gérés séparément de communiquer et de fonctionner ensemble sous la forme d'applications logicielles communes à différents systèmes.

Avant l'arrivée de l'architecture SOA à la fin des années 1990, il était difficile de connecter une application à des services hébergés par un autre système. Cela nécessitait une intégration point-à-point poussée (connectivité, routage, traduction des modèles de données, etc.), que les développeurs devaient ensuite reproduire pour chaque nouveau projet. Ce modèle était appelé « monolithique », car tout le code de l'application tenait dans un déploiement unique. Si l'un des éléments de l'application ne fonctionnait pas correctement, il fallait mettre hors ligne l'application entière pour résoudre le problème avant de déployer une autre version.

En exposant des services via des protocoles réseau standards (comme SOAP, JSON, ActiveMQ ou Apache Thrift) pour envoyer des requêtes ou accéder aux données, l'architecture SOA évite aux développeurs de devoir réaliser une intégration de A à Z. À la place, ils peuvent utiliser des modèles appelés ESB pour réaliser l'intégration entre un composant centralisé et les systèmes back-end, puis les rendre disponibles en tant qu'interfaces de services. Cela permet aussi aux développeurs de réutiliser les fonctions déjà existantes au lieu de les recréer.

Au sein d'une architecture orientée services, les services communiquent via un système de « couplage faible ». Les composants (aussi appelés « éléments ») sont interconnectés dans un système ou réseau, ce qui leur permet de transmettre des informations ou de coordonner un processus métier, en réduisant la dépendance entre eux. Dans les faits, cela aboutit à la création d'une application.

• Mise sur le marché accélérée et plus grande flexibilité : le caractère réutilisable des services facilite et accélère le regroupement des applications. Les développeurs ne doivent plus repartir de zéro à chaque fois, comme c'est le cas pour les applications monolithiques.
• Utilisation de l'infrastructure existante sur les nouveaux marchés : grâce à l'architecture SOA, les développeurs peuvent plus facilement étendre et mettre à l'échelle les fonctionnalités d'une plateforme ou d'un environnement.
• Coûts réduits grâce à une meilleure agilité et à un développement plus efficace
• Maintenance facilitée : les services étant autonomes et indépendants, ils peuvent être modifiés et mis à jour autant que nécessaire, sans affecter les autres services.
• Évolutivité : comme l'architecture SOA s'adapte à plusieurs services, plateformes et langages de programmation, l'évolutivité est considérablement accrue. En outre, le protocole de communication standardisé limite les interactions entre les clients et les services pour les entreprises, En diminuant le degré d'interaction, les applications peuvent être mises à l'échelle plus facilement et avec moins de pression.
• Fiabilité améliorée : il est plus facile de déboguer des petits services plutôt qu'un long code, ce qui permet de créer des applications plus fiables.
• Grande disponibilité : les fonctions de l'architecture SOA sont à la portée de tous.

Trois rôles fournissent les principaux composants d'une architecture orientée services. 

1. Fournisseur de services

   Un fournisseur de services crée des services web qu'il met à disposition dans un registre de services. Il est responsable des conditions d'utilisation du service.

2. Broker ou registre de services

   Un broker ou registre de services est chargé de fournir les informations sur le service au demandeur. Le broker peut être public ou privé.

3. Demandeur ou consommateur de services

   Le consommateur de services cherche un service dans un broker ou registre de services, puis se connecte à un fournisseur de services pour obtenir le service en question.

Le concept de services introduit par l'architecture orientée services est aujourd'hui un élément essentiel du cloud computing et de la virtualisation dans les solutions de type middleware et microservices.

On confond souvent l'architecture SOA et l'architecture de microservices en raison de leurs similitudes. Toutefois, la principale caractéristique qui les distingue est leur portée : l'architecture SOA est une approche à l'échelle de l'entreprise, tandis que les microservices sont une stratégie de mise en œuvre au sein des équipes de développement des applications.

Ils ne communiquent pas non plus de la même façon avec leurs composants. L'architecture SOA utilise un ESB, alors que les microservices peuvent communiquer entre eux sans état, à l'aide d'API indépendantes de tout langage, ce qui permet aux équipes de développement de choisir leurs outils. Ainsi, les microservices offrent plus de tolérance et de flexibilité.

Il arrive également que l'architecture SOA soit confondue avec le modèle SaaS (Software-as-a-Service). Le SaaS est une forme de cloud computing qui permet de fournir une application cloud aux utilisateurs, avec ses plateformes et son infrastructure sous-jacentes. Dans une architecture SOA, les services web sont parfois distribués sous forme d'applications SaaS. En général, un fournisseur de services cloud (par exemple AWS, Azure ou IBM Cloud) s'occupe de la gestion de l'environnement cloud sur lequel l'application SaaS est hébergée.

Les utilisateurs interagissent avec le logiciel par le biais d'un navigateur web sur leur ordinateur ou leurs appareils mobiles. Ils peuvent également le connecter à d'autres fonctions à l'aide d'API telles que REST ou SOAP.

Grâce aux progrès réalisés en matière de technologies de conteneurs, les microservices constituent désormais la base des applications cloud-native, qui sont des microservices faiblement couplés déployés dans des conteneurs Linux et connectés via des API ou un réseau maillé pour le routage des messages.

Chaque élément met en œuvre une fonctionnalité métier et est développé indépendamment par des équipes DevOps réduites sur la base de workflows comme l'intégration et le déploiement continus (CI/CD). Le développement de logiciels est accéléré, le déploiement automatisé et les mises à jour régulières. Par ailleurs, cela permet de s'affranchir des limites liées au cycle de développement des applications monolithiques.

Grâce à sa gamme de produits Open Source, qui inclut Red Hat^®Enterprise Linux^® et Red Hat OpenShift, Red Hat est en mesure d'accompagner les entreprises qui souhaitent migrer progressivement leur infrastructure et le développement des applications vers l'environnement dynamique et évolutif du cloud computing, en tirant le meilleur parti de l'infrastructure existante.