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

L'architecture orientée services (SOA) est une méthode de développement de logiciels qui utilise des composants logiciels appelés services pour créer des applications métier. Chaque service offre une capacité commerciale, et les services peuvent également communiquer entre eux à travers les plateformes et les langues. Les développeurs utilisent la SOA pour réutiliser des services dans différents systèmes ou combiner plusieurs services indépendants pour effectuer des tâches complexes.

Par exemple, plusieurs processus métier dans une organisation nécessitent la fonctionnalité d'authentification de l'utilisateur. Au lieu de réécrire le code d'authentification pour tous les processus métier, vous pouvez créer un service d'authentification unique et le réutiliser pour toutes les applications. De même, presque tous les systèmes d'une organisation de soins de santé, tels que les systèmes de gestion des patients et les systèmes de dossiers de santé électroniques (DSE), doivent enregistrer les patients. Ces systèmes peuvent appeler un seul service commun pour effectuer la tâche d'enregistrement des patients.

Quels sont les avantages d'une architecture orientée services ?

Une architecture orientée services (SOA) présente plusieurs avantages par rapport aux architectures monolithiques classiques dans lesquelles les processus sont exécutés en tant qu'unité distincte. Voici les principaux avantages de la SOA :

Délais de commercialisation réduits

Les développeurs réutilisent les services pour différents processus métier afin de gagner du temps et de l'argent. Ils peuvent assembler les applications bien plus rapidement avec la SOA qu'en rédigeant du code et en effectuant les intégrations depuis le départ.

Efficacité de maintenance

Il est plus simple de créer, de mettre à jour et de déboguer de petits services que de grands blocs de code dans des applications monolithiques. La modification d'un service dans la SOA n'a aucun impact sur la fonctionnalité globale du processus métier.

Meilleure adaptabilité

La SOA s'adapte mieux aux progrès technologiques. Vous pouvez moderniser vos applications de manière efficace et rentable. Par exemple, les organismes de soins de santé peuvent utiliser les fonctionnalités de systèmes de dossiers de santé électroniques anciens dans des applications cloud récentes.

 

Quels sont les principes de base d'une architecture orientée services ?

Il n'existe pas de directives standard bien définies pour la mise en place d'une architecture orientée services (SOA). Cependant, certains principes de base sont répandus dans toutes les mises en place de la SOA.

Interopérabilité

Chaque service dans une SOA inclut des documents descriptifs qui indiquent la fonctionnalité du service et les conditions générales qui y sont liées. Tout système client peut exécuter un service, peu importe la plateforme sous-jacente ou le langage de programmation. Par exemple, les processus métier peuvent utiliser des services rédigés en C# et en Python. Puisqu'il n'y a pas d'interactions directes, les modifications d'un service n'affectent pas les autres composants qui utilisent ce service.

Couplage faible

Les services d'une SOA doivent être couplés de manière faible et dépendre aussi peu que possible des sources externes comme les modèles de données ou les systèmes d'informations. Ils doivent également être sans état et ne retenir aucune information des sessions ou des transactions passées. Ainsi, si vous modifiez un service, cela n'affectera pas de manière significative les applications client et les autres services qui l'utilisent.

Abstraction

Les clients ou les utilisateurs de service d'une SOA doivent connaître la logique de code ou les détails de mise en œuvre du service. Ils doivent considérer les services comme une boîte noire. Les clients obtiennent les informations nécessaires relatives à la fonction et à l'utilisation du service via des contrats de service et autres documents de description du service.

Granularité

Les services d'une SOA doivent avoir une taille et une portée appropriées, l'idéal étant de regrouper une fonction
métier individuelle par service. Ensuite, les développeurs peuvent utiliser plusieurs services pour créer un service composite destiné à réaliser des opérations complexes.

Quels sont les composants d'une architecture orientée services ?

Une architecture orientée services (SOA) est constituée de quatre composants principaux.

Service

