Лист за преговор: Conception et déploiement d'architectures microservices

📋 Plan du Cours

1. Systèmes distribués
2. Web Services et SOA
3. REST et architecture
4. Microservices et design
5. XML et XSD
6. JSON et JSON Schema
7. SOAP et protocol
8. API RESTful et annotations
9. Déploiement et configuration
10. Architecture microservices

📖 1. Systèmes distribués

🔑 Notions clés & Définitions

• Distributed computing : Coordination de plusieurs éléments informatiques pour résoudre un problème commun, permettant le partage de ressources et la gestion de tâches réparties (voir concepts pré-assignés).
• High-performance computing (HPC) : Utilisation de supercalculateurs ou clusters pour le traitement parallèle de données volumineuses ou complexes, souvent associé à la recherche scientifique ou à l’analyse de Big Data, en exploitant la programmation parallèle.
• Ubiquitous computing : Intégration de systèmes informatiques puissants dans l’environnement quotidien, permettant une interaction omniprésente avec les données et services, notamment via le cloud, IoT, et grid computing (voir concepts pré-assignés).
• Grid computing : Architecture de haute performance qui partage des ressources informatiques à travers un réseau pour exécuter des tâches intensives, combinant la puissance de plusieurs machines pour former une plateforme unifiée.
• Peer-to-peer et volunteer computing : Partage de ressources informatiques lorsque celles-ci sont inactives, permettant à des utilisateurs volontaires ou à des réseaux décentralisés de contribuer à la puissance de calcul globale.

📝 Points essentiels

• L’évolution des systèmes informatiques va du modèle centralisé (sans OS, mono-utilisateur) vers le modèle distribué, intégrant réseaux, clusters, et systèmes ubiquistes.
• Le high-performance computing repose sur des architectures spécialisées comme les supercalculateurs et clusters, utilisant la parallélisation pour accélérer les traitements scientifiques ou industriels.
• La technologie du grid computing permet de mutualiser des ressources dispersées pour des calculs intensifs, facilitant la recherche scientifique et l’analyse de données massives.
• La volonté de partage de ressources dans le peer-to-peer et le volunteer computing exploite les périodes d’inactivité des machines pour augmenter la puissance collective.
• La transformation vers le cloud computing représente un paradigme où les ressources sont accessibles à distance, permettant une flexibilité et une scalabilité accrues dans la gestion des infrastructures informatiques.

💡 À retenir

Les systèmes distribués coordonnent plusieurs éléments informatiques pour optimiser la puissance de traitement et la gestion des ressources, évoluant vers des architectures ubiquistes et cloud, essentielles pour le traitement de Big Data et la recherche scientifique.

📖 2. Web Services et SOA

🔑 Notions clés & Définitions

• Web Services : Interfaces accessibles via un réseau utilisant des protocoles Internet standards, permettant l’interaction entre applications distribuées. Selon Yudith Cardinale (2024), un Web Service expose des fonctionnalités à un consommateur via une URL programmable, en masquant les détails d’implémentation et en étant décrit par un langage de description de service (WSDL).
• Service Oriented Architecture (SOA) : Principes de conception pour des systèmes logiciels distribués composés de services autonomes, indépendants, et réutilisables. Yudith Cardinale (2024) précise que ces services encapsulent la logique métier et peuvent être déployés et gérés indépendamment, favorisant la flexibilité et la contrôle des dépendances.
• SOAP (Simple Object Access Protocol) : Protocole d’accès aux Web Services basé sur des standards, développé par Microsoft (date non précisée), permettant l’échange de messages structurés en XML via des protocoles comme HTTP ou SMTP, avec une structure d’enveloppe comprenant en-tête et corps.
• WSDL (Web Services Description Language) : Langage en XML permettant de décrire formellement un Web Service, ses opérations, messages, et points d’accès. Selon Yudith Cardinale (2024), il couvre tous les détails nécessaires pour interagir avec le service, notamment les formats de message et protocoles.
• UDDI (Universal Description, Discovery, and Integration) : Mécanisme de registre pour localiser et décrire des Web Services, facilitant leur découverte par d’autres applications ou services.

