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

L'architecture orientée services (SOA) est apparue au début de ce siècle comme une évolution de l'informatique distribuée. Avant SOA, les services étaient considérés comme le résultat final du processus de développement d'applications. Dans SOA, l'application elle-même est composée de services. Les services peuvent être fournis individuellement ou combinés en tant que composants dans un service composite plus vaste.

Les services interagissent sur le fil en utilisant un protocole tel que REST ou SOAP (Simple Object Access Protocol). Les services sont faiblement couplés , ce qui signifie que l'interface de service est indépendante de l'implémentation sous-jacente. Les développeurs ou intégrateurs système peuvent composer un ou plusieurs services dans une application sans nécessairement savoir comment chaque service est implémenté.

Cet article est un aperçu de Java SOA et des principales caractéristiques d'une architecture orientée services implémentée à l'aide de services Web SOAP. Je vais également comparer brièvement SOA et microservices et discuter de la différence entre les services Web RESTful et SOAP en Java.

SOA et services Web

SOA et services Web sont souvent confondus, mais ce n'est pas la même chose. SOA est une architecture qui permet aux développeurs de combiner plusieurs services d'application en un service composite plus grand. SOA peut être implémentée à l'aide de services Web SOAP ou d'API REST, ou parfois d'une combinaison des deux. Il est important de comprendre que dans SOA, un service est une ressource disponible à distance qui peut répondre aux demandes. Un service Web est implémenté à l'aide de protocoles spécifiques.

Pourquoi une architecture orientée services?

SOA répond à trois défis d'entreprise courants:

  • Répondez rapidement aux changements commerciaux.
  • Tirez parti des investissements d'infrastructure existants.
  • Soutenir de nouveaux canaux d'interaction avec les clients, partenaires et fournisseurs.

L'infrastructure d'entreprise est hétérogène entre les systèmes d'exploitation, les applications, les logiciels système et l'infrastructure d'application. En conséquence, de nombreux systèmes d'entreprise sont constitués d'applications complexes et incohérentes offrant une gamme de services interdépendants. Les applications existantes exécutant les processus métier actuels sont essentielles, donc partir de zéro ou les modifier est une proposition délicate. Mais les entreprises doivent être en mesure de modifier et d'étendre l'infrastructure technique pour répondre aux demandes commerciales.

SOA et microservices

Microservices est un style architectural évolué à partir de SOA. Les deux sont des architectures distribuées et offrent tous deux un paradigme découplé. Alors que l'architecture orientée services est plus lourde en infrastructure, les microservices offrent un style de développement plus flexible et plus léger. Il y a des avantages et des inconvénients aux deux, et les deux sont largement utilisés. De manière générale, la SOA est plus fréquemment mise en œuvre ou maintenue par des entreprises établies qui ont les ressources nécessaires pour prendre en charge plus de formalité. Les microservices font souvent appel aux organisations nouvelles ou en croissance qui nécessitent de l'agilité.

Par rapport à une architecture monolithique, la nature faiblement couplée de la SOA rend relativement transparente le branchement de nouveaux services ou la mise à niveau de services existants pour de nouvelles exigences commerciales. Il offre également la possibilité de rendre les services consommables sur différents canaux et d'exposer les applications héritées en tant que services, protégeant ainsi les investissements dans l'infrastructure.

Comme ils sont faiblement couplés, les composants SOA peuvent être modifiés avec un impact minimal sur les autres composants. Les composants peuvent également être ajoutés à l'architecture de manière standardisée et ils peuvent être mis à l'échelle pour répondre à la charge.

À titre d'exemple, considérez comment une entreprise peut utiliser un ensemble d'applications existantes pour créer une nouvelle application de chaîne d'approvisionnement composite. Alors que les applications existantes sont hétérogènes et réparties sur divers systèmes, leurs fonctionnalités sont exposées et accessibles à l'aide d'interfaces standard.

Matthew Tyson

Principales caractéristiques de SOA

La SOA peut être aussi simple qu'un composant unique consommant des services fournis par un autre composant ou aussi sophistiquée qu'une gamme de composants interagissant via un bus de services d'entreprise tel que l'ESB de MuleSoft. Quelle que soit l'échelle, la clé d'une implémentation SOA réussie est d'utiliser le moins de complexité possible pour atteindre vos objectifs. Votre première et dernière question devrait toujours être: cette conception répond-elle à nos exigences commerciales?

Indépendamment de l'échelle ou de la complexité, le modèle d'une architecture orientée services est plus ou moins le même:

  • Les fournisseurs de services exposent les points de terminaison et décrivent les actions disponibles sur chaque point de terminaison.
  • Les consommateurs de services émettent des demandes et consomment des réponses.
  • Les fournisseurs de services génèrent des messages pour traiter les demandes.

Implémentation d'une architecture orientée services

