Qu’est-ce qu’une architecture orientée services (SOA) ?

La SOA simplifie la vie des développeurs d’applications, qui devaient autrefois redévelopper ou dupliquer les fonctions existantes et savoir comment assurer la connectivité ou l’interopérabilité avec les fonctions existantes.

Chaque service d’une SOA comporte le code et les données nécessaires pour exécuter une fonction métier complète et discrète (par exemple, vérifier la solvabilité d’un client, calculer les mensualités d’un prêt ou traiter une demande de prêt hypothécaire). Les interfaces de service fournissent un couplage lâche. Cela signifie qu’elles peuvent être appelées même si elles possèdent peu ou pas de connaissances sur l’implémentation du service en dessous, ce qui réduit les dépendances entre les applications.

Cette interface est un contrat de service entre le fournisseur de services et le consommateur de services. Les applications derrière l’interface de service peuvent être écrites en Java, Microsoft .Net, Cobol ou tout autre langage de programmation, proposées par un fournisseur sous forme d’applications logicielles empaquetées (par exemple, SAP), SaaS (par exemple, Salesforce CRM), ou open source.

Les interfaces de service sont fréquemment définies à l’aide du langage WSDL (Web Service Definition Language), une structure de balises standard basée sur xml (Extensible Markup Language).

Les services sont exposés en utilisant des protocoles réseau standard, comme le protocole SOAP (Simple Object Access Protocol)/HTTP ou Restful HTTP (JSON/HTTP), pour envoyer des demandes de lecture ou de modification de données. La gouvernance des services contrôle le cycle de vie pendant le développement et, à l’étape appropriée, les services sont publiés dans un registre qui permet aux développeurs de les trouver rapidement et de les réutiliser pour assembler de nouvelles applications ou de nouveaux processus métier.

Ces services peuvent être créés de toutes pièces, mais ils sont souvent créés en exposant les fonctions des systèmes hérités en tant qu’interfaces de service.

En ce sens, la SOA représente une étape importante dans l’évolution du développement et de l’intégration des applications au cours des dernières décennies. Avant l’apparition de la SOA à la fin des années 1990, la connexion d’une application aux données ou aux fonctions hébergées dans un autre système nécessitait une intégration point à point complexe, une intégration que les développeurs devaient recréer, en tout ou en partie, pour chaque nouveau projet de développement. L’exposition de ces fonctions via les services SOA a permis au développeur de réutiliser simplement la capacité existante et de se connecter via l’architecture SOA ESB (voir ci-dessous).

Bien que la SOA et l’architecture de microservices, plus récente, partagent de nombreux mots en commun (notamment « service » et « architecture »), elles ne sont que faiblement liées et, en réalité, fonctionnent à des échelles différentes, comme nous le verrons plus loin dans cet article.

Un ESB, ou Enterprise Service Bus, est un modèle d’architecture dans lequel un composant logiciel centralisé assure des intégrations entre les applications. Il s’occupe des transformations des modèles de données, de la connectivité et de la messagerie, du routage, de la conversion des protocoles de communication et potentiellement de la composition de plusieurs requêtes.

L’ESB peut rendre ces intégrations et transformations disponibles en tant qu’interface de service à réutiliser dans de nouvelles applications. Le modèle ESB est généralement mis en œuvre à l’aide d’une exécution et d’un ensemble d’outils d’intégration spécialement conçus pour garantir la meilleure productivité possible.

Il est possible de mettre en œuvre une SOA sans ESB, mais cela reviendrait à disposer simplement de plusieurs services. Chaque propriétaire d’application devrait se connecter directement au service dont il a besoin et effectuer les transformations de données nécessaires pour répondre à chacune des interfaces de service.

Cela représente une charge de travail importante (même si les interfaces sont réutilisables) et crée des défis de maintenance significatifs pour la suite, car chaque connexion s’effectue point-à-point. En fait, les ESB ont fini par être considérés comme un élément de facto constitutif de toute mise en œuvre de la SOA, à tel point que les deux termes sont parfois utilisés comme des synonymes, ce qui crée une certaine confusion.

Par rapport aux architectures précédentes, la SOA offrait des avantages significatifs à l’entreprise :

• Une plus grande agilité de l’entreprise, un délai de mise sur le marché plus rapide : la réutilisation est essentielle. L’efficacité de l’assemblage d’applications à partir de services réutilisables, c’est-à-dire de blocs fonctionnels, au lieu de les réécrire et de les réintégrer à chaque nouveau projet de développement, permet aux développeurs de créer des applications beaucoup plus rapidement pour répondre aux nouvelles opportunités commerciales.
  L’approche architecturale orientée services prend en charge les scénarios d’intégration d’applications, d’intégration de données et d’automatisation des workflows sous forme d’orchestration des services. Cela accélère la conception et le développement de logiciels en permettant aux développeurs de consacrer considérablement moins de temps à l’intégration et davantage de temps au déploiement et à l’amélioration de leurs applications.