📝 Points essentiels

• Un Web Service est une composante logicielle accessible via un réseau, utilisant des standards comme HTTP, XML, SOAP, WSDL, et UDDI, pour assurer l’interopérabilité entre différentes plateformes et langages.
• La conception SOA repose sur des services autonomes, encapsulant la logique métier, pouvant être déployés et gérés indépendamment, ce qui facilite la modularité et la réutilisation dans des architectures distribuées.
• SOAP, développé initialement par Microsoft, est un protocole basé sur XML, permettant l’échange de messages structurés, notamment dans des environnements nécessitant une sécurité ou une fiabilité accrue.
• WSDL sert à décrire de manière formelle un Web Service, ses opérations, messages, et points d’accès, facilitant l’automatisation de l’intégration et la génération de clients.
• UDDI joue un rôle clé dans la découverte des Web Services, en agissant comme un annuaire où les services peuvent être enregistrés, recherchés, et localisés par les développeurs ou applications.

💡 À retenir

Les Web Services, encadrés par la SOA, permettent une communication standardisée et interopérable entre applications distribuées, grâce à des protocoles et langages comme SOAP et WSDL, et à un mécanisme de registre via UDDI.

📖 3. REST et architecture

🔑 Notions clés & Définitions

• REST (Representational State Transfer) : style architectural pour la conception de services web simples, basé sur l’utilisation des protocoles HTTP et la manipulation de ressources via des représentations. (voir source)

• SOAP (Simple Object Access Protocol) : protocole de services web basé sur des standards, développé par Microsoft, souvent considéré comme complexe, auquel REST a répondu en proposant une alternative plus simple. (voir source)

• Méthodes HTTP en REST : opérations fondamentales pour manipuler les ressources via URIs, comprenant GET (récupérer une ressource), POST (créer une ressource), PUT (mettre à jour une ressource), DELETE (supprimer une ressource). (voir source)

• Statelessness (sans état) : principe selon lequel chaque requête REST doit contenir toutes les informations nécessaires pour être traitée, sans dépendance à des états côté serveur, ce qui facilite la scalabilité et la simplicité. (voir source)

• Identification des ressources par URIs : chaque ressource dans une architecture REST est identifiée de manière unique par une URI (Uniform Resource Identifier), permettant une localisation précise et une manipulation claire. (voir source)

📝 Points essentiels

• REST a été conçu comme une réponse aux limitations de SOAP, notamment sa complexité et son couplage étroit avec des standards spécifiques. REST privilégie la simplicité, la légèreté, et l’utilisation native des protocoles HTTP. (voir source)

• Les méthodes HTTP (GET, POST, PUT, DELETE) sont utilisées pour effectuer des opérations CRUD (Create, Read, Update, Delete) sur les ressources identifiées par des URIs, ce qui facilite l’interopérabilité et la compréhension des services web. (voir source)

• Le principe de statelessness garantit que chaque requête est indépendante, ce qui permet une meilleure scalabilité, une gestion simplifiée des sessions, et une architecture plus robuste. (voir source)

• La conception REST repose sur la manipulation de ressources représentées généralement en XML ou JSON, et leur accès via des URIs, ce qui favorise une architecture orientée ressources plutôt que services. (voir source)

• REST est souvent utilisé dans le développement d’API modernes, notamment pour les applications mobiles, web, et microservices, en raison de sa simplicité et de sa compatibilité avec le web. (voir source)

💡 À retenir

REST est un style architectural léger et efficace pour la conception de services web, basé sur l’utilisation des méthodes HTTP et l’identification claire des ressources via des URIs, avec un principe de statelessness pour favoriser la scalabilité.

📖 4. Microservices et design

