• 4 heures
  • Difficile

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 16/04/2024

Apprenez l'architecture orientée services

Dans ce chapitre, nous aborderons l'architecture orientée services (service-oriented architecture) et les problèmes qu'elle permet de résoudre. À la fin du chapitre, je vous montrerai un exemple concret (la société GlobalWeather), puis vous devrez résoudre un cas similaire en appliquant ce que vous avez appris. 

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

Imaginez que vous achetiez un article sur le site marchand d'une marque très connue. Vous sélectionnez l'article, la taille, la couleur, puis vous passez à la caisse sur le site. Vous payez l'article avec votre carte de crédit ou un autre mode de paiement et choisissez la livraison à votre domicile, éventuellement grâce à un service de livraison tel que FedEx.

Selon votre adresse de livraison, le site web vous donne immédiatement un numéro de suivi pour votre colis. Il s'agit d'un numéro unique et long (20 chiffres) utilisé pour suivre votre colis. À partir de cet instant, vous pouvez accéder au site Internet du détaillant et vérifier à tout moment la localisation de votre colis.

Si nous examinons cette situation, il semble que le site marchand ait « parlé » avec FedEx lorsque vous avez effectué l'achat, et qu'il ait pu vous communiquer immédiatement votre numéro de suivi. Les deux sociétés ont communiqué ensemble lors de l'achat de l'article pour que vous puissiez suivre votre colis grâce au numéro donné.

Les deux sites y sont parvenus grâce à une architecture orientée services. Dans cette architecture, les services sont fournis à des consommateurs externes par un processus de communication sur un réseau (Internet). Dans notre exemple, FedEx est le fournisseur de services, et le site marchand est le consommateur de services. Les services de FedEx sont mis à la disposition de ce client externe via une architecture orientée services. 

Quelle est la structure d'une architecture orientée services ? 

Voyons à quoi cela ressemble :

Dépôt de service Web au milieu. Flèche à sa gauche vers Serveur de base de données. Flèche en dessous, étiquetée Internet, vers Contrôleur de services Web. 4 flèches en dessous, étiquetées Internet, vers des Demandeurs de services.
Architecture orientée services

Comme vous pouvez le voir dans le schéma ci-dessus, une architecture orientée services standard comporte quatre parties :

  • Le dépôt de services web (Web service repository) : Il s'agit d'une bibliothèque de services web conçue pour répondre à des demandes d'informations externes. L'information fournie est généralement un petit élément, comme un numéro, un mot, quelques variables, etc. Par exemple, un numéro de vol, un numéro de suivi de colis, le statut d'une commande (une lettre), etc. Cette bibliothèque est généralement documentée de manière très détaillée, car des applications externes font appel aux fonctions qu'elle contient. 

  • Le contrôleur de services web (Web service controller) : Ce module communique les informations contenues dans le dépôt de services web aux demandeurs de services. Lorsqu'un demandeur de service externe appelle une certaine fonction du dépôt de services web, le contrôleur de services web interprète la demande et recherche la fonction dans le dépôt de services web. Il exécute ensuite cette fonction et renvoie une valeur au demandeur.

  • Le serveur de base de données (Database Server) : Ce serveur contient les tables, les index et les données gérés par l'application. Les recherches et les opérations d'insertion/suppression/mise à jour sont exécutées ici. 

  • Les demandeurs de services (Service Requester) : Il s'agit d'applications externes qui demandent des services au dépôt de services web par l'intermédiaire d'Internet, comme une organisation demandant des informations sur les vols à une compagnie aérienne, ou une autre entreprise demandant à un transporteur la localisation d'un colis à un moment donné.

Notez que l'architecture orientée services est créée par l’entreprise qui fournit le service et non par celle qui le consomme, cela permet de simplifier les connexions avec les clients éventuels.

Comment cela fonctionne-t-il en pratique ?

Prenons l'exemple de Visa qui fournit un service à une entreprise connue de jeans :

  • Le site web de Levi's a besoin des informations de Visa (fournisseur de services) pour effectuer une transaction.

  • Le site web de Levi's appelle la fonction « Validate_Credit_Card_Number 5555 4567 8901 3456 » à partir du dépôt de services web du site Visa.

  • Le site web de Visa reçoit la demande, exécute la fonction « Validate_Credit_Card_Number 5555 4567 8901 3456 » et renvoie la valeur « OK », ce qui signifie que la carte de crédit est valide.

  • Le site web de Levi's reçoit la valeur « OK » et l'utilise pour conclure la transaction.