Les services sont les éléments constitutifs de base d'une SOA. Ils peuvent être privés (uniquement disponibles pour les utilisateurs internes d'une organisation) ou publics (disponibles pour tous via Internet). De manière individuelle, chaque service est doté de trois fonctions principales.

Mise en œuvre du service
La mise en œuvre du service est le code qui construit la logique permettant de réaliser la fonction spécifique du service, telle que l'authentification des utilisateurs ou le calcul des factures.

Contrat du service
Le contrat du service définit la nature du service ainsi que les conditions générales qui y sont associées, par exemple les prérequis d'utilisation du service, le coût et la qualité du service offert.
 
Interface du service
Dans une SOA, les autres services ou systèmes communiquent avec un service via son interface. L'interface définit comment vous pouvez invoquer le service pour réaliser des activités ou échanger des données. Elle réduit les dépendances entre les services et le demandeur de service. Par exemple, même les utilisateurs avec pas ou peu de compréhension de la logique de code sous-jacente peuvent utiliser un service via son interface.

Fournisseur du service

Le fournisseur du service crée, maintient et fournit un ou plusieurs services que d'autres personnes peuvent utiliser. Les organisations peuvent créer leurs propres services ou les acheter à des fournisseurs de services tiers.

Consommateur du service

Le consommateur du service demande au fournisseur d'exécuter un service spécifique. Il peut s'agir d'un système complet, d'une application ou d'un autre service. Le contrat du service spécifie les règles que le fournisseur et le consommateur du service doivent respecter lors de leurs interactions. Les fournisseurs et consommateurs de services peuvent appartenir à différents branches, organisations ou même secteurs.

Registre du service

Un registre de service, ou référentiel de service, est un répertoire des services disponibles, accessible via le réseau. Il stocke les documents de description des services émis par les fournisseurs. Les documents de description contiennent des informations relatives au service et à la manière de communiquer avec ce dernier. Les utilisateurs de services peuvent facilement découvrir les services dont ils ont besoin grâce au registre de services.

Comment fonctionne l'architecture orientée services ?

Dans une architecture orientée services (SOA), les services fonctionnent de manière indépendante et fournissent des fonctionnalités ou des échanges de données aux utilisateurs. L'utilisateur demande des informations et envoie les données d'entrée au service. Le service traite les données, réalise la tâche et renvoie une réponse. Par exemple, si une application utilise un service d'autorisation, elle lui transmet le nom d'utilisateur et le mot de passe. Le service vérifie le nom d'utilisateur et le mot de passe et renvoie une réponse appropriée.

Protocoles de communication

Les services communiquent à l'aide de règles établies qui déterminent la transmission de données sur un réseau. Ces règles sont appelées protocoles de communication. Voici quelques protocoles standards de mise en œuvre d'une SOA :

• Le protocole simple d'accès aux objets (SOAP)
• RESTful HTTP
• Apache Thrift
• Apache ActiveMQ
• Le service de messagerie Java (JMS)

Vous pouvez même utiliser plus d'un protocole dans votre mise en œuvre de SOA.

Qu'est-ce qu'un ESB dans une architecture orientée services ?

Un enterprise service bus (ESB) est un logiciel que vous pouvez utiliser lorsque vous communiquez avec un système doté de plusieurs services. Il établit la communication entre les services et leurs utilisateurs, peu importe la technologie.  

Avantages d'un ESB

Un ESB fournit des capacités de communication et de transformation à travers une interface de service réutilisable. Vous pouvez considérer un ESB comme un service centralisé qui achemine les demandes de service vers le service approprié. Il convertit également la demande dans un format accepté par la plateforme sous-jacente et le langage de programmation du service.

Quelles sont les limites de la mise en œuvre d'une architecture orientée services ?

Capacité de mise à l'échelle limitée

La capacité de mise à l'échelle du système est affectée de manière considérable lorsque les services partagent de nombreuses ressources et doivent se coordonner pour réaliser leurs tâches. 

Augmentation des interdépendances

