docPrincipes de la programmation BD et Web
download 
Plainte Transcription
Principes de la programmation BD et Web
INT EVRY WWW - Intérêts du Web client universel facilité d'emploi standards ouverts intégration des autres services Internet extensibilité du système faibles coûts logiciel et réseau utilisation au sein d'une entreprise (Intranet) Web est une BD mais sans schéma sans langage de requêtes sans transactions, concurrence, reprise, … sans mécanismes d’autorisation sophistiqués De nombreuses données stockées dans des SGBD doivent être publiées sur le web Transformer les BD en ensembles de pages statiques Simple Redondance, problème de cohérence Désavantages du web Besoin de générer des pages web dynamiques à partir du contenu des BD 1 INT EVRY url HTTP server CGI query string Html result Browser (client) SQL HTML Simple et portable Beaucoup de code à écrire (un CGI par requête!): peut être amélioré par des solutions génériques Pas très efficace DBMS ! ! Client 1 Client 2 Client 3 Process 1 Process du serveur C G I Serveur W3 Process 1 Process 1 Scripts CGI Client 1 " Serveur W3 API Client 2 Client 3 Process ensemble du serveur de fonctions Thread 1 Thread 2 Thread 3 les scripts CGI deviennent des fonctions d'une librairie dynamique DLL, exécutées dans des thread du process serveur W3 2 INT EVRY # Genre de script CGI persistant (démon) script décomposé en 3 parties : initialisation : une fois corps : à chaque requête terminaison : une fois WWW –limitations Web performances Internet => augmenter la bande passante scripts CGI => FastCGI, scripts serveurs sécurité HTTP => S-HTTP TCP/IP => protocole SSL initialisation doit inclure le code coûteux (connexion à une BD, …) bien adapté à un accès BD, mais une fois lancé est persistant WWW –Limitations Web (2) Transactions Pas possible avec HTTP 1.0 Pas de mode session Utilisation des "cookies" Possible avec HTTP 1.1 Permet des connexions persistantes (TCP) # $% (1) décodage de la requête http (passage var. environnements vers SQL) (2) exécution de la requête sur le SGBD (3) formatage HTML du résultat interface Utilisateur HTML pas très puissant pour construire des IHM sophistiquées Java est plus adapté 3 INT EVRY &$ ' ( ) * *+, $ Solution générique (et automatisable) : Programme écrit avec une interface BD solution dépendante du SGBD solution indépendante du SGBD (ODBC, JDBC ou DBI pour Perl) Langages de programmation utilisables classiques : C, C++, Ada, … si embedded SQL Perl (avec DBI) select : tableau HTML autre requête : chaine de caractères Solution spécifique : codage spécifique pour chaque requête dans la passerelle (une passerelle / requête !) dans le SGBD (procédure stockée) Solution intermédiaire : paramétrisation du résultat (formulaire de mise à jour, parcours hypertexte d ’une BD ,…) " % -. url / Serveur HTTP résultat html Client browser CGI query string rés. HTML SQL résultat Passerelle SGBD <html><body> <form name="f1" action="http://mica/multi2.cgi" method="get"> <input type="hidden" name="uid" value="citcom/citcom@MICA"> <input type="hidden" name="sqlstatement" value="select * from vins where cru="> Donner un cru : <input name="vcru" value=""> <p> <input type="submit" value="lancer"> </form> </body></html> 4 INT EVRY " % url / Serveur HTTP query Passerelle string résultat html rés. HTMLSQL Client browser résultat SGBD " % -. . / <html><body> <form name="f1" action="http://mica/multi2.cgi" method="get"> <input type="hidden" name="uid" value="citcom/citcom@MICA"> <input type="hidden" name="sqlstatement" value="select * from vins where cru="> Donner un cru : <input name="vcru" value=""> <p> <input type="button" value="lancer" onClick="f1.sqlstatement.value+=f1.vcru.value; f1.submit();"> </form> </body></html> ) 0 SGBD protocole spécifique (1) (2) (3) cgi passerelle ou HTML pur spécifique SGBD SGBD Client browser + programme Java, Tcl, ... script client client SGBD passerelle ou SGBD protocole spécifique : JDBC, IIOP (CORBA) hors http SGBD client 5 INT EVRY 1 0 dépendance / indépendance par rapport au SGBD (natif ou ODBC) langage de requêtes supporté (SQL ou un sous-ensemble, statique vs dynamique) formattage du résultat (personnalisable ou non) performances + 2 CGI vers NSAPI, ISAPI (mais propriétaire) diminuer le nombre de processus (si grand nombre de clients : passerelle multithread & transaction = programme BD (séquence de lire, écrire) propriétés = ACID A : Atomicity C : consistency I : Isolation D : Durability ' commandes on-line (vente par correspondance, train, avion, ...) banque assurance une bonne partie du e-business!!!! 6 INT EVRY + + Transaction = séquence d’invocations url (gestion du contexte par le web?) Transaction = propriétés ACID (assurées par le SGBD) HTTP = pas de support de session gérer le contexte côté client (cookies) simuler des sessions http (web transactionnel) supporter un langage avec un run-time côté serveur (PHP, ASP, JSP, ...) + 3 -4/ Contexte est géré chez le client (cookies) avantages : simplicité de la mise en œuvre accès en maj de la BD se fait en une fois à la fin (pas de ressources bloquées) si pas de terminaison de la transaction par l ’utilisateur, rien à faire 3 Client browser cgi Serveur http 1 1 1’ c1 2 c1 2’ c1, c2 3 fin c1, c2 5’ del(c1, c2) 1’ c1 2 c1 2’ c1, c2 3 fin c1, c2 5’ del(c1, c2) 4’ ok 1 : premier accès 4 sql(c1, c2) 1’ : retour du cookie c1 2 : autre accès avec transport du cookie c1 2’ : retour des cookies c1, c2 3 : fin transaction avec transport c1, c2 4 : construction de la transaction et exécution sur le SGBD 5’ : suppression des cookies SGBD + 3 -5/ Inconvénients pas vraiment transactionnel fonctionnalité limitée beaucoup de cgi à écrire (sauf programme de maj générique qui prenne une séquence d ’instructions SQL en entrée) Problèmes des cookies global à l ’utilisateur (pas de différenciation entre fenêtres) global à une url (pas deux transactions en même temps sur le même site) 7 INT EVRY Client browser # Serveur http cgi démon passerelle SGBD -6/ 1 : demande de création de transaction (implicite ou explicite) allocation d ’un idf par le démon, maj de la table des transactions, lancement d ’une passerelle, renvoi de l ’idl au client (cookie ou variable) Contexte géré par un démon côté serveur besoin d ’un identifiant de transaction stocké côté client (cookie ou variable selon client) et côté démon (dans une table) passerelle ne traite pas une seule requête mais toute une transaction (plusieurs requêtes) # -4/ 3 : terminaison de la transaction implicite : plantage, timeout explicite : idem 2 + maj de la table des transactions, annulation de l ’idf côté client et arrêt de la passerelle 2 : demande d ’opérations sur la BD routage de la demande par le démon sur la bonne passerelle en utilisant l ’idf et sa table 8 INT EVRY ' Avantages vraiment transactionnel solution générique Inconvénients architecture complexe blocage des ressources nécessité de détecter un « abandon » de l ’utilisateur (timeout) Offrir un langage de programmation intégré au Web (possibilité de faire des appels depuis une page Web, support par le serveur HTTP) run-time du langage offre un support de session (donc de transactions) PHP, servlet - JSP, ASP, XSP (Cocoon) 9
