Introduction aux Systèmes Basés sur le Web PDF

Architecture Orientée Services Chapitre 1 : Introduction aux systèmes basés sur le Web 1 Année universitaire : 2024-2025  Plan ❖ Fonctionnement du Web ❖ Historique d’évolution du Web ❖ Technologies liées au Web ❖ C...

Architecture Orientée Services Chapitre 1 : Introduction aux systèmes basés sur le Web 1 Année universitaire : 2024-2025  Plan ❖ Fonctionnement du Web ❖ Historique d’évolution du Web ❖ Technologies liées au Web ❖ Contexte de communication ❖ Paradigmes des architectures logicielles ❖ Le terme Service ❖ Middlewares ❖ Service Web ❖ Principes d’un service Web ❖ Avantages des services web 2 Fonctionnement du Web ❏ Communication entre un serveur et un client Requête Réponse ❏ Le Web est désormais indispensable pour accéder à l'information, établir des communications et interagir avec divers services en ligne à l'échelle mondiale. 3  Historique d’évolution du Web Page web statique Les pages web statiques sont stockées sur le serveur sous la forme Début 1990 d'un fichier HTML distinct. ❏ Contenu Fixe ❏ Aucune interactivité ❏ Les mises à jour nécessitent des modifications manuelles du document HTML correspondant. demande une page web Navigateur web Serveur Web retourne une page web Les pages web dynamiques dont le contenu est généré à la volée, en Page web dynamique 1995 fonction des données et des actions des utilisateurs. ❏ Contenu dynamique ❏ Interaction basique (ex : formulaire de contact, forums) ✓ Exemple : sites e-commerce, blogs 4  Historique d’évolution du Web Le Web 2.0 a marqué un tournant majeur vers des applications Web Applications web basées sur le navigateur, exploitant des technologies comme JavaScript Fin des années 1990 et Ajax. ❏ Interface utilisateur riche ❏ Interaction et collaboration en temps réel ❏ Partage de contenu ✓ Exemple : Gmail, Facebook Le terme service web fait référence à une technologie permettant à des Service Web applications de communiquer entre elles via le Web en utilisant des 2000 protocoles standardisés et des normes ouvertes telles que HTTP, XML et JSON, qui sont faciles à manipuler par les machines.. ❏ Interopérabilité ❏ Fonctionnalités exposées via des APIs accessibles sur le web. ❏ Composition d’applications ✓ Exemple : API Google Maps, API Stripe 5 Standards liées au Web 6 ❏ Les standards liées au Web comprennent des formats de données tels que HTML, XML et JSON pour structurer et échanger des informations. ❏ Le transfert de ces données est réalisé via les protocoles HTTP et TCP, utilisant des URI/URL pour localiser les ressources. ❏ Les requêtes et réponses HTTP sont organisées selon une structure spécifique, et les méthodes HTTP permettent d'effectuer différentes actions sur les ressources du Web. 7  Formats d'échange de données sur le Web ❑ TEXT ❑ HTML (HyperText Markup Language): Langage de base du Web pour la création de pages web. ❑ XML (eXtensible Markup Language): Langage de balisage utilisé principalement pour la structuration et l'échange de données. ❑ JSON (JavaScript Object NFormat léger et lisible pour l'échange de données structurées. Utilise des paires "clé : valeur".otation): 8  Protocole de communication TCP vs HTTP ❏ TCP (Transmission Control Protocol) est un protocole de la couche de transport qui assure une communication fiable et orientée connexion entre les appareils sur un réseau. ❏ HTTP (Hypertext Transfer Protocol) est un protocole de la couche application qui s'exécute au-dessus de TCP (ou d'autres protocoles de la couche de transport) et régit le transfert de ressources hypertexte (web) entre les clients et les serveurs sur le World Wide Web. 9  Protocole de communication TCP vs HTTP ❏ HTTP s'appuie sur TCP pour assurer un transport fiable des données entre les navigateurs et les serveurs web. 10  HTTP: Méthodes ❏ Les méthodes HTTP spécifient l'action à effectuer sur la ressource: GET — Obtenir des informations à partir d'un serveur Web. POST — Soumettre des données au serveur Web et potentiellement créer de nouveaux enregistrements. PUT — Mettre à jour une ressource existante avec de nouvelles données. PATCH — Mettre à jour une partie d'une ressource existante, sans modifier l'intégralité de la ressource. DELETE — Supprimer des informations/enregistrements d'un serveur Web. 11 HTTP: Méthodes HEAD — Récupérer les en-têtes de réponse d'une ressource, sans le corps de la réponse. - Souvent pour vérifier si une ressource existe ou a été modifiée depuis la dernière demande. - Exemple: vérifier si une image est toujours disponible sur un serveur externe. OPTIONS — Découvrir les méthodes HTTP prises en charge par une ressource. - Cela permet au client d'adapter ses requêtes ultérieures en fonction des actions possibles sur la ressource. - Exemple: Un client qui rencontre une ressource pour la première fois. 12  HTTP: Structure de Requête La requête HTTP est composée de trois parties principales : Ligne de Requête — Indique la méthode HTTP, l'URL de la ressource demandée et la version du protocole HTTP. En-têtes de Requête — Fournissent des informations supplémentaires sur la requête, telles que le type de contenu, les cookies, etc. Corps de Requête (facultatif) — Contient des données envoyées au serveur généralement utilisé avec les méthodes POST, PUT et PATCH). 13  HTTP: Structure de Réponse La réponse HTTP est aussi composée de trois parties principales : Ligne de Statut — Indique la version du protocole HTTP, le code du statut HTTP et sa description. En-têtes de Réponse — Fournissent des informations supplémentaires sur la réponse, telles que le type de contenu, la date de dernière modification et les cookies. Corps de Réponse (facultatif) — Contient le contenu demandé par le client, généralement du HTML, des images, des vidéos ou des données JSON. 14  HTTP: Structure de Réponse Les codes de Statut HTTP: Les codes de statut HTTP indiquent le résultat de la requête. Ils sont divisés en cinq catégories : 1xx (Informationnel) — La requête a été reçue et le 4xx (Erreur Client) — La requête contient une processus est en cours. mauvaise syntaxe ou ne peut être satisfaite. Exemple: 100 Continue Exemple: 400 Bad Request | 401 Unauthorized | 2xx (Succès) — La requête a été reçue, comprise et 404 Not Found acceptée. 5xx (Erreur Serveur) — Le serveur a échoué à Exemple: 200 OK | 201 Created | 204 No Content satisfaire une requête valide. 3xx (Redirection) —Des actions supplémentaires doivent Exemple: 500 Internal Server Error être prises par le client pour terminer la requête. Exemple: 302 Found | 304 Not Modified 15  URL vs URI Tous les URL sont des URI, mais tous les URI ne sont pas des URL. ❏ URI (Uniform Resource Identifier) : - Offre un moyen général d'identifier des ressources sur le Web ou dans un réseau. - Il peut s'agir d'une page web, d'une image, d'une vidéo, d'un fichier ou de tout autre type de ressource accessible via un protocole réseau. - Peut utiliser différents protocoles (HTTP, FTP, HTTPS, etc). ❏ URL (Uniform Resource Locator) : - Un type spécifique d’URI. - Spécifiquement conçue pour localiser des ressources web via HTTP. - S'agit de l'adresse la plus courante utilisée pour accéder aux pages web sur Internet. 16  Contexte de communication Human-centric web ▪ Le Web centré utilisateur implique que l’humain est l’acteur principal pour l’initialisation de l’ensemble des requêtes B2C Business ToConsumer Inter net Utilisateur Application Application-centric web ▪ Le Web centré application a pour objectif de permettre à des organisations de communiquer entre elles B2B Inter Business To net Business Application Application 17  Contexte de communication Historique Source: https://www.ibisc.univ-evry.fr/~tmelliti/cours/CPAR/cours6.pdf 18  Contexte de communication Exemple B2B contrat Compagnie aérienne Chaîne hôtelière Internet Application de l’agence de voyage Agence de location des voitures 19 19  Paradigmes des architectures logicielles Le terme de paradigme est employé pour exprimer la façon dont un système a été conçu et pensé dans ses grandes lignes. Objectif: Développer une application de facturation 20  Paradigmes des architectures logicielles ❏ Les révolutions informatiques coïncident généralement avec un changement de paradigme. ❏ Niveau d’abstraction grandissant avec l’évolution des paradigmes 21  Paradigmes des architectures logicielles Paradigme procédural ❏ le code est organisé en procédures (ou fonctions) qui contiennent des séquences d'instructions. Ces procédures sont appelées successivement pour accomplir une tâche spécifique. ❏ Un Système informatique désordonné Limites : ❏ Tend à générer ducode "Spaghetti" ❏ Maintenance complexe ❏ Modularité et abstraction absente ❏ Réutilisation ardue 22  Paradigmes des architectures logicielles Paradigme objet ❏ L'idée est de concevoir les programmes non plus comme des lignes de codes qui s'exécutent séquentiellement, mais comme des objets qui dialoguent ❏ Ses principes incluent l'abstraction encapsulation,de données, polymorphisme et héritage. Limites : ❏ Réutilisation difficile ❏ Couplage fort ❏ Problème de maintenance 23  Paradigmes des architectures logicielles Paradigme composant ❏ Construire une application composée par un ensemble de briques de base configurables et réutilisables. ❏ Il s'agit d'externaliser le code fonctionnel d'une application afin de le rendre réutilisable dans d'autres applications Limites : ❏ Complexité de gestion des dépendances Composant ❏ Interopérabilité entre composants hétérogènes Objet 24  Paradigmes des architectures logicielles Paradigme service ❏ Prise en charge de la diversité et de l’hétérogénéité des termes de langages systèmes de programmation, et de logiciels, en de technologies de conception Service (et de réalisation) ou de plates-formes d’exécution ❏ Le paradigme service permet de: Composant réduire le couplage améliorer la réutilisation augmenter l’abstraction Objet 25 Le terme Service 26  Définition Un service est un terme général utilisé en informatique pour décrire une unité autonome de fonctionnalités qui peut être exécutée de manière indépendante. Il possède une interface pour la communication et l'interaction avec un demandeur de service. Les services peuvent être à la fois locaux ou distants : ✓ Locaux: s'exécutent sur la même machine que l'application qui les consomme ou bien en internes à une organisation comme les services système ou d’application de bureau; ✓ Distants: existent sur le Web et peuvent s'exécuter sur des machines différentes ou être hébergés dans le cloud comme les services web ou cloud. 27  Middlewares : intergiciel Un logiciel servant d'intermédiaire entre d'autres logiciels Un intermédiaire de communication entre des applications complexes et distribuées Le middleware joue un rôle essentiel en simplifiant la communication et l'intégration entre applications, services ou composants logiciels dans un environnement distribué. Il agit comme une couche d'abstraction, permettant aux différents éléments du système de travailler harmonieusement ensemble, indépendamment de leurs différences techniques, langages de programmation ou plates-formes de développement. 28  Middlewares : intergiciel Rôles de base d’un middleware: ▪ Résoudre l’intéropérabilité : Unifier l’accès à des machines distantes ▪ Résoudre l’hétérogénéité : Etre indépendant des systèmes d’exploitation et du langage de programmatio des applications 29  Middlewares : intergiciel Solutions existantes: – DCOM, –.NET Remoting Middlware.Net – RMI (Remote Method Invocation) Middlware Java permet de faire communiquer des objets java distribués sur le réseau – CORBA (Common Object Request Broker Architecture) Permet de faire communiquer des objets écrits dans des langages différents (C++, Java, Smalltalk) – Quels sont les atouts d’une meilleure solution? ? Requête Web Réponse Application A Application B 30  Services Web Service web = service + web Un service Web met à disposition un service via Internet Un SW est un programme informatique, permettant la communication et l'échange de données entre applications et systèmes hétérogènes dans des environnements distribués. Les services Web interagissent à travers l’échange de messages 31  Services Web Il constitue ainsi une interface permettant à deux machines (ou applications) de communiquer. Pour y parvenir, la technologie doit disposer de deux propriétés essentielles : - être multiplateforme : il n’est pas nécessaire que le client et le serveur aient la même configuration pour pouvoir communiquer. Le service Web leur permet de se retrouver à un même niveau. - être partagée : dans la plupart des cas, un service Web est à disposition de plus d’un client. Différents clients accèdent à ce service via Internet. 32  Service Web VS API Tout service web est une API (Interface de Programmation d'Applications) Tout API n’est pas un forcément un service web ( l'inverse n'est pas toujours vrai) ❑ Une API est une interface qui permet à ❑ Un service web (API web) est un type différentes applications ou systèmes de spécifique d'API qui utilise des protocoles communiquer entre eux. web pour permettre la communication entre machines sur un réseau, ❑ Les API ne nécessitent pas forcément généralement Internet. d'utiliser le réseau ou Internet. ❑ Fonctionnent sur des machines différentes, souvent via Internet ou un réseau interne. 33  Famille de Services Web ❑Il existe deux grandes familles de services web: Les services web étendus utilisant les standards: SOAP pour la communication ; UDDI (annuaire) pour la publication ; WSDL (contrat) pour la description Les services web REST utilisant : Directement HTTP au lieu d’une enveloppe SOAP ; Un URI pour nommer et identifier une ressource ; Les méthodes HTTP (POST, GET, PUT et DELETE) pour effectuer les opérations de base CRUD 34  Services Web : REST / SOAP REST SOAP Structure de Fixé par le serveur Fixé par le serveur réponse Format de données JSON, XML, TXT, HTML XML P. Transport HTTP HTTP, SMTP, FTP P. Communication HTTP SOAP Méthodes GET, POST, PUT, Noms opérations DELETE Contrat WADL (optionnel) WSDL (obligatoire) standardisé  Principes d’un service Web Auto-description(Contrat standardisé) Modularité Autonomie Couplage lâche Sans état(Stateless) Service Abstraction Découvrable Réutilisabilité Composable Interopérabilité 36  Principes d’un service Web ⮚Auto-description (Contrat standardisé) L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation. ⮚Abstraction Le service fonctionne en « boîte noire » Seul le contrat du service (informations nécessaires pour l’invocation) est exposé au consommateur du service. Le fonctionnement interne du service (sa logique métier et son implémentation) n’est pas visible. 37  Principes d’un service Web Couplage lâche ⮚Dépendance faible entre le consommateur et le service Dépendance du contrat et non pas de l’implémentation; Echange à travers des messages; Orchestration qui assure l’indépendance des services vu qu’elle leur permet de communiquer pour réaliser un processus, sans avoir à se connaître 38  Principes d’un service Web ⮚ Autonomie Un service ne doit être dépendant d'aucun contexte ou service externe: - Son comportement est indépendant du contexte fonctionnel et technique dans lequel il a été invoqué. ⮚Stateless Un service ne stocke pas les informations des clients: - Ne stocke pas de données; - Ne fait référence à aucune transaction passée. 39  Principes d’un service Web Composable ⮚Un service peut participer à des compositions de services Un ensemble de services peuvent être composés à travers leur orchestration pour répondre à un besoin complexe; Avantage: Apport de valeur ajoutée (répondre à un nouveau besoin complexe) 40  Principes d’un service Web Modularité La modularité est matérialisée par le fait que les différents services sont indépendants les uns des autres dans la plateforme de services et peuvent être accessibles par les applications distantes tournant dans des environnements hétérogènes. D’où la notion d’interopérabilité. Interopérabilité Réfère à la capacité d’un système à coexister et à coopérer avec d’autres systèmes éventuellement hétérogènes selon un schéma ouvert d'interconnexion. ✔Langages de programmation différents, ✔SGBD différents, ✔ Architectures différentes, ✔etc. 41  Principes d’un service Web Intégration vs Interopérabilité – Integration means that you've writtensome custom code to connect two (or more) systems together. [Bobby Wolf – IBMArchitect] Lorsqu'on parle d'intégration, nous pensons au processus qui fait que différents systèmes d'information apparaissent comme un seul. 42  Principes d’un service Web Intégration vs Interopérabilité – Interoperabilité Integration Source: http://modelseverywhere.wordpress.com/2010/11/04/model-driven-integration/ 43  Avantages des services web ⮚ Offrir une technologie adaptée aux applications B2B; ⮚ Rendre possible et plus facile l’interconnexion et l’interaction des systèmes et composants hétérogènes; ⮚ Utilisés par le Web Sémantique pas seulement le web interactif ⮚ Garantir l’interopérabilité et donner lieu à des systèmes plus ouverts que ceux utilisant des protocoles tels que RPC, DCOM, RMI… ; ⮚ Réutilisables dans un environnement ouvert; ⮚ Garantir un couplage lâche. 44  A retenir Protocoles Contrat B2B/B2C internet Services Web intégration Middleware URI/URL Modulaire Interopérabilité 45  Références http://fr.wikipedia.org/wiki/Paradigme https://www.coursera.org/learn/service-oriented-architecture/ http://design-patterns.fr/introduction-a-la- programmation-orientee- objet http://fr.wikipedia.org/wiki/Middleware http://blog.xebia.fr/2009/04/29/soa-du-composant- au-service-lautonomie https://www.ibisc.univ-evry.fr/~tmelliti/cours/CPAR/cours6.pdf http://adslbox.free.fr/rapports/rapport-gl-service-oriented-architecture.pdf http://deptinfo.unice.fr/~baude/WS/cours_SOA_AO+FB.pdf 25