Les systèmes d'architecture orientée services (SOA) peuvent se complexifier avec le temps et développer des interdépendances entre les services. Il peut être difficile de les modifier ou de les déboguer si plusieurs services s'appellent en boucle. Les ressources partagées, telles que les bases de données centralisées, peuvent également ralentir le système.

Point unique de défaillance

Pour les mises en œuvre d'une SOA avec un ESB, l'ESB crée un point unique de défaillance. Il s'agit d'un service centralisé, qui est contraire à l'idée de décentralisation préconisée par la SOA. Les clients et les services ne peuvent pas du tout communiquer entre eux si l'ESB tombe en panne.

Que sont les microservices ?

Une architecture de microservices est constituée de composants logiciels très petits et totalement indépendants, nommés microservices, qui se spécialisent et se concentrent sur une seule tâche. Les microservices communiquent via des API, qui sont des règles créées par les développeurs pour permettre aux autres systèmes logiciels de communiquer avec leur microservice.

Le style d'architecture de microservices est plus adapté aux environnements de cloud computing modernes. En règle générale, ils opèrent sous la forme de conteneurs, des unités logicielles indépendantes qui regroupent le code avec toutes ses dépendances.

Avantages des microservices

Les microservices présentent des caractéristiques natives cloud : ils sont individuellement évolutifs, rapides, portables et indépendants des plateformes. Ils sont également dissociés, ce qui signifie qu'ils n'ont que peu ou pas de dépendances avec d'autres microservices. Pour ce faire, les microservices bénéficient d'un accès local à toutes les données nécessaires plutôt que d'un accès à distance à des données centralisées que d'autres systèmes consultent et utilisent également. Cela engendre une duplication de données, compensée par les performances et l'agilité des microservices.

Les SOA comparées aux microservices

L'architecture de microservices est une évolution du style d'architecture de SOA. Les microservices comblent les lacunes des SOA afin de rendre le logiciel plus compatible avec les environnements d'entreprise cloud modernes. Ils sont précis et favorisent la duplication des données plutôt que le partage des données. Cela les rend totalement indépendants grâce à leurs propres protocoles de communication qui sont présentés via des API légères. La tâche des utilisateurs est principalement d'utiliser le microservice via son API, ce qui élimine ainsi le besoin d'ESB centralisé.

Comment AWS participe-t-il à la mise en œuvre des microservices ?

AWS est le service parfait pour la conception d'applications modernes avec des schémas d'architecture modulaires, des modèles opérationnels sans serveur et des processus de développement agiles. Il offre la plateforme la plus complète pour concevoir des microservices hautement disponibles afin d'alimenter des applications modernes de toute portée et échelle. Par exemple, vous pouvez :

• Créer, isoler et exécuter des microservices sécurisés dans des conteneurs gérés afin de simplifier les opérations et de réduire les frais de gestion.
• Utiliser AWS Lambda afin d'exécuter vos microservices sans allouer et gérer des serveurs.
• Choisir parmi 15 bases de données AWS sur mesure, relationnelles et non relationnelles, pour prendre en charge l'architecture de microservices.
• Facilement surveiller et contrôler les microservices exécutés sur AWS avec AWS App Mesh.
• Surveiller les interactions complexes des microservices et régler les problèmes qui y sont associés, avec AWS X-Ray.

Les microservices sur AWS vous permettent d'innover plus rapidement, de réduire les risques, d'accélérer les délais de commercialisation et de réduire votre coût total de possession. Démarrez avec la SOA et les microservices sur AWS en créant un compte AWS dès aujourd'hui.

Prochaines étapes sur AWS

Parcourir les ressources supplémentaires liées au produit
En savoir plus sur l'architecture orientée services 
Créer gratuitement un compte

Obtenez un accès instantané à l'offre gratuite AWS. 

S'inscrire 
Commencer à créer sur la console

Commencez à créer avec AWS dans la Console de gestion AWS.

Se connecter