🔑 Notions clés & Définitions

• Architecture microservices : Construction d’applications sous forme de services faiblement couplés, autonomes et déployables indépendamment, permettant une gestion modulaire et évolutive des systèmes (voir concepts pré-assignés).
• Conteneurs et machines virtuelles : Technologies permettant le déploiement isolé et portable des microservices, facilitant leur gestion, leur mise à l’échelle et leur déploiement indépendant.
• Principes de conception pour microservices : Ensemble de règles visant à assurer la scalabilité, la résilience et l’autonomie des microservices, notamment par la décentralisation, la gestion indépendante et la tolérance aux pannes.

📝 Points essentiels

• L’architecture microservices repose sur la décomposition d’une application en services autonomes, chacun étant responsable d’une fonction spécifique, ce qui facilite la maintenance, la scalabilité et la résilience du système (voir concepts pré-assignés).
• Le déploiement des microservices s’appuie souvent sur des conteneurs (ex : Docker) ou des machines virtuelles, permettant une isolation, une portabilité et une gestion indépendante, tout en simplifiant la mise à l’échelle et la mise à jour.
• La conception des microservices doit respecter des principes clés :
  • Scalabilité : capacité à augmenter ou réduire dynamiquement le nombre de microservices en fonction de la charge.
  • Résilience : capacité à continuer de fonctionner malgré des défaillances partielles, grâce à l’isolation et à la gestion indépendante des services.
  • Autonomie : chaque microservice doit pouvoir évoluer, déployer, et gérer ses propres données et dépendances sans impact sur les autres.
• La gestion indépendante permet une évolution plus rapide, une meilleure tolérance aux erreurs, et une adaptation flexible aux besoins changeants.

💡 À retenir

L’architecture microservices repose sur la modularité, l’indépendance et la scalabilité des services, facilitée par l’utilisation de conteneurs ou machines virtuelles, et guidée par des principes assurant résilience et autonomie.

📖 5. XML et XSD

🔑 Notions clés & Définitions

• XML (Extensible Markup Language) : Langage de balisage extensible permettant de représenter, stocker et transporter des données de manière hiérarchique et lisible par l’homme et la machine. Il repose sur une syntaxe stricte pour assurer la cohérence de la structure des documents.
• XSD (XML Schema Definition) : Schéma basé sur XML permettant de définir et de valider la structure, la syntaxe et les contraintes d’un document XML. Il remplace le DTD en offrant une richesse typologique et une extensibilité accrues.
• Structure et syntaxe de XML : Règles régissant la composition des documents XML, notamment la nécessité de respecter la hiérarchie des balises, la citation des attributs, la sensibilité à la casse, et la conformité à un schéma ou DTD pour assurer leur validité.
• Utilisation de XML dans les Web Services : Format privilégié pour l’échange de messages, notamment dans SOAP, où XML sert à structurer les données transmises entre client et serveur, facilitant l’interopérabilité et la standardisation.

📝 Points essentiels

• XML doit suivre une syntaxe rigoureuse : balises bien formées, noms courts, non utilisation de caractères spéciaux non échappés, et respect de la casse. La déclaration initiale <?xml version="1.0" encoding="UTF-8"?> précise la version et l’encodage, supportant ainsi les caractères internationaux grâce à Unicode.
• Validité d’un XML : un document est valide s’il respecte la grammaire définie par un DTD ou un XSD. Le DTD décrit la structure avec une liste d’éléments et d’attributs légaux, tandis que le XSD, basé sur XML, offre une description plus riche, notamment la typologie des données, l’ordre des éléments, et l’utilisation des espaces de noms.
• XSD se distingue par sa syntaxe XML, permettant une meilleure intégration et extensibilité. Il définit notamment :
  • Les types simples (string, integer, date, etc.) et complexes (éléments contenant d’autres éléments ou attributs).
  • Les indicateurs d’ordre (all, choice, sequence), d’occurrence (minOccurs, maxOccurs), et de groupes (groupes d’éléments ou d’attributs).
  • La possibilité d’étendre ou de restreindre des types via l’héritage.