Pour implémenter SOA, vous commencez par l'architecture de service de base, puis fournissez l'infrastructure, c'est-à-dire les protocoles et autres outils qui permettent la communication et l'interopérabilité. La figure 2 montre un diagramme d'une architecture de service typique.

Matthew Tyson

Dans ce diagramme, trois consommateurs invoquent des services en envoyant des messages à un bus de services d'entreprise, qui transforme et achemine les messages vers une implémentation de service appropriée. Un moteur de règles métier incorpore des règles métier dans un service ou entre les services. Une couche de gestion des services gère des activités telles que l'audit, la facturation et la journalisation.

Les composants de cette architecture sont faiblement couplés, de sorte qu'ils peuvent être désactivés ou mis à jour avec un impact relativement minime sur l'application dans son ensemble. Cela donne à l'entreprise la flexibilité d'ajouter ou de mettre à jour des processus métier selon les besoins. Dans la plupart des cas, les modifications apportées aux services individuels ne devraient pas avoir une incidence importante sur les autres services.

Services Web SOAP vs RESTful

Il est possible d'adopter le style SOA et de l'implémenter avec REST, par exemple à l'aide de l'API JAX-RS ou de Spring Boot Actuator, mais cette discussion est hors de portée de cet article. Voir «SOAP vs REST vs JSON» pour une comparaison utile des services Web SOAP vs RESTful. Il existe également un chevauchement entre les services Web RESTful et le style plus léger associé aux microservices.

Services Web basés sur SOAP

Les services Web mis en œuvre à l'aide de SOAP sont toujours plus rigides qu'une implémentation de services Web ou de microservices RESTful, mais beaucoup plus flexibles que les premiers jours de la SOA. Ici, nous allons simplement examiner les protocoles de haut niveau requis pour les services Web SOAP.

SOAP, WSDL et XSD

SOAP, WSDL et XSD sont l'infrastructure fondamentale d'une implémentation de service Web basée sur SOAP. WSDL est utilisé pour décrire le service et SOAP est la couche de transport pour l'envoi de messages entre les consommateurs de services et les fournisseurs. Les services communiquent avec des messages définis formellement à l'aide du schéma XML (XSD). Vous pouvez considérer WSDL comme l'interface du service (vaguement analogue à une interface Java). L'implémentation se fait dans les classes Java et la communication à travers le réseau se fait via SOAP. Fonctionnellement, un consommateur recherchait un service, obtiendrait le WSDL pour ce service, puis invoquerait le service à l'aide de SOAP.

Sécurité des services Web

La spécification WS-I Basic Profile 2.0 traite de la sécurité des messages. Cette spécification se concentre sur l'échange d'informations d'identification, l'intégrité des messages et la confidentialité des messages.

Découverte de services Web

Autrefois la pierre angulaire de la découverte de services Web, l'UDDI (Universal Description, Definition and Integration) est passé dans l'histoire. Aujourd'hui, il est courant d'exposer un service Web basé sur SOAP comme vous le feriez pour n'importe quel autre service, via une URL de point de terminaison. À titre d'exemple, vous pouvez utiliser le service JAX-WS Interface Endpoint et ses @WebServiceet @WebMethodannotations.

Création et déploiement de services Web

Les développeurs Java disposent de plusieurs options pour créer et déployer des services Web SOAP, notamment Apache Axis2 et Spring-WS; cependant, le standard Java est JAX-WS, l'API Java pour les services Web XML. L'idée principale derrière JAX-WS est de créer des classes Java et de les annoter pour créer les artefacts requis. Sous le capot, JAX-WS utilise plusieurs packages Java, y compris JAXB, une bibliothèque à usage général pour lier des classes Java à XML.

JAX-WS cache la complexité et les protocoles sous-jacents au développeur, rationalisant ainsi le processus de définition et de déploiement des services SOAP Java. Les IDE Java modernes comme Eclipse incluent une prise en charge complète du développement de services Web JAX-WS. La spécification JAX-WS a également été sélectionnée pour un développement continu à Jakarta EE.

Conclusion

L'architecture orientée services mise en œuvre avec les services Web SOAP nécessite des définitions de service plus rigides et formelles que les services Web ou microservices RESTful. Cependant, certaines grandes organisations continuent de privilégier le style plus formel imposé par SOAP. De nombreux systèmes hérités à grande échelle sont également basés sur SOAP, et certains systèmes B2B et internes choisissent des services Web basés sur SOAP pour leurs contrats d'API définis plus formellement. Que vous développiez ou mainteniez un système d'entreprise à grande échelle, comprendre le modèle SOA et être en mesure d'évaluer vos options de mise en œuvre vous sera utile dans votre carrière de programmeur.

Cette histoire, "Qu'est-ce que l'architecture orientée services?" a été initialement publié par JavaWorld.