L'utilisation d'une architecture orientée services présente plusieurs avantages :

  • Ce modèle permet de collaborer avec des acteurs externes sans les laisser accéder à nos systèmes. Dans l'exemple ci-dessus, Visa ne veut pas ouvrir sa base de données à des tiers pour des raisons de sécurité, mais elle souhaite néanmoins que les clients puissent obtenir les informations dont ils ont besoin. 

  • Il permet également de partager avec le monde entier, de manière ordonnée et contrôlée, la sélection des fonctions les plus populaires du site. Visa dit : « Si quelqu'un veut connaître l'état de la carte X, appelez cette fonction, donnez la valeur de X et je répondrai par oui ou par non. » La fonction est ouverte au monde en tant que service dans un environnement très strict et contrôlé ; les clients ne peuvent pas accéder à ce qu'ils veulent. 

Il existe également quelques inconvénients majeurs :

  • Les services web peuvent représenter une faiblesse au niveau du site pour les pirates qui veulent engorger le système. Certaines formes d'attaques sont des « dénis de service ». Elles consistent à demander le même service web des millions de fois par seconde, jusqu'à ce que le serveur tombe en panne. Il existe aujourd'hui une technologie permettant de résoudre ce problème, mais c'est toujours un problème à prendre en compte dans les architectures de services web.

  • Le propriétaire du service web aide d'autres sites, mais reçoit une petite rémunération pour ce faire.

Quand utiliser l'architecture orientée services ? 

Voici quelques situations où cette architecture peut être utile :

Nom de l'exemple 

Définition 

Exemple concret 

Avantages

Suivi de colis

Un service web de suivi des colis est une fonction qui, en fonction d’un numéro de suivi, décrit l'itinéraire et la localisation actuelle d'un colis commandé par un client.

  • FedEx shipping Integration (fedex.com).

  • DHL Express Package Tracking (dhl.com).

Les sites de vente au détail qui utilisent ces services web ne doivent pas accéder aux systèmes internes de FedEx ou de DHL. 

La fonction de suivi de colis réside sur Internet et peut être utilisée librement par tout site de vente au détail.

Informations sur les vols

Un service web d'information sur les vols accepte en entrée un numéro de vol. Il renvoie les données relatives au vol : heure de départ, heure d'arrivée prévue, lieu de départ, lieu d'arrivée, altitude actuelle, etc.

  • Flight Explorer Professional Edition (flightexplorer.com)

Les sites de voyage, les hôtels et les entreprises de logistique qui utilisent ce produit peuvent disposer d'informations immédiates sur un vol par Internet sans avoir à accéder aux systèmes internes.

Convertisseur de devises

Un service web de conversion de devises accepte une devise source et donne sa valeur dans une devise de destination (par exemple, « combien de dollars américains font un euro »).

Toutes les grandes banques en disposent, y compris la banque centrale de nombreux pays.

Les transactions monétaires nécessitent les taux de change officiels à un instant donné. Ce service web de conversion de devises publie toutes les conversions de devises fournies par la Banque centrale.

Étude de cas : Résoudre un problème d'entreprise avec l'architecture orientée services 

Appliquons ce que vous avez appris et voyons comment cela est utilisé dans une organisation réelle.

GlobalWeather est une entreprise mondiale qui vend des informations sur les conditions météorologiques. Voici quelques faits importants :

  • GlobalWeather est basée aux États-Unis et compte plus de 700 employés.

  • GlobalWeather vend aux entreprises des informations météorologiques sur des pays, des régions, des villes, voire des lieux précis définis par leurs latitude et longitude.

  • Les clients de GlobalWeather sont dispersés dans le monde entier et utilisent généralement les informations via Internet. Cela est particulièrement utile pour les entreprises de transport : compagnies aériennes, services de bus et entreprises de logistique qui disposent d'une flotte de camions pour distribuer des marchandises dans une région. Ainsi que pour toutes les entreprises qui coordonnent des événements en plein air. 

  • Les clients ont besoin d'informations en temps réel. 

 Quelle est la problématique de l'entreprise ?

GlobalWeather vend des informations à ses clients en temps réel, mais ne peut laisser tous les clients accéder à ses systèmes internes pour des contraintes de sécurité.

Comment pouvons-nous résoudre ce problème ? Voyons les faits :

GlobalWeather a des milliers de clients. Pour acheter ses services, chaque client doit se connecter aux systèmes de GlobalWeather et obtenir des informations manuellement. C’est très complexe et prend beaucoup de temps, d'autant plus que les informations demandées ne constituent généralement que des petites informations qui peuvent être transmises par Internet. 