• Avantages du XSD : supporte les namespaces, la typologie avancée, la validation automatique, et l’extensibilité, contrairement au DTD qui est limité à une syntaxe non XML.

💡 À retenir

XML, via ses schémas XSD, offre une méthode structurée, extensible et standardisée pour représenter et valider des données dans les Web Services, garantissant leur cohérence et leur interopérabilité.

📖 6. JSON et JSON Schema

🔑 Notions clés & Définitions

• JSON (JavaScript Object Notation) : Format léger d’échange de données, basé sur une syntaxe de type objet en JavaScript, permettant de représenter des structures de données de manière simple et lisible (voir concepts pré-assignés).
• JSON Schema : Outil permettant de définir la structure, les contraintes et les règles de validation pour des données JSON, garantissant leur conformité à un modèle prédéfini (voir concepts pré-assignés).
• Comparison of JSON and XML : Analyse comparative entre JSON et XML pour la représentation de données, où JSON est souvent privilégié pour sa simplicité, sa légèreté et sa facilité d’intégration dans les applications modernes (voir concepts pré-assignés).
• Use of JSON in RESTful APIs : Utilisation de JSON comme format principal pour l’échange de données dans les API RESTful, facilitant la communication entre clients et serveurs grâce à sa compatibilité avec les technologies web et sa simplicité de traitement (voir concepts pré-assignés).

📝 Points essentiels

• JSON est devenu le standard de facto pour l’échange de données dans les architectures modernes, notamment dans les API RESTful, en raison de sa syntaxe simple, sa légèreté et sa compatibilité avec JavaScript.
• JSON Schema permet de formaliser la structure attendue des données JSON, en spécifiant notamment les types, les contraintes, les propriétés obligatoires, et en assurant la validation automatique des données échangées.
• La comparaison entre JSON et XML montre que JSON est généralement préféré pour sa simplicité syntaxique, sa taille réduite, et sa facilité d’intégration dans les applications web, contrairement à XML qui est plus verbeux et complexe.
• L’utilisation de JSON dans les API RESTful favorise une communication efficace, notamment grâce à la compatibilité native avec JavaScript, la facilité de parsing, et la possibilité d’utiliser des outils de validation comme JSON Schema pour garantir la cohérence des données échangées.

💡 À retenir

JSON est le format léger et universel pour l’échange de données dans les architectures modernes, et JSON Schema offre un cadre pour garantir la conformité et la validation des données JSON dans ces échanges.

📖 7. SOAP et protocol

🔑 Notions clés & Définitions

• Envelope SOAP : Structure de base d’un message SOAP, encapsulant l’intégralité du message, comprenant généralement un en-tête (header) et un corps (body). (source : contenu source)

• Header SOAP : Partie optionnelle du message SOAP utilisée pour transmettre des informations de contrôle, telles que l’authentification, la gestion des sessions ou d’autres métadonnées. (source : contenu source)

• Body SOAP : Partie principale du message SOAP contenant la requête ou la réponse, c’est-à-dire les données opérationnelles échangées entre le client et le serveur. (source : contenu source)

• Format et traitement du message SOAP : Le message SOAP est un document XML structuré, comprenant un envelope, un header (optionnel) et un body. Le traitement implique la sérialisation/désérialisation XML, la gestion des erreurs via des faults, et l’utilisation de protocoles de transport comme HTTP ou SMTP. (source : contenu source)

• Protocoles de transport utilisés par SOAP : SOAP peut fonctionner sur divers protocoles, principalement HTTP pour la compatibilité web, mais aussi SMTP, TCP, ou d’autres protocoles, permettant la flexibilité dans la transmission des messages. (source : contenu source)