• Capacité d’utiliser les fonctions héritées sur de nouveaux marchés : une SOA bien conçue permet aux développeurs de prendre facilement des fonctions « verrouillées » sur une plateforme ou un environnement informatique et de les étendre à de nouveaux environnements et marchés. Par exemple, de nombreuses entreprises ont utilisé la SOA pour exposer les fonctions des systèmes financiers mainframe à de nouvelles applications Web. Cela permet à leurs clients de se servir eux-mêmes des processus et des informations auparavant accessibles uniquement par le biais d’une interaction directe avec les employés ou les partenaires commerciaux de l’entreprise.
• Amélioration de la collaboration entre les entreprises et les services informatiques : dans une SOA, les services peuvent être définis en termes professionnels (par exemple, « générer un devis d’assurance » ou « calculer le ROI des équipements »). Cela permet aux analystes métier de travailler plus efficacement avec les développeurs sur des informations importantes, telles que la portée d’un processus métier défini en utilisant des services ou les implications métier de la modification d’un processus, qui peuvent conduire à un meilleur résultat.

En 2010, les mises en œuvre de la SOA explosaient à plein régime dans les entreprises de premier plan de pratiquement tous les secteurs. Par exemple :

Delaware Electric s’est tourné vers une SOA pour intégrer des systèmes qui ne communiquaient pas entre eux, ce qui a permis d’améliorer l’efficacité du développement et de maintenir la solvabilité de l’entreprise durant un gel des tarifs d’électricité imposé par l’État, qui a duré cinq ans.

Cisco a adopté la SOA pour s’assurer que son expérience de commande était cohérente pour tous les produits et canaux en exposant les processus de commande à des services que les divisions, les acquisitions et les partenaires commerciaux de Cisco peuvent intégrer à leurs sites Web.

Indépendance Blue Cross (IBC), à Philadelphie, a mis en place une SOA pour s’assurer que les différents acteurs traitant les données des patients (agents du service client IBC, cabinets médicaux, utilisateurs du site web de l’IBC) travaillaient avec la même source de données (une source d’information unique).

Les experts ont noirci quelques milliers de pages imprimées et numériques pour comparer la SOA et les microservices, et définir les subtilités de leur relation les uns aux autres. Dans le cadre de cet article, les principales différences entre les deux sont le couplage des composants et le champ d’application :

La SOA est un style architectural d’intégration et un concept à l’échelle de l’entreprise. Il permet d’exposer les applications existantes sur des interfaces faiblement couplées, chacune correspondant à une fonction métier qui permet aux applications d’une partie d’une entreprise étendue de réutiliser des fonctions dans d’autres applications.

L’architecture de microservices est un style d’architecture d’application et un concept à l’échelle d’application. Elle permet de diviser les composants internes d’une seule application en petits morceaux qui peuvent être modifiés, mis à l’échelle et gérés de manière indépendante. Elle ne définit pas la manière dont les applications communiquent entre elles, ce qui nous ramène au champ d’application des interfaces de service fournies par l’architecture SOA.

L’architecture de microservices est apparue et a pris de l’ampleur avec l’essor de la virtualisation, du cloud computing, des pratiques de développement Agile et du DevOps. La plupart des avantages des microservices dans ces contextes découlent du découplage des composants, ce qui simplifie et améliore les éléments suivants :

• Agilité et productivité des développeurs : les microservices permettent aux développeurs d’intégrer de nouvelles technologies dans une partie de l’application sans affecter le reste de l’application. Tout composant peut être modifié, testé et déployé indépendamment des autres, ce qui accélère les cycles d’itération.
• Évolutivité : les microservices tirent le meilleur parti de l’évolutivité cloud. Chaque composant peut être redimensionné indépendamment des autres pour répondre le plus rapidement possible aux exigences des workloads et utiliser les ressources informatiques de la manière la plus efficace qui soit.
• Résilience : encore une fois, grâce au découplage, la défaillance d’un microservice n’a pas d’incidence sur les autres. Et chaque microservice peut répondre à ses propres exigences en matière de disponibilité sans que les autres composants ou l’ensemble de l’application ne soient soumis aux exigences communes les plus strictes.

Pour une analyse plus approfondie des différences entre la SOA et les microservices, consultez l’article SOA et microservices : quelle différence ?

Tout comme l’architecture de microservices a le potentiel d’améliorer l’agilité, l’évolutivité et la résilience de la conception d’application, ces mêmes techniques peuvent également être appliquées à l’intégration.

Ce point est important car, au fil du temps, le modèle ESB fortement centralisé et son équipe centralisée de spécialistes de l’intégration peuvent devenir un goulot d’étranglement. En empruntant les principes des microservices, nous pouvons potentiellement décomposer l’ESB en une intégration décentralisée plus fine. C’est l’un des principes fondamentaux de l’intégration agile.