Plan de la séquence

Graphe de ressources liées décentralisé

Ressources

• Documents (statiques)
• Consultation dynamique :
  • ressources issues d’applications (dynamiques)
  • représentation de ces ressources dans les navigateurs Web
• Éléments « virtuels » décrivants des « faits » (Web sémantique/des données)

Ressources liées

• Identification des ressources
• Localisation des ressources
• Agréger des ressources et leurs donner des propriétés pour créer de la connaissance

Décentralisé

• Lier entre-elles des ressources localisées physiquement n’importe où sur Internet
• Confiance, provenance ?

Structure générale

Architecture Client-Serveur

Protocole très simple :

1. requête
2. réponse

Client et serveur Web

En fait : 1 client - n serveurs (modèle distribué)

Dialogue entre client et serveur

• Communication en 3 étapes simples :
  1. Le client (navigateur) fait une requête d’accès à une ressource auprès d’un serveur Web selon le protocole HTTP
  2. Le serveur vérifie la demande, les autorisations et transmet éventuellement l’information demandée
  3. Le client interprète la réponse reçue (et l’affiche)
• On recommence pour des ressource complémentaires (images, …).

Concepts de base d’HTTP

• Interaction avec des ressources hypertexte :
  • Quoi : Action : verbe (CRUD)
  • Qui : Ressources identifiées par des URI (données d’une application, …)
  • Où : URL pour localiser les représentations informatiques de ces ressources (documents hypertextes, images, etc.) sur des serveurs Internet
  • Comment : Requêtes protocole de communication HTTP

Construction de la toile (Web)

• Graphe de ressources hypertexte/hypermedia décentralisé
• Les ressources référencent d’autres ressources (attribut href dans HTML)
• Les liens sont unidirectionnels
• Aucune garantie de disponibilité, cohérence
• Parcourir la toile :
  1. trouver les liens,
  2. accéder aux ressources liées
  3. enrichir le modèle applicatif
  4. recommencer …

Localisation des ressources

• Objectif : nommer, localiser et accéder à l’information
• Solution : URL (Uniform Resource Locator) : identification universelle de ressource composée de 3 parties :
  1. le protocole (comment)
  2. l’identification du serveur Web, le nom DNS (où)
  3. l’emplacement de la ressource sur le serveur (quoi)

Interopérabilité ?

• Qui peut créer des clients Web ?
• Qui peut opérer des serveurs ?

Déploiement DIY

• Raspberry Pi
• Fibre
• Debian GNU/Linux
• Apache / Nginx
• …

Déploiement Cloud

Plan de la séquence

Architecture ?

• Structure générale d’un système informatique
  • matériel
  • logiciel
  • humain / responsabilités
• Conception
  • Normes ?
  • Standards ?
  • Bonnes pratiques ?

À l’origine, applications BD + Web

Les applications produisent des pages Web dynamiques, à partir de données issues de bases de données.

On décore le SGBD avec des pages qui génèrent des requêtes.

Succès historique des applications BD + Web

Des applications sont réalisables facilement, dès que des programmes génèrent des pages HTML en fonction des requêtes HTTP du client

Pour « M / Mme Michu », quand même plus convivial…

… que SQL !

Avantages

• Base de données gère l’intégrité des données (transactions, accès multiples, intégrité référentielle, …)
• Tient la charge (tant qu’on arrive à dupliquer l’exécution des scripts)
• Large gamme de choix du langage de programmation

Architecture 3 tiers

Architecture logicielle en couches (tiers):

• couche de présentation ;
• couche de traitement ;
• couche d’accès aux données.

Simplification de l’approche générale d’une architecture à plusieurs niveaux (multi tier)

Variante ligne de commande

Application Symfony Todo (cf. TP), en ligne de commande :

présentation

affichage sortie standard

traitement

App\Command\ListTodosCommand

accès aux données

Doctrine + SQLite (SQL)

Variante « classique » sur le Web

Classique : éléments logiciels principalement côté serveur (y compris présentation)

3 couches des applications Web

• Présentation : pages HTML :
  • serveur les construit (classique)
  • client (navigateur) les charge et affiche
• Traitements : programmes :
  • serveur Web (dialogue HTTP, invocation des applications)
  • serveur d’applications (exécute des programmes PHP, par ex.)
• Accès aux données : SGBD

Développer aujourd’hui une appli « classique » ?

Dans ce cours, on concevra l’application de façon traditionnelle, en 3 couches.

On utilisera le cadriciel (framework) Symfony pour son approche orienté objet.

Dans le cours, on va se concentrer principalement sur l’apprentissage de la conception des couches :

1. présentation (frontend)
2. traitements et accès aux données (backend)

L’accès au données est considéré comme déjà acquis (SGBDR, SQL).

Architectures modernes, pédagogie…

On pourrait apprendre d’autres architectures plus modernes laissant une plus grande place aux composants sur le client (Javascript, serverless, etc.). Apprentissages complexes vue le temps imparti.

Objectif pédagogie ! Faciliter les apprentissages, donc architecture plus classique facilite la tâche.

Web comme plate-forme

Les technos du Web ne concernent plus seulement les « sites » vus dans un navigateur sur un PC

Importance du côté client :

• Navigateur
  • Moteur de rendu HTML
  • Machine virtuelle Javascript
• Applications natives programmées HTML5 + CSS + Javascript sur mobile
• Client HTTP + (micro) services REST

Native apps vs Web apps

Take away

• Structure de la toile
  • Ressources
  • Ressources liées
  • Décentralisé
• Protocole client-serveur, HTTP, URL
• Applications générant des pages Web
• Modèle de couches (3 et +)
  • présentation
  • traitement
  • accès aux données

Crédits illustrations et vidéos

Figures interactives

On utilise un export HTML d’une illustration réalisés avec https://www.diagrams.net/ (moteur OpenSource de draw.io).

Copyright

• Document propriété de ses auteurs et de Télécom SudParis (sauf exceptions explicitement mentionnées).
• Réservé à l’utilisation pour la formation initiale à Télécom SudParis.