L'architecture SOA définit un moyen de rendre les composants logiciels réutilisables et interopérables grâce à des interfaces de services. Les services utilisent des normes d'interface communes et un modèle architectural, de sorte qu'ils peuvent être rapidement incorporés dans de nouvelles applications.  Cela libère le développeur d'applications qui, auparavant, redéveloppait ou dupliquait la fonctionnalité existante ou devait savoir comment se connecter ou assurer l'interopérabilité avec les fonctions existantes.

Chaque service d'une architecture SOA comprend le code et les données nécessaires à l'exécution d'une fonction métier complète et distincte (par exemple, la vérification de la solvabilité d'un client, le calcul d'une mensualité de prêt ou le traitement d'une demande de prêt immobilier). Les interfaces de service fournissent un couplage lâche, ce qui signifie qu'elles peuvent être appelées sans savoir comment le service est mis en œuvre 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 service. Les applications derrière  l'interface de service peuvent être écrites en Java, Microsoft .Net, Cobol ou tout autre langage de programmation. Elles peuvent être fournies sous forme d'applications logicielles intégrées par un fournisseur (par exemple SAP), d'applications SaaS (par exemple Salesforce CRM) ou obtenues sous forme d'applications open source.  Les interfaces de service sont souvent définies à l'aide du langage de définition de service Web (WSDL), qui est une structure de balises standard basée sur le langage XML (Extensible Markup Language).  

Les services sont exposés à l'aide de protocoles réseau standard, tels que SOAP (protocole d'accès simple à un objet)/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 du développement et, au stade approprié, 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 d'entreprise.

Ces services peuvent être créés complètement, mais ils sont souvent créés en exposant les fonctions des systèmes d'enregistrement existants sous forme d'interfaces de service.

Ainsi, 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 à 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 par le biais des services SOA a permis au développeur de simplement réutiliser la capacité existante et de se connecter par le biais de l' architecture ESB SOA (voir ci-dessous).

Il convient de noter que bien que l'architecture SOA et l'architecture de microservices , plus récente, aient de nombreux mots en commun (par exemple, « service » et « architecture »), elles ne sont que vaguement liées et opèrent en réalité à des échelles différentes, comme nous le verrons plus loin dans cet article.

Un ESB (Enterprise Service Bus), ou bus de service d'entreprise, est un modèle architectural dans lequel un composant logiciel centralisé réalise des intégrations entre des applications.  Il effectue des transformations de modèles de données, gère la connectivité/messagerie, effectue le routage, convertit les protocoles de communication et gère éventuellement la composition de demandes multiples. L' EBS peut rendre ces intégrations et transformations disponibles en tant qu'interface de service pour être réutilisées par de nouvelles applications. Le modèle ESB est généralement implémenté à l'aide d'un environnement d'exécution et d'un ensemble d'outils d'intégration spécialement conçus pour garantir la meilleure productivité possible.

Il est possible d'implémenter une architecture SOA sans ESB, mais cela reviendrait à n'avoir qu'un ensemble de 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 respecter chacune des interfaces de service. Cela représente beaucoup de travail (même si les interfaces sont réutilisables) et crée des problèmes de maintenance importants pour l'avenir, car chaque connexion est de type point à point.  En fait, les ESB ont fini par être considérés comme un élément de facto d'une implémentation SOA , au point que les deux termes sont parfois utilisés comme synonymes, ce qui crée une certaine confusion.

En savoir plus sur les ESB

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