En outre, de nombreux clients sont des sites web qui doivent se connecter au flux d'informations et afficher rapidement les informations météorologiques en temps réel. Par exemple, une compagnie aérienne qui vend un billet de la ville A à la ville B veut afficher la météo de la ville B une fois que le client achète ce billet.

Cette situation est parfaite pour une architecture orientée services : GlobalWeather peut créer une bibliothèque de fonctions et la mettre en œuvre sous forme de services web que ses clients utilisent une fois qu'ils ont payé. Cela garantit un service rapide et en temps réel sans permettre aux clients d'accéder aux serveurs internes.

Quelle est la solution ?

Voyons le schéma détaillé de l'architecture :

Fonctions du service Web météorologique au mileu. Flèche à sa gauche vers Serveur de base de données. Flèche en dessous, étiquetée Internet, vers Contrôleur de services Web. 4 flèches en dessous, étiquetées Internet, vers des Clients.
Architecture orientée services : GlobalWeather

Passons en revue chaque composant du système :

  • Les fonctions du service web météorologique : Il s'agit d'une bibliothèque de services web conçue pour fournir aux sites web externes des informations météorologiques telles que la pluie, la direction et la vitesse du vent, la pression atmosphérique, etc.

  • Le contrôleur de services web : Ce module communique le dépôt de services web aux demandeurs de services. Lorsqu'un demandeur de service externe appelle une certaine fonction (par exemple, des informations sur les vols, des informations météorologiques, le statut des colis) à partir du dépôt de services web, le contrôleur de services web interprète l'appel et recherche la fonction dans le dépôt de services web. Il exécute ensuite cette fonction et renvoie une valeur au demandeur.

  • Les clients : Il s'agit d'applications externes qui demandent des services au dépôt de services web par l'intermédiaire d'Internet. Ces demandes sont codées dans l'application du demandeur selon une certaine syntaxe publiée par le fournisseur de services.

  • Le serveur de base de données GobalWeather : Ce serveur contient les tables, les index et les données gérées par le système.

En pratique, une compagnie aérienne demande : « Donnez-moi la météo dans la ville B demain, détaillée par heure, y compris la température, la pluie, la pression et le vent. » Le service web exécute cette fonction et renvoie ces valeurs à la compagnie aérienne. Tout cela se fait par Internet sans accéder aux serveurs internes de GlobalWeather.

Essayez vous-même !

Maintenant que vous avez découvert une solution, voyons si vous pouvez appliquer ce que vous avez appris à un autre cas !

Le contexte : Imaginez que vous êtes architecte logiciel dans une compagnie aérienne. Votre patron est Kim, le directeur des systèmes d'information (DSI).

Votre mission : Vous travaillez dans l'administration d'un grand aéroport de votre pays. On vous a demandé de développer un système logiciel permettant de donner le statut d'un vol en cours à certains demandeurs potentiels : compagnies aériennes, sites de voyage, sites d'hôtels, etc.

Il existe un système central dans la zone de contrôle de l'aéroport qui fonctionne en temps réel : celui-ci reçoit des informations pour les radars et les avions au fur et à mesure de l'avancement des vols.

Maintenant, c'est à vous de créer un système de transport aérien ! Voici quelques questions clés que vous pouvez vous poser pour commencer :

  1. De nombreux vols sont en cours à un moment donné. Comment pouvez-vous obtenir le statut du vol à partir du système central ?

  2. Comment allez-vous transmettre ces informations aux demandeurs externes ?

  3. Pourquoi la compagnie aérienne a-t-elle besoin de ce système ? Qui va utiliser ces informations ?

Pouvez-vous créer un schéma d'architecture pour ce contexte commercial ?

En résumé

Modèle d'architecture

Description

Avantages

Inconvénients

Quand l'utiliser

Orienté services

Un modèle d'architecture basé sur les services qui permet à un système externe d'utiliser une bibliothèque de fonctionnalités sans accéder aux systèmes internes.

Communication simple : fonctionne à 100 % sur Internet.

Normes de sécurité strictes : aucun client ne peut accéder aux systèmes internes.

Les clients ont besoin d'Internet pour utiliser la bibliothèque.

Le contrôleur de services web peut être surchargé et subir des problèmes de performance. 

Pensez au nombre de demandes que le service web de suivi de FedEx reçoit par seconde.

Lorsque vous avez de nombreux clients pour un service web.

Lorsque vous devez communiquer à distance avec ces clients.

Exemple de certificat de réussite
Exemple de certificat de réussite