• Faults SOAP et gestion des erreurs : Mécanisme intégré dans le corps du message SOAP permettant de signaler des erreurs lors du traitement, avec des éléments spécifiques comme <Fault> contenant des codes d’erreur, des descriptions, et des détails pour diagnostiquer les problèmes. (source : contenu source)

📝 Points essentiels

• Le envelope SOAP constitue la structure fondamentale d’un message SOAP, permettant d’encapsuler la communication entre client et serveur dans un format XML standardisé, facilitant l’interopérabilité. (source : contenu source)

• La partie header est optionnelle mais essentielle pour transmettre des métadonnées ou des instructions spécifiques, telles que la sécurité ou la gestion de sessions, sans affecter le traitement principal du corps. (source : contenu source)

• Le body contient la charge utile, c’est-à-dire la requête ou la réponse opérationnelle, et doit respecter un format XML précis pour assurer la compatibilité et la compréhension mutuelle. (source : contenu source)

• La structure du message SOAP repose sur un document XML, qui doit être sérialisé et désérialisé lors de l’envoi ou de la réception, avec une gestion spécifique des erreurs via la balise <Fault>. (source : contenu source)

• Les protocoles de transport comme HTTP ou SMTP permettent la transmission des messages SOAP, avec HTTP étant le plus couramment utilisé pour sa compatibilité avec le web. La sélection du protocole influence la sécurité, la performance et la fiabilité. (source : contenu source)

• La gestion des faults SOAP permet de signaler et diagnostiquer les erreurs survenues lors du traitement, en fournissant des codes d’erreur, des descriptions, et éventuellement des détails techniques pour la résolution. (source : contenu source)

💡 À retenir

Le protocole SOAP repose sur une structure XML standardisée comprenant un envelope, un header optionnel et un body, utilisant principalement HTTP ou SMTP pour la transmission, avec un mécanisme intégré pour la gestion des erreurs via les faults.

📖 8. API RESTful et annotations

🔑 Notions clés & Définitions

• API RESTful : Ensemble de conventions pour concevoir des interfaces web permettant l’échange de ressources via le protocole HTTP, en utilisant des opérations standardisées telles que GET, POST, PUT, DELETE, pour manipuler des ressources identifiées par des URIs.
• Annotations dans les API REST : Mécanismes utilisant des balises (annotations) pour associer des méthodes HTTP et des URIs à des fonctions ou méthodes dans le code, facilitant la gestion des requêtes et le binding des paramètres.
• Utilisation des annotations pour la gestion des requêtes et le binding des paramètres : Application d’annotations pour définir comment les paramètres d’une requête HTTP (corps, URI, paramètres de requête) sont liés aux arguments des méthodes, simplifiant ainsi la gestion des flux de données.
• Meilleures pratiques pour la conception des API RESTful : Recommandations visant à assurer la cohérence, la simplicité, la scalabilité et la maintenabilité des API, telles que l’utilisation cohérente des URIs, le respect des méthodes HTTP, et la gestion appropriée des codes de statut.
• Point à retenir : La conception d’une API RESTful repose sur l’utilisation cohérente des méthodes HTTP, l’identification claire des ressources via des URIs, et l’emploi d’annotations pour simplifier le mapping des requêtes et la gestion des paramètres.

📖 9. Déploiement et configuration

🔑 Notions clés & Définitions

Deployment strategies for distributed and microservices architectures : Méthodes et plans d’action pour déployer efficacement des architectures distribuées ou basées sur des microservices, en assurant la disponibilité, la scalabilité et la résilience des services. (voir section 4)

Configuration management for services and applications : Pratiques et outils permettant de gérer, automatiser et standardiser la configuration des services et applications, afin de garantir leur cohérence et leur déploiement sans erreur. (voir section 4)

Use of containers and orchestration tools : Emploi de conteneurs (ex : Docker) et d’outils d’orchestration (ex : Kubernetes) pour déployer, gérer et faire évoluer des applications de manière flexible, portable et scalable. (voir section 4)

