Architecture orientée services - Définition et Explications
Source: Wikipédia sous licence CC-BY-SA 3.0.
La liste des auteurs est disponible ici.
L'architecture orientée services (calque de l'anglais Service Oriented Architecture, ou SOA) est une forme
d'architecture de médiation qui est un modèle d'interaction applicative qui met en œuvre des services (composants
logiciels) :
avec une forte cohérence interne (par l'utilisation d'un format d'échange pivot, le plus souvent XML),
et des couplages externes "lâches" (par l'utilisation d'une couche d'interface interopérable, le plus souvent un service
web WS-*).
Le service est une action exécutée par un " fournisseur " (ou " producteur ") à l'attention d'un " client " (ou
" consommateur "), cependant l'interaction entre consommateur et producteur est faite par le biais d'un médiateur (qui
peut être un bus) responsable de la mise en relation des composants.
Ces systèmes peuvent aussi être définis comme des couches applicatives.
L'architecture orientée services est une réponse très efficace aux problématiques que rencontrent les entreprises en
termes de réutilisabilité, d'interopérabilité et de réduction de couplage entre les différents systèmes qui implémentent
leurs systèmes d'information.
Les architectures SOA ont été popularisées avec l'apparition de standards comme les Services Web dans l'e-commerce
(commerce électronique) (B2B, inter-entreprise, ou B2C, d'entreprise à consommateur), basés sur des plates-formes
comme J2EE ou .NET et la déclinaison libre Mono de cette dernière.
Elles mettent en application une partie des principes d'urbanisation.
Au sein de l'architecture orientée services, on distingue les notions d'annuaire, de bus, de contrat et de service, ce
dernier étant le noyau et le point central d'une architecture orientée services.
Le service étant à grandes mailles, il englobe et propose les fonctionnalités des composants du système. La SOA est un
concept d'architecture, la WSOA (WebService Oriented Architecture) en est sa déclinaison ou plus précisément
son implémentation avec des WebService.
Exemple
On peut citer la SNCF, qui a mis en place une architecture de type SOA pour son système de réservation (recherche
d'horaire, demande de tarif, réservation...) qui prend en charge à la fois les terminaux des guichets des agences et
gares, et les sollicitations de son site web de commande en ligne.
Description de l'architecture
L'annuaire de services
L'annuaire de services référence l'ensemble des services (et des contrats associés) disponible au sein du SI, il participe
ainsi activement à la mise en œuvre d'une cartographie dynamique du SI. Dans un modèle de bus, l'annuaire peut être
auto-alimenté par le service (enregistrement). Les annuaires UDDI forment aujourd'hui le standard
de référencement des services.
Le bus de service
Dans une architecture SOA, le bus a un rôle de médiateur (middleware) entre le consommateur et le producteur du
service, il permet ainsi de réaliser le couplage lâche. Le bus peut aussi fournir une gamme de services :
sur la base des patterns EIP (Enterprise Integration Pattern), fournir des fonctionnalités de split, combine, etc.
permettant de combiner l'appel sur plusieurs services,
des fonctionnalités de versioning de service,
des fonctionnalités de supervision et contrôle (avec SLA) des services.
Le service
Le service est un composant clef de l'Architecture Orientée Services. Il consiste en une fonction ou fonctionnalité bien
définie. C'est aussi un composant autonome qui ne dépend d’aucun contexte ou service externe.
Une architecture orientée services consiste essentiellement en une collection de services qui interagissent et
communiquent entre eux. Cette communication peut consister en un simple retour de données ou en
une activité (coordination de plusieurs services).
Un service est une entité de traitements qui respecte les caractéristiques suivantes :
Grande Maille (coarse-grained) : Les opérations proposées par un service encapsulent plusieurs fonctions et opèrent
sur un périmètre de données large au contraire de la notion de composant technique.
Interface : Un service peut implémenter plusieurs interfaces, et aussi plusieurs services peuvent implémenter
une interface commune.
Localisable : Avant d’appeler (bind, invoke) un service, il faudra le trouver (find).
Instance unique : A la différence des composants qui sont instanciés à la demande et peuvent avoir plusieurs
instances en même temps, un service est unique. Il correspond au design pattern Singleton.
Couplage faible (loosely-coupled) : Les services sont connectés aux clients et autres services via des standards. Ces
standards assurent le découplage, c'est-à-dire la réduction des dépendances. Ces standards sont des documents XML
comme dans les web services.
Synchrone ou Asynchrone.
Les protocoles et les normes
Les architectures SOA reposent principalement sur l’utilisation d’interface d’invocation (SOAP) et de vocabulaire de
description de données (WSDL et XML) qui doivent être communs à l’ensemble des agents (fournisseurs de services et
utilisateurs de services).
Ce dispositif permet de réutiliser les applicatifs métiers, le but étant de permettre à l’entreprise de s’adapter rapidement
à un nouveau contexte de marché.
En terme d'intéropérabilité, les architectures SOA reposent en partie sur les normes décrites à travers le WS-I.
Parmi les différentes couches de normes et protocoles qui permettent de bâtir de telles architectures, on relève :
la gestion d'un annuaire de services (quels sont les services mis à disposition et par qui) avec : UDDI (Universal
Description Discovery and Integration) normalisé par l'OASIS,
la description des interfaces des services (quelles sont les données nécessaires à l'exécution du service, que fournit-il
en retour, ...) avec : WSDL (Web Services Description Language) recommandé par le W3C,
l' invocation (ou l'appel) du service (la requête transmise au service) avec : SOAP (Simple Object Access Protocol)
recommandé par le W3C,
le format des données échangées avec : XML (eXtensible Markup Language) recommandé par le W3C,
et enfin, le transport des données avec les protocoles internet : HTTP et TCP/IP qui sont des normes RFC.
Une architecture SOA pourra être également complétée par :
la gestion de la sécurité avec : SSL (Secure Sockets Layer), XML Signature, XML Encryption, SAML (Security
Assertion Markup Language) ou encore XKMS (XML Key Management Specification, qui gère les infrastructures à clé
publique ou PKI)
l' orchestration (on parle également de chorégraphie) des services pour constituer des processus métier avec :
BPEL4WS (Business Process Execution Language For Web Services) devenu WS-BPEL et qui est un dérivé à la fois
de WSFL (Web Services Flow Language) d'IBM et de XLang de Microsoft qu'il a remplacé, devenant de fait le standard
de l'orchestration des services web. On peut aussi citer WSCI (Web Services Choregraphy Interface). L'orchestration
suppose l'existence d'un chef d'orchestre (WS-BPEL est un langage d'orchestration), tandis que la chorégraphie
implique des interactions pair-à-pair. WS-CDL (Web Services Choregraphy Description Language) est un exemple, le
plus récent, d'un tel langage.
la gestion transactionnelle (gestion du two-phase commit pour la mise à jour contrôlée de plusieurs bases de données
réparties entre plusieurs fournisseurs de services : la transaction " attend " de recevoir l'acquittement (le commit) des
différents serveurs sollicités et en cas de problème avec l'un d'eux, est en mesure de demander aux autres serveurs de
" défaire " les mises à jour partielles effectuées afin de maintenir l'intégrité des données) : WS-Transaction d'IBM, XAML
(Transaction Authority Markup Language) ou encore BTP (Business Transaction Protocol).
écouvrez les architectures orientées services
Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !
Les architectures orientées services
À travers ce cours, vous allez découvrir ce que c’est une architecture orientée
services, ses concepts, et ce qu’elle apporte dans le développement d’applications,
notamment les applications distribuées. Mais avant cela, je vous présenterai
quelques enjeux et problèmes qui découlent du développement d’applications.
Évolution des applications
L’un des facteurs importants à considérer lors du développement des applications
est l’évolution des applications.
Pour comprendre de quoi il s’agit, considérons par exemple que vous êtes sollicité
pour le développement d’une application qui fournit des fonctionnalités désignées par
A et B.
Si vous êtes amené à étendre votre application par l'ajout de nouvelles
fonctionnalités, désignées par C et D, cela ne doit pas remettre en question les
parties existantes de l’application.
Au contraire, votre application doit évoluer pour intégrer de nouvelles
fonctionnalités, sans aucun impact sur le code existant.
Réutilisation des applications
Maintenant, supposons que vous êtes sollicité une autre fois pour développer une
autre application qui doit fournir des fonctionnalités B, C, E, et F. Étant donné que les
fonctionnalités B et C sont déjà fournies par la première application, il serait judicieux
de pouvoir les réutiliser et de ne pas les développer à nouveau. Cela vous éviterait la
duplication du code inutile et cela réduirait aussi les efforts et les coûts. Il est
donc important que vos applications soient développées de telle sorte qu’elles
favorisent la réutilisation.
Applications distribuées
Comme vous le savez certainement déjà, les applications sont de plus en plus
complexes et reposent sur l’intégration de plusieurs applications.
À titre d’exemple, quand vous effectuez des achats sur Internet, plusieurs logiciels
appartenant à différents organismes peuvent être amenés à collaborer : la banque
pour vérifier la validité de votre numéro de carte bancaire, la société de livraison pour
la prise en compte et le suivi de la livraison, et le site marchand pour la prise en
compte de votre commande.
Architectures orientées services – SOA
L’architecture orientée services est apparue pour apporter des solutions au
problème d’intégration d’applications. En quoi consiste SOA ? L’idée est simple !
Elle consiste à encapsuler les applications sous forme de briques logicielles
appelées services. Ainsi, les différentes fonctionnalités requises sont exposées
sous forme d’un ou plusieurs services.
Par conséquent, en suivant cette architecture, les applications peuvent être
construites en composant et en réutilisant des services, à l’image des Lego.
Contrairement au développement classique des applications, SOA favorise la
réutilisation, l’évolution et l’intégration des applications.
Service Web
Vous avez vu jusqu’à maintenant que la notion de service est centrale dans
l’architecture orientée services.
Vous vous posez certainement la question de savoir comment utiliser ces services
pour créer par exemple des applications qui exploitent différents services qui
appartiennent potentiellement à différents fournisseurs ?
Ou autrement dit, comment créer des applications orientées services distribuées ?
La réponse est en utilisant la technologie des services Web.
Et c’est quoi, un service Web ?
Un service Web peut être vu comme une interface logicielle accessible via le
Web qui permet de fournir des données et des prestations. Pour utiliser un
service Web, seule la description de son interface est nécessaire. Les détails liés à
son implémentation ne sont ni exposés ni requis.
Étant donné que les services Web se basent sur les standards du Web et n’exposent
aucun détail lié à l’implémentation, différents services, même développés dans
différents langages, peuvent être composés pour créer des applications.
Les standards des services Web
La technologie des services Web repose principalement sur trois standards :
1. WSDL (Web service description language) ou, autrement dit, un langage de
description qui est basé sur XML. Le but de ce langage est de décrire
l’interface d’un service Web indépendamment de son implémentation. Cette
description fournit des informations nécessaires à l’appel du service, comme
les opérations qu’il offre, les types de données supportées, les protocoles
utilisés et l’adresse du service.
2. Les services Web communiquent via l’échange de messages qui respectent
un certain format. C’est justement ce que permet de faire SOAP (Simple
Object Access Protocol). SOAP est un standard de communication basé sur
XML.
3. Les messages SOAP sont ensuite envoyés en utilisant un protocole de
transport tel que HTTP.
Enfin, la description WSDL des services Web peut être publiée dans des
annuaires respectant le standard UDDI (Universal Description Discovery and
Integration).
Dans ce cours, vous avez vu ce qu’est une architecture orientée services et ce
qu’elle apporte dans le développement des applications. Le choix d’une solution
adéquate pour mettre en place une application distribuée n’aura plus de secret pour
vous. Vous êtes désormais capable de proposer des solutions de conception
d’applications qui sont modulaires, distribuées, évolutives, et interopérables en vous
basant sur l’architecture SOA. Dans le prochain cours, vous allez découvrir une
deuxième architecture très répandue de nos jours et qui est plutôt orientée
ressource.