Larchitecture orientée services (SOA) a émergé au début de ce siècle comme une évolution de linformatique distribuée. Avant SOA, les services étaient considérés comme le résultat final du processus de développement dapplications. Dans SOA, lapplication 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 grand.
Les services interagissent via le réseau en utilisant un protocole tel que REST ou SOAP (Simple Object Access Protocol). Les services sont faiblement couplés, ce qui signifie que linterface de service est indépendante de limplé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 caractéristiques clés dun architecture orientée services implémentée à laide 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.
Pourquoi l’architecture orientée services?
La SOA répond à trois défis d’entreprise courants :
- Réagissez rapidement aux changements commerciaux.
- Tirez parti des investissements dinfrastructure existants.
- Soutenez de nouveaux canaux dinteraction avec les clients, les partenaires et les fournisseurs.
Linfrastructure dentreprise est hétérogène entre les systèmes dexploitation, les applications, les logiciels système et linfrastructure dapplication. Par conséquent, de nombreux systèmes dentreprise sont composés dapplications complexes et incohérentes fournissant 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 leur infrastructure technique pour répondre aux besoins de lentreprise.
Comme par rapport à un archi monolithique tecture, 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 dexposer les applications héritées en tant que services, protégeant ainsi les investissements dinfrastructure.
Parce quils 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 application de la chaîne dapprovisionnement composite. Bien que les applications existantes soient hétérogènes et réparties sur divers systèmes, leurs fonctionnalités sont exposées et accessibles à laide dinterfaces standard.
Figure 1. Application de la chaîne logistique dans une architecture orientée services
Caractéristiques clés de SOA
La SOA peut être aussi simple quun composant unique consommant des services fournis par un autre composant ou aussi sophistiquée quune gamme de composants interagissant via un bus de services dentreprise tel que lESB de MuleSoft. Quelle que soit léchelle, la clé dune implémentation SOA réussie est pour 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 dune architecture orientée services est plus ou moins la même:
- Les fournisseurs de services exposent les points de terminaison et décrivent les actions disponibles à 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.
Mise en œuvre du service- architecture orientée
Pour implémenter SOA, vous commencez par larchitecture de service de base, puis fournissez linfrastructure, cest-à-dire les protocoles et autres outils qui permettent la communication et linteropérabilité. La figure 2 montre un diagramme dune architecture de service typique.
Figure 2. Un exemple darchitecture de service
Dans ce diagramme, trois consommateurs invoquent des services en envoyant des messages à un bus de services dentreprise, 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 de service gère des activités telles que laudit, la facturation et la journalisation.
Les composants de cette architecture sont faiblement couplés, ils peuvent donc être désactivés ou mis à jour avec un impact relativement minime sur lapplication dans son ensemble. Cela donne à lentreprise la flexibilité dajouter 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 dincidence importante sur les autres services.
Services Web basés sur SOAP
Les services Web implémentés à laide de SOAP sont encore plus rigides quune implémentation de services Web ou de microservices RESTful, mais beaucoup plus flexibles que les premiers jours de SOA. Ici, nous allons simplement examiner les protocoles de haut niveau requis pour les services Web basés sur SOAP.
SOAP, WSDL et XSD
SOAP, WSDL et XSD sont linfrastructure fondamentale dune 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 lenvoi de messages entre les consommateurs de services et les fournisseurs. Les services communiquent avec des messages définis formellement à laide du schéma XML (XSD). Vous pouvez penser à WSDL comme interface du service (vaguement analogue à une interface Java). Limplémentation se fait dans les classes Java et la communication à travers le réseau se fait via SOAP. Fonctionnellement, un consommateur chercherait un service, obtiendrait le WSDL pour ce service, puis invoquerait le service en utilisant SOAP.
Sécurité du service Web
Le WS -I La spécification Basic Profile 2.0 traite de la sécurité des messages. Cette spécification se concentre sur léchange dinformations didentification, lintégrité des messages et la confidentialité des messages.
Découverte de services Web
Une fois la pierre angulaire de la découverte de services Web, lUDDI (Description, définition et intégration universelles) sest évanouie dans lhistoire. Aujourdhui, il est courant dexposer un service Web SOAP comme vous le feriez pour tout autre service, via une URL de point de terminaison. Par exemple, vous pouvez utiliser linterface de point de terminaison de service JAX-WS et son @WebService et @WebMethod annotations.
Création et déploiement de services Web
Les développeurs Java disposent de plusieurs options pour créer et déployer SOAP services Web, y compris Apache Axis2 et Spring-WS; cependant, le standard Java est JAX-WS, lAPI Java pour les services Web XML. Lidée principale de 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éfinir et de déployer 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 WS a également été sélectionnée pour un développement en cours dans Jakarta EE.
Conclusion
Larchitecture orientée services implémentée avec des services Web SOAP nécessite plus de rigidité et des définitions de service 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 construits sur SOAP, et certains systèmes B2B et internes choisissent des services Web basés sur SOAP pour leurs contrats dAPI définis plus formellement. Que vous développiez ou mainteniez un système dentreprise à 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.