• Entreprise plus agile, mise sur le marché plus rapide : la réutilisabilité est essentielle.  L'efficacité de l'assemblage d'applications à partir de services réutilisables, c'est à dire de blocs fonctionnels, plutôt que leur réécriture et leur réintégration à chaque nouveau projet de développement, permet aux développeurs de créer des applications beaucoup plus rapidement en réponse à de nouvelles opportunités commerciales. L'approche architecturale orientée services prend en charge des scénarios d'intégration d'applications, d'intégration de données et d'automatisation des processus métier ou des flux de travail de type orchestration de services.  Cela accélère la conception et le développement de logiciels en permettant aux développeurs de consacrer beaucoup moins de temps à l'intégration et beaucoup plus à la distribution et à l'amélioration de leurs applications. 
  
  
• Capacité à exploiter les fonctionnalités existantes sur de nouveaux marchés : une architecture SOA bien conçue permet aux développeurs de prendre facilement des fonctionnalités « verrouillées » dans une plateforme ou un environnement informatique et de les étendre à de nouveaux environnements et marchés. Par exemple, de nombreuses entreprises utilisent l'architecture SOA pour exposer la fonctionnalité de systèmes financiers basés sur des grands systèmes à de nouvelles applications Web, 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 l'informatique : dans une architecture SOA, 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 métier défini à l'aide de services ou les implications métier de la modification d'un processus, qui peuvent produire un meilleur résultat.

En 2010, les implémentations SOA étaient en plein essor dans les grandes entreprises dans presque tous les secteurs d'activité. Par exemple :

• Delaware Electric s'est tourné vers une architecture SOA pour intégrer des systèmes qui, auparavant, ne communiquaient pas entre eux. Cela a permis à l'organisation de réaliser des gains d'efficacité de développement et de rester solvable pendant les cinq années de gel des tarifs d'électricité imposé par l'État.
  
  
• Cisco a adopté une architecture SOA pour s'assurer que l'expérience de commande de ses produits était cohérente pour tous les produits et canaux, en exposant les processus de commande comme des services que les divisions, les acquisitions et les partenaires commerciaux de Cisco pouvaient intégrer dans leurs sites Web.
  
  
• Independence Blue Cross (IBC) de Philadelphie a mis en place une architecture SOA pour que les différents acteurs traitant les données des patients (agents du service client d'IBC, cabinets médicaux, utilisateurs du site Web d'IBC) travaillent avec la même source de données (une « source unique de données de référence »).

Des spécialistes ont rempli quelques milliers de pages papier et numériques pour comparer l'architecture SOA et les microservices et définir les subtilités de leurs relations mutuelles. Les principales différences reprises dans cet article sont le couplage des composants et le champ d'application :

• SOA est un type d'architecture d'intégration et un concept d'entreprise. L'architecture SOA permet aux applications existantes d'être exposées par le biais d'interfaces faiblement couplées, chacune correspondant à une fonction métier, ce qui permet aux applications d'une partie de l'entreprise étendue de réutiliser la fonctionnalité d'autres applications.
  
  
• Une architecture de microservices est un type d'architecture d'application et un concept d'application. Elle permet de diviser les éléments internes d'une application unique en petites parties qui peuvent être modifiées, mises à l'échelle et administrées de manière indépendante. Elle ne définit pas la manière dont les applications communiquent entre elles ; pour cela, il faut revenir à l'échelle entreprise des interfaces de service fournies par SOA.

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

• L'Agilité et la productivité des développeurs : les microservices permettent aux développeurs d'intégrer de nouvelles technologies à une partie de l'application sans en affecter le reste. Tout composant peut être modifié, testé et déployé indépendamment des autres, ce qui accélère les cycles d'itération.
  
  
• L'évolutivité : les microservices peuvent tirer le meilleur parti de l'évolutivité du cloud, chaque composant pouvant être mis à l'échelle indépendamment des autres pour répondre le plus rapidement possible aux demandes de charge de travail et utiliser les ressources informatiques le plus efficacement possible.
  
  
• La résilience : là encore, grâce au découplage, la défaillance d'un service n'a pas d'incidence sur les autres. En outre, chaque microservice peut répondre à ses propres exigences de disponibilité sans que les autres composants ou l'ensemble de l'application ne soient soumis aux plus grandes exigences de disponibilité communes.

Pour un examen plus approfondi des différences entre une architecture SOA et les microservices, consultez la rubrique « SOA et microservices : quelle est la différence ? »

À l'instar d'une architecture de microservices qui a le potentiel d'apporter des améliorations en termes d'agilité, d'évolutivité et de résilience à la conception des applications, ces mêmes techniques peuvent être appliquées à l'intégration. Cela 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 un ESB en intégrations plus fines et décentralisées. C'est l'un des principes fondamentaux de l'intégration Agile.