Continuous integration and continuous deployment (CI/CD) pipelines : Processus automatisés permettant d’intégrer régulièrement les modifications de code, de tester et de déployer automatiquement les nouvelles versions des applications, assurant rapidité et fiabilité. (voir section 4)

📝 Points essentiels

• Les stratégies de déploiement pour architectures distribuées ou microservices doivent garantir la disponibilité continue des services tout en permettant une mise à jour progressive ou en rolling (déploiement sans interruption). (voir section 4)
• La gestion de configuration est essentielle pour maintenir la cohérence entre différents environnements (développement, test, production) et automatiser la mise à jour des paramètres. Des outils comme Ansible, Chef ou Puppet sont souvent utilisés. (voir section 4)
• L’utilisation de conteneurs facilite la portabilité et l’isolation des services, permettant un déploiement cohérent sur différentes plateformes. Les orchestrateurs comme Kubernetes automatisent la gestion des conteneurs, leur scalabilité, leur résilience et leur mise à jour. (voir section 4)
• Les pipelines CI/CD permettent d’automatiser l’intégration, le test et le déploiement, réduisant ainsi les erreurs humaines et accélérant la livraison des nouvelles fonctionnalités. Des outils comme Jenkins, GitLab CI ou CircleCI sont couramment employés. (voir section 4)
• La mise en œuvre de stratégies de déploiement telles que le blue-green ou le canary permet de minimiser les risques lors des mises à jour en production. (voir section 4)

💡 À retenir

Les stratégies modernes de déploiement, combinées à la gestion automatisée de la configuration et à l’utilisation de conteneurs orchestrés par des pipelines CI/CD, assurent la flexibilité, la fiabilité et la rapidité dans la livraison des architectures distribuées et microservices.

📖 10. Architecture microservices

🔑 Notions clés & Définitions

• Architecture microservices : Approche de conception d’applications consistant à décomposer une application en plusieurs services autonomes, indépendants, et déployables séparément, chacun réalisant une fonction métier spécifique. AUTEUR (voir section 4) : construit des applications comme une collection de services faiblement couplés, facilitant la scalabilité et la résilience.

• Décomposition en services et contextes bornés : Processus de diviser une application en unités fonctionnelles cohérentes, appelées "contextes bornés", qui encapsulent un domaine métier précis, permettant une gestion claire des responsabilités et une évolution indépendante. AUTEUR (voir section 4) : principe de séparation claire des responsabilités pour éviter les dépendances excessives.

• Communication entre microservices : Mécanismes permettant aux services de dialoguer, généralement via des protocoles légers comme HTTP/REST ou des messages asynchrones, pour échanger des données ou coordonner des actions. Points essentiels : utilisation de patterns comme la requête-réponse ou la messagerie asynchrone, pour assurer la cohérence et la résilience.

• Défis de l’architecture microservices : Difficultés rencontrées lors de la mise en œuvre, notamment la gestion de la cohérence des données (voir section 3), la surveillance (monitoring) pour détecter et diagnostiquer les problèmes, et la gestion de la complexité opérationnelle. La cohérence des données est souvent assurée par des stratégies comme la gestion eventuale ou la compensation.

📝 Points essentiels

• La décomposition en microservices repose sur le principe de service décomposition et de contextes bornés pour favoriser l’autonomie, la scalabilité, et la facilité de maintenance, conformément à AUTEUR (voir section 4). Chaque service doit encapsuler une logique métier cohérente et disposer d’une interface claire.

• La communication entre microservices privilégie des patterns légers comme REST ou la messagerie asynchrone, permettant une interaction flexible et résiliente. La communication doit respecter la souveraineté des services et minimiser les dépendances directes.

• Les principaux défis concernent la cohérence des données (ex : gestion eventuale, transactions distribuées), la monitoring pour assurer la disponibilité et la performance, et la gestion de la complexité opérationnelle (déploiement, versioning, sécurité). La surveillance est cruciale pour détecter rapidement les anomalies et assurer la résilience.

• La légitimité (voir section 4) de cette architecture repose sur ses avantages en termes de scalabilité, résilience, et autonomie, mais nécessite une gestion rigoureuse des défis liés à la cohérence et à la surveillance.

💡 À retenir

L’architecture microservices repose sur la décomposition en services autonomes et la gestion efficace de leur communication, tout en relevant les défis liés à la cohérence des données et au monitoring pour garantir la performance et la fiabilité du système.

📊 Tableaux de Synthèse

Thème	Concepts Clés	Protocoles / Standards	Auteurs / Références
Systèmes distribués	Modèle centralisé → distribué, HPC, grid, peer-to-peer, cloud	N/A	Connaissance générale, pas d'auteur spécifique
Web Services & SOA	Web Service, SOA, SOAP, WSDL, UDDI	SOAP (Microsoft), WSDL, UDDI	Yudith Cardinale (2024), Microsoft
REST & architecture	REST, HTTP methods, statelessness, URIs	HTTP, JSON, XML	Source générale, pas d'auteur spécifique

⚠️ Pièges & Confusions Fréquentes

1. Confondre Web Services SOAP avec REST : SOAP utilise XML et est plus lourd, REST privilégie JSON ou XML léger.
2. Associer à tort REST uniquement à JSON : REST peut utiliser XML ou d’autres formats.
3. Croire que SOAP est toujours plus sécurisé que REST : REST peut être sécurisé via HTTPS et autres mécanismes.
4. Confondre WSDL avec UDDI : WSDL décrit le service, UDDI le registre de services.
5. Penser que le modèle REST est synonyme de statelessness : REST impose le principe de statelessness, mais ce n’est pas une obligation dans tous les cas.
6. Confondre le rôle de la méthode POST avec PUT : POST crée ou envoie, PUT met à jour ou crée une ressource spécifique.
7. Omettre que le cloud computing représente une évolution du grid et du distributed computing, avec une gestion à distance des ressources.

✅ Checklist Examen

• Connaître la définition de Perroux sur la croissance économique.
• Identifier les différences fondamentales entre systèmes distribués, HPC, grid, et cloud computing.
• Expliquer le principe de fonctionnement des Web Services selon Yudith Cardinale (2024).
• Définir la architecture SOA et ses avantages pour la modularité.
• Comprendre le protocole SOAP, ses usages, et sa structure XML.
• Savoir décrire le rôle de WSDL dans la description des Web Services.
• Connaître le rôle d’UDDI dans la découverte et l’enregistrement des Web Services.
• Expliquer le style architectural REST et ses principes fondamentaux.
• Identifier les méthodes HTTP utilisées dans REST et leur correspondance avec les opérations CRUD.
• Comprendre le principe de statelessness et ses bénéfices pour la scalabilité.
• Différencier REST et SOAP en termes de complexité et d’usage.
• Maîtriser l’utilisation des URI pour l’identification des ressources dans REST.
• Connaître les formats de représentation des ressources (XML, JSON).
• Savoir que REST est souvent utilisé dans le développement d’API modernes pour microservices.
• Vérifier la maîtrise des protocoles et standards liés aux Web Services et REST.
• Assimiler l’évolution des architectures distribuées vers le cloud computing.
• Identifier les pièges fréquents liés à la confusion entre SOAP et REST.
• Se rappeler que REST privilégie la simplicité et la légèreté pour l’interopérabilité.
• Connaître les auteurs et références clés : Yudith Cardinale (2024), Microsoft, sources générales.
• Maîtriser la différence entre WSDL (description formelle) et UDDI (registre de services).
• Comprendre le rôle de la scalabilité dans les architectures REST et cloud.
• Vérifier la compréhension des principes fondamentaux des systèmes distribués pour leur déploiement efficace.