menu icon

Architecture orientée services

Explorez l'architecture orientée services, une étape importante dans l'évolution du développement et de l'intégration des applications.

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

Un architecture orientée services, définit un moyen de rendre les composants logiciels réutilisables via des interfaces de service. Ces interfaces utilisent des normes de communication communes leur permettant d'être rapidement incorporées à de nouvelles applications sans qu'il soit nécessaire d'effectuer une intégration approfondie à chaque fois.

Chaque service d'une architecture orientée services représente le code et les intégrations de données nécessaires à l'exécution d'une fonction métier complète discrète (par exemple, la vérification du crédit d'un client, le calcul d'un paiement mensuel de prêt ou le traitement d'une demande de prêt hypothécaire). Les interfaces de service fournissent un couplage lâche, ce qui signifie qu'elles peuvent être appelées même si vous ne savez pas comment l'intégration est implémentée. Les services sont exposés à l'aide de protocoles de réseau standard, tels que SOAP (Simple Object Access Protocol)/HTTP ou JSON/HTTP, pour envoyer des demandes de lecture ou de modification de données. Les services sont publiés d'une manière qui permet aux développeurs de les trouver rapidement et de les réutiliser pour assembler de nouvelles applications.

Ces services peuvent être créés à partir de zéro, mais sont généralement créés en exposant les fonctions des anciens systèmes d'enregistrement en tant qu'interfaces de service.

Ainsi, l'architecture orientée services 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'émergence de l'architecture orientée services à la fin des années 1990, la connexion d'une application à des données ou à des fonctionnalités 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 partie ou en totalité, pour chaque nouveau projet de développement. L'exposition de ces fonctions via l'architecture élimine la nécessité de recréer l'intégration en profondeur à chaque fois.

Notez que même si l'architecture orientée services et les architecture de microservices plus récentes ont de nombreux mots en commun, elles ne sont que faiblement liées et, en fait, fonctionnent à des échelles différentes, comme nous le verrons plus loin dans cet article.

Qu'est-ce qu'un ESB ?

Un ESB, ou bus de service d'entreprise, est un modèle dans lequel un composant centralisé effectue l'intégration aux systèmes dorsaux et rend ensuite ces intégrations disponibles sous forme d'interfaces de service. Il effectue la traduction des modèles de données, la connectivité en profondeur, le routage et, éventuellement, la composition de demandes multiples, et il les rend disponibles sous la forme d'une interface de service unique en vue de leur réutilisation par de nouvelles applications. Le modèle ESB est généralement mis en œuvre à l'aide d'un moteur d'exécution et d'outils d'intégration spécialement conçus, qui sont bien adaptés aux fonctionnalités mentionnées précédemment et garantissent la meilleure productivité possible.

En théorie, vous pourriez implémenter une architecture orientée services sans un ESB, mais les propriétaires d'applications doivent chacun trouver leur propre moyen d'exposer les interfaces de service, ce qui représente un travail considérable (même si les interfaces sont finalement réutilisables) et crée un problème important en matière de maintenance à l'avenir. En fait, les ESB ont fini par être considérés comme un élément de facto de toute implémentation de l'architecture orientée services, au point que les deux termes sont parfois utilisés comme synonymes, ce qui crée une certaine confusion.

Pour en savoir plus sur les ESB, consultez en « Présentation d'ESB (Enterprise Service Bus) ».

Avantages de l'architecture orientée services

Par rapport aux architectures qui l'ont précédée, cette architecture offre des avantages considérables à l'entreprise :

  • Agilité commerciale accrue, réduction du délai d'accès au marché : l'efficacité de l'assemblage d'applications à partir d'interfaces de services réutilisables, plutôt que la réécriture et la réintégration à chaque nouveau projet de développement, permet aux développeurs de créer des applications beaucoup plus rapidement pour réponse aux nouvelles opportunités commerciales.
  • Capacité de tirer parti de la fonctionnalité existante sur de nouveaux marchés : une architecture orientée services bien conçue permet aux développeurs de prendre facilement une fonctionnalité « verrouillée » dans une plateforme ou un environnement informatique et de l'étendre à de nouveaux environnements et marchés. Par exemple, la plupart des entreprises utilisent l'architecture orientée services pour exposer sur le Web les fonctionnalités de systèmes financiers basés sur des mainframes, permettant ainsi à leurs clients d'accéder à des processus et à des informations qui n'étaient auparavant accessibles que par une interaction directe avec les employés ou les partenaires commerciaux de l'entreprise.
  • Amélioration de la collaboration entre l'entreprise et les services informatiques : dans une architecture orientée services, les services peuvent être définis en termes commerciaux (par exemple, « générer un devis d'assurance » ou « calculer le retour sur investissement d'un bien d'équipement »). Ainsi, les analystes métier peuvent travailler plus efficacement avec les développeurs sur des informations importantes, telles que la portée d'un processus d'entreprise défini par un service ou les implications commerciales de la modification d'un processus, qui peuvent produire un meilleur résultat.

Exemples d'architectures orientées services

En 2010, l'implémentation de l'architecture orientée services battait son plein dans les grandes entreprises de presque tous les secteurs. Exemples :

  • Delaware Electric s'est tourné vers cette architecture pour intégrer des systèmes qui, auparavant, ne communiquaient pas entre eux, ce qui a permis à l'entreprise de gagner en efficacité et de rester solvable pendant les cinq années de gel des tarifs d'électricité imposé par l'État.
  • Cisco l'a adoptée pour que l'expérience de commande de ses produits soit cohérente pour l'ensemble des produits et des canaux, en exposant les processus de commande sous forme de services que les divisions, les acquisitions et les partenaires commerciaux de Cisco pouvaient intégrer à leurs sites Web.
  • Independence Blue Cross (IBC) de Philadelphie a implémenté une architecture orientée services pour que les différents acteurs traitant les données des patients (agents du service clientèle d'IBC, cabinets médicaux, utilisateurs du site Web d'IBC) travaillent avec la même source de données (une « version unique de la vérité »).

L'architecture orientée services et microservices

Des experts ont produit de milliers de pages imprimées et numériques pour comparer l'architecture orientée services et les microservices et définir les subtilités de leur relation. Aux fins du présent article, les principales différences entre les deux sont le couplage des composants et le champ d'application :

  • L'architecture orientée services est un concept qui s'applique à l'ensemble de l'entreprise. Elle permet d'exposer les applications existantes par le biais d'interfaces faiblement couplées, chacune correspondant à une fonction métier, ce qui permet aux applications d'une partie d'une entreprise étendue de réutiliser les fonctionnalités dans d'autres applications.
  • L'architecture de microservices est un concept qui s'applique à l'application. Il permet de diviser les éléments internes d'une application unique en petits morceaux qui peuvent être modifiés, mis à l'échelle et administrés de manière indépendante. Elle ne définit pas la manière dont les applications communiquent entre elles ; pour cela, nous revenons à l'échelle entreprise des interfaces de service fournies par l'architecture orientée services.

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

  • Agilité et productivité du développeur : les microservices permettent aux développeurs d'intégrer de nouvelles technologies à une partie de l'application sans communication avec 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 peuvent tirer le meilleur parti de l'évolutivité du cloud : chaque composant peut être mis à l'échelle indépendamment des autres pour répondre le plus rapidement possible aux demandes de charge de travail et utiliser de manière optimale les ressources informatiques.
  • Résilience : là encore, grâce au découplage, la défaillance d'un microservice n'a pas d'incidence sur les autres. En outre, chaque microservice peut fonctionner conformément à ses propres exigences de disponibilité sans soumettre les autres composants ou l'ensemble de l'application aux exigences de disponibilité communes les plus élevées.

Pour un examen plus approfondi des différences entre l'architecture orientée services et les microservices, consultez « Architecture orientée services et Microservices : quelle est la différence ? »

De la même manière que l'architecture microservices peut apporter des améliorations en termes d'agilité, d'évolutivité et de résilience à la conception des applications, ces mêmes techniques peuvent être également appliquées à l'intégration. C'est important car, au fil du temps, le modèle ESB fortement centralisé et l'équipe centralisée de spécialistes de l'intégration qui lui est associée peuvent devenir un goulot d'étranglement. En s'inspirant des principes des microservices, nous pouvons potentiellement décomposer ESB en intégrations à plus fine granulité et décentralisées. Il s'agit de l'un des principales promesses de l'intégration agile.

L'architecture orientée services et IBM Cloud

Alors que votre entreprise fait évoluer son infrastructure informatique vers une approche de cloud hybride , il est fort probable que vous transformiez diverses charges de travail, y compris celles basées sur l'architecture orientée services, en modèles de déploiement de cloud plus légers et plus flexibles. IBM est l'un des pionniers de l'architecture SOA, et les offres et services IBM Cloud peuvent tirer parti de votre architecture orientée services actuelle et l'étendre au Cloud.

Pour aller plus loin :

L'architecture orientée services OA permet de rendre les services consommables dans différents canaux, quel que soit l'endroit où se trouve l'application ou la base de données centrale, ce donne la possibilité à votre entreprise à tirer parti de ses investissements lorsqu'elle modernise les applications dans le cadre de sa transition vers le cloud.

Démarrez en créant un compte IBM Cloud dès aujourd'hui.