SUP24

RAPPORT DE PROJET DE FIN DETUDES
Filire Ingnieurs des Travaux
Etude, Conception et ralisation dune plate-forme de tl-facturation tlphonique journalire

Elabor par :
Taghlet Moez Barhoumi Mourad

Encadr par :
Mr Bouallgue Ridha
Anne universitaire : 2001/2002
DEDICACES
Nous ddions ce prsent travail A nos trs chers parents, A nos femmes et enfants, A nos frres et surs, A tous nos amis.
REMERCIEMENTS
Nous tenons prsenter nos sincres remerciements et notre profonde gratitude toutes les personnes ayant contribues de prs ou de loin la ralisation de notre projet de fin dtudes. Nos remerciements vont particulirement notre encadreur Monsieur BOUALLEGUE Ridha, notamment nos chers collgues Keyssi Slaheddine , Nasri Imed et Farah Slaheddine pour leurs soutien moral et technique. Ce que nous ressentons de joie et de fiert en fin danne ne peut sexprimer que par une seule phrase : Merci ceux qui taient, et sont encore prs de nous, nous guider pour un avenir russi
Liste des tables
Page : Table 2.1 : Enumration des entits de la base de donnes tl facturation--------------- 27 Table 5.1 : Les mthodes http ---------------------------------------------------------------------- 48 Table 5.2 : Informations envoyes par le client ------------------------------------------------- 48 Table 5.3 : Les codes de rponses http ------------------------------------------------------------- 49 Table 5.4 :Les enttes de rponses http ------------------------------------------------------------ 49 Table 5.5 : Quelques types MIME les plus utiliss ------------------------------------------- 49 Table 6.1 : Variables CGI relatives la requte ------------------------------------------------- 57 Table 6.2 : Variables CGI relatives la connexion --------------------------------------------- 57 Table 6.3 : Variables CGI relatives au serveur -------------------------------------------------- 57
Liste des figures

Page : Figure 1.1 : Rle du systme dinformation dans la cration de la base de donnes --- 10 Figure 1.2 : Systme daccs aux donnes ------------------------------------------------------- 12 Figure 1.3 : Les tapes de la conception dune base de donnes --------------------------- 14 Figure 2.1 : Reprsentation du modle hirarchique ------------------------------------------ 17 Figure 2.2 : Reprsentation du modle rseau -------------------------------------------------- 18 Figure 2.3 : Reprsentation du modle relationnel --------------------------------------------- 18 Figure 2.4 : Reprsentation du modle objet ---------------------------------------------------- 18 Figure 3.1 : Architecture de la solution propose ----------------------------------------------- 26 Figure 3.2 : Architecture de la solution ralisable ---------------------------------------------- 28 Figure 4.1 : Architecture fonctionnelle des SGBD-R ------------------------------------------- 34 Figure 5.1 : Exemple dune configuration client-serveur ----------------------------------- 44
Figure 5.2 : Reprsentation du protocole http -------------------------------------------------- 47 Figure 5.3 : Format de la ligne dtat dune rponse ------------------------------------------- 48 Figure 6.1 : Architecture de la solution propose ----------------------------------------------- 55 Figure 7.1 : Procd dadresse pour rseau dexploitation et de maintenance via X25 68 Figure 7.2 : Type de rseau et valeurs AFI, IDI et DSP associs ----------------------------- 69 Figure 7.3 : Diffrentes possibilits de connexion de linterface X25 ----------------------- 70 Figure 7.4 : Squence de gestion et dinstallation X25 ---------------------------------------- 69
SOMMAIRE
Page : Introduction gnrale : ------------------------------------------------------------------------------- 5 Cahier des charges de projet : ---------------------------------------------------------------------- 8 Chapitre 1 : Systme de donnes et problmatiques de la conception Introduction : -------------------------------------------------------------------------------------I-Notion de systme de donnes :--------------------------------------------------------------II- Varit dexpression au systme de donnes :-------------------------------------------III- Problmatiques de la conception :---------------------------------------------------------VI- Une conception par tapes :-----------------------------------------------------------------Conclusion : --------------------------------------------------------------------------------------Chapitre 2 : Conception dtaille de la base de donne ----------------------------------Introduction : --------------------------------------------------------------------------------------I-Objecrifs de ltape conceptuelle : -----------------------------------------------------------II- Principes et fondements de la conception : ---------------------------------------------II.1- Analyse : --------------------------------------------------------------------------------------II.1.1- Analyse du rel : ------------------------------------------------------------------II.1.2- Modlisation : ----------------------------------------------------------------------II.2- Modle conceptuel de donnes : --------------------------------------------------------II.2.1- Concepts de base : -----------------------------------------------------------------II.2.2- Qualits du modle conceptuel de donnes : -------------------------------II.2.3- Les diffrents modles de base de donnes : --------------------------------III-Le modle relationnel : -----------------------------------------------------------------------III.1- Les caractristiques du modle relationnel :-----------------------------------------III.2- Les concepts de base du modle :-------------------------------------------------------III.2.1- Domaine : ---------------------------------------------------------------------------III.2.2- Relation : ----------------------------------------------------------------------------III.2.3 -Attribut : -----------------------------------------------------------------------------III.2.4 -Cl et contrainte dintgrit : ---------------------------------------------------III.2.4.1- Contrainte dintgrit sur les cls : -----------------------------------III.2.4.2 -Contrainte dentit : -----------------------------------------------------III.2.4.3 -Contrainte rfrentielle : ------------------------------------------------III.3- Avantages et inconvnients du modle relationnel: ------------------------------III.3.1- Avantages : -------------------------------------------------------------------------III.3.2 -Inconvnients : ---------------------------------------------------------------------IV- Base de donnes du projet tl facturation : -------------------------------------------IV.1- Inventaire des entits et associations : -----------------------------------------------IV.2- Conceptualisation : ------------------------------------------------------------------------IV.2.1- Les relations de la base des donnes : ----------------------------------------IV.2.2 -Le modle relationnel des donnes : -----------------------------------------Conclusion : --------------------------------------------------------------------------------------9 10 11 13 13 14 15 16 16 16 16 16 17 17 17 17 19 19 19 19 19 19 20 20 20 20 21 21 21 21 21 21 22 24 24
Chapitre 3 : Architecture de la solution propose -------------------------------------------Introduction: --------------------------------------------------------------------------------------I- Architecture de la solution propose : ----------------------------------------------------II- Solution ralisable sur la maquette EWSD de lISETCOM : ------------------------III- Structure de base de la solution propose :---------------------------------------------III.1- Le client :--------------------------------------------------------------------------------------III.2- Le serveur Web : ----------------------------------------------------------------------------III.2.1- Le site Web: -------------------------------------------------------------------------III.2.2- Les modules de traitements : ---------------------------------------------------IV- Plan de navigation : --------------------------------------------------------------------------IV.1- Page daccueil : -----------------------------------------------------------------------------IV.2- Activation de linscription : --------------------------------------------------------------IV.3- Mise jour des renseignements: -------------------------------------------------------IV.4- Activation de la consultation : ----------------------------------------------------------IV.5- Consultation de la facture : --------------------------------------------------------------V- Modle de traitement : -----------------------------------------------------------------------V.1- Le modle requte-rponse: -------------------------------------------------------------V.2- Traitement des exceptions: ---------------------------------------------------------------Conclusion : --------------------------------------------------------------------------------------Chapitre 4 : Ralisation et implmentation de la base de donnes ---------------------Introduction : -------------------------------------------------------------------------------------I- Les SGBD relationnelles : -------------------------------------------------------------------I.1- Dfinition : ------------------------------------------------------------------------------------I.2- Fonctionnalits : -----------------------------------------------------------------------------I.3- Architecture et fonctionnement : -------------------------------------------------------I.4- Le langage SQL: -----------------------------------------------------------------------------I.4.1- Intrt de SQL: -----------------------------------------------------------------------II- Choix technique pour le projet : MYSQL ----------------------------------------------II.1- caractristiques de MYSQL : ------------------------------------------------------------II.2- Pourquoi a-t-on choisit MYSQL ? : ----------------------------------------------------II.3- Obtention : ----------------------------------------------------------------------------------II.3.1- Installation et compilation : ------------------------------------------------------III- Serveur MYSQL : ----------------------------------------------------------------------------III.1- Connexion au serveur MYSQL : ------------------------------------------------------III.2- Systme de droit et contrle daccs : ------------------------------------------------III.2.1- But : ----------------------------------------------------------------------------------III.2.2- Noms dutilisateurs et mot de passe : ---------------------------------------III.2.3- Fonctionnement : -----------------------------------------------------------------III.3- Lancement du serveur MYSQL: -------------------------------------------------------III.4- Arrt du serveur : ------------------------------------------------------------------------IV- Programmation MYSQL : -----------------------------------------------------------------IV.1- Cration de la base de donnes PFE : ------------------------------------------------IV.2- Cration des tables de la base : --------------------------------------------------------IV.3- Test de la base : ---------------------------------------------------------------------------IV.4- Alimentation de la base : ---------------------------------------------------------------Conclusion : ---------------------------------------------------------------------------------------
25 26 28 29 29 29 29 29 29 29 30 30 30 30 30 30 31 31 32 33 33 33 34 35 35 36 36 36 37 37 37 37 38 38 38 38 39 39 39 39 40 41 41 42
Chapitre 5 : Serveur web et interfaces clients -------------------------------------------------Introduction : --------------------------------------------------------------------------------------I- Systme client : ----------------------------------------------------------------------------------I.1- Performances des applications orientes Web : --------------------------------------I.2- Dveloppement Web cot client : --------------------------------------------------------I.3- Utilisation des formulaires : --------------------------------------------------------------I.4- Les formulaires HTML : --------------------------------------------------------------------II- Le protocole http : -----------------------------------------------------------------------------II.1- Requte http : --------------------------------------------------------------------------------II.2- Rponse http : --------------------------------------------------------------------------------III- Le serveur Web : ------------------------------------------------------------------------------III.1- Principes et fonctionnement : -----------------------------------------------------------III.2- Performances dun serveur Web : ------------------------------------------------------III.2.1- .1- Excution des scripts et autres programmes:---------------------------III.2.2- compression et cryptage des donnes: ---------------------------------------III.2.3- Accs aux donnes: ---------------------------------------------------------------IV- Choix technique : APACHE ---------------------------------------------------------------IV.1- Pourquoi APACHE ? ----------------------------------------------------------------------IV.2- Installation : ---------------------------------------------------------------------------------IV.3- Configuration : ------------------------------------------------------------------------------IV.4- Dmarrage du serveur APACHE : -----------------------------------------------------V- Scurit du serveur APACHE : ------------------------------------------------------------Conclusion : --------------------------------------------------------------------------------------Chapitre 6 : Interface Web- base de donnes ----------------------------------------------Introduction : --------------------------------------------------------------------------------------I- choix techniques : CGI ------------------------------------------------------------------------I.1- Dfinition :--------------------------------------------------------------------------------------I.2- Spcification : ---------------------------------------------------------------------------------I.3- Installation : -----------------------------------------------------------------------------------I.4- Normalisation des CGI : -------------------------------------------------------------------I.4.1- Variables relatives la requte : --------------------------------------------------I.4.2- Variables relatives la connexion : ----------------------------------------------I.4.3- Variables relatives au serveur : ---------------------------------------------------I.4.4- Entres-sorties : -----------------------------------------------------------------------II- Le langage Perl : -------------------------------------------------------------------------------II.1- Pourquoi Perl ?-------------------------------------------------------------------------------II.2- Perl et CGI : -----------------------------------------------------------------------------------II.3- Accs aux base de donnes : -------------------------------------------------------------III- Aspect scurit : ------------------------------------------------------------------------------III.1- Aperu gnral : ----------------------------------------------------------------------------III.2- Comment se protger ? : ------------------------------------------------------------------IV- Organigrammes :------------------------------------------------------------------------------Conclusion : ---------------------------------------------------------------------------------------
43 44 44 45 45 45 47 47 48 50 50 50 50 50 51 51 51 51 52 52 52 53 54 56 56 56 56 56 56 57 57 58 58 58 59 59 59 59 60 60 66
Chapitre 7 : Installation et mise en service de linterface x 25 la maquette EWSD Introduction : --------------------------------------------------------------------------------------- 67 I- Prsentation du rseau OSI : ------------------------------------------------------------------ 68 II- Adresses didentification du terminal : ---------------------------------------------------- 68 II.1- Adresse X 25 : ---------------------------------------------------------------------------------- 68 II.2- Adresse DTE : ---------------------------------------------------------------------------------- 69 II.3- Adresse NSAP : ------------------------------------------------------------------------------- 69 III- Connexion directe (type de rseau X 25LC) : -------------------------------------------- 70 IV- Installation et procdure de gestion : ----------------------------------------------------- 71 IV.1- Cble IOP pour connexion directe (X25LC) : ----------------------------------------- 72 IV.2- Base de donnes pour la cration dun lien X25 : ------------------------------------ 72 V- Protocole FTP : ----------------------------------------------------------------------------------- 73 V.1- Prsentation : ---------------------------------------------------------------------------------- 73 V.2- Les commandes FTP : ----------------------------------------------------------------------- 73 V.2.1- Contrle daccs :------------------------------------------------------------------- 74 V.2.2- Paramtres de transfert : --------------------------------------------------------- 74 V.2.3- Services FTP : ---------------------------------------------------------------------- 74 V.3- Les rponses FTP :---------------------------------------------------------------------------- 74 Conclusion : --------------------------------------------------------------------------------------- 75 Conclusion gnrale : ----------------------------------------------------------------------------- 76 Bibliographie : ------------------------------------------------------------------------------------- 77 Glossaire : --------------------------------------------------------------------------------------- 78
Introduction gnrale
De nombreuses socits se lancent dans la vente de services de tlphonie, toutes ont besoin d'un service de facturation. Bons nombres doprateurs possdent le niveau ncessaire dans la vente et le marketing pour faire crotre leur base clients. Cependant, ils ne disposent pas toujours du niveau ou des ressources pour grer la facturation. Ds lors, toute l'attention porte cette fonction dtourne loprateur de son activit principale. La facturation tlphonique exige un systme fiable avec une capacit de croissance illimite. Ordinateurs et quipements d'impression ainsi que personnel entran techniquement sont les lments cls. La croissance du business ncessite l'augmentation adquate et rapide de ces capacits. Le financement pour obtenir et maintenir ces ressources est considrable et cela pour une opration ne durant pas plus que trois quatre jours par trimestre. En TUNISIE avec lapparition des systmes de commutation lectromcanique lide tait de photographier les compteurs mcaniques afin dviter lintervention humaine et en vue dassurer la confidentialit, puis les transmettre vers le centre de facturation pour traitement. Lvolution technologique nous a permet ensuite dinstaller les centres lectroniques qui traitent les compteurs de taxation dune faon logique et les sauvegarder dans les fichiers correspondants. Avec cette technologie on a eu loccasion de sauvegarder les fichiers de taxation sur un support magntique puis optique et de les envoyer chaque trimestre vers le centre de facturation pour le traitement ncessaire. Aller plus loin avec le dveloppement des systmes dexploitation de ces centres a dgag lavantage suivant :
Les centres lectroniques offrent la possibilit aujourdhui de transfrer les fichiers automatiquement en appliquant le protocole FTAM et en se connectant un rseau publique de donnes X 25 ou travers le rseau numrique intgration de service RNIS . A ce stade notre premier oprateur saligne avec la technologie de pointe et installe un serveur pour la collecte des fichiers de taxation ds les centres AXE et EWSD en premire phase, et de cette faon on a un service de facturation volu. Mais de nos jours les clients professionnels attendent plus qu'une simple facture. Il est courant aujourd'hui de fournir les dtails des factures sur CD ou via internet. Il est aussi essentiel de fournir des outils d'analyse ainsi qu'un service d'assistance lors de la fourniture de donnes lectroniques. Lorsque la base de clients est dordre important, la mise sous enveloppe et l'affranchissement des factures deviennent galement des tches majeures. Une facture imprime reste toujours une exigence et bien que la fourniture des dtails via Internet soit une ralit. Dans ce contexte ont a pens bnficier les clients de TUNISIE TELECOM dun service en ligne qui assure un accs linformation tout moment et tout lieu , afin de pouvoir matriser leurs consommation tlphonique et aussi de trimestre. Ce rapport prsente les principales facettes de ltablissement dune plate forme de tl facturation journalire tlphonique. Les objectifs de ce produit seront dtaills et les besoins tudis dans la partie consacre au cahier de charge et ses spcifications. La conception de la base de donnes en premier lieu puis celle du schma gnral de lapplication font objectif des trois chapitres suivants : systme de donne et problmatique de la conception (Chapitre 1), conception dtaille de la base de donnes (Chapitre 2) et architecture de la solution propose (Chapitre 3). de minimiser les problmes des retards de paiement des factures puisque les clients connaissent leurs montants ds la fin
Ensuite on va entamer la partie consacre aux dtails techniques du dveloppement et de lenvironnement de travail ainsi que sur les choix et dcisions sur la plate-forme et le processus dimplmentation : ralisation et implmentation de la base de donnes (Chapitre 4) tude, installation , configuration du serveur Web et interfaces clients (Chapitre 5), dveloppement des modules dinterface entre la base de donnes et le serveur (Chapitre 6), installation et configuration des interfaces X25 pour le transfert des fichiers de taxation de la maquette EWSD de lISETCom (chapitre 7).
Cahier des charges du projet du projet
Cahier des charges du projet
Pour mettre en uvre le projet de la plate -forme de tl facturation tlphonique en ligne, un ensemble de rgles et de contraintes fonctionnelles, technique et mthodologique sont exigs. Du point de vue fonctionnel, ce projet devra permettre aux clients de consulter leurs factures tlphoniques journalirement. Techniquement, lobjectif est de concevoir la base de donnes et dvelopper les modules qui permettent laccs l a base de donnes depuis le site Web. Chaque mthode de conception et outil de dveloppement utilis devra tre expliqu. La base de donnes ainsi que les modules seront implments sur une plate-forme technique ( Serveur de base de donnes, serveur Web, ). Finalement le dveloppement de ce produit doit suivre un cycle quatre phases : la conception, le dveloppement, limplmentation et les tests.
Notion de systme de donnes et problmatiques de la conception
Chapitre 1 Notion de systme de donnes et problmatiques de la conception
Introduction : La fonction essentielle de tout systme de donnes est de fournir ceux qui lutilisent des reprsentations appropries et pertinentes de la ralits quils ne sont pas en mesure dobserver directement. A cette fin, il convient de crer et de mmoriser des collections de donnes aussi reprsentatives que possible de la ralit en question et qui, exploites par des programmes de traitements appropris (des interfaces CGI dans notre cas), permettent de reconstruire les images de la ralit. Le projet de la tl facturation, fait intervenir plusieurs acteurs qui interagissent dune ou plusieurs faons avec des institutions et organisations de natures diffrentes (financire, juridique, administrative ) et dont ces interactions sont conditionns par un ou plusieurs facteurs. Dautre part, ce projet comme tout autre projet informatique, mobilise des ressources humaines, financires et techniques pour lesquelles ladoption dune dmarche de conception non solide serait source de gaspillage fatale. Lobjectif de ce chapitre est de dgager une mthode qui sera suivie lors de la conception de la base de donnes et qui sera dduite suite une tude et analyse des problmes qui seront rencontres et des objectifs attendus.
Notion de systme de donnes et problmatiques de la conception I- Notion de systme de donnes : Lorsque le systme dinformation est mis au point (fonctionnel), il contient une reprsentation des processus rels qui intressent lapplication, sous forme de collection de donnes qui sont mmorises dans la base de donnes. Nous admettons que les donnes de la base sont mmorises sur diffrents support de stockage et sont gres selon les techniques appropries. Mais avant de crer et faire fonctionner la base de donnes, un important travail de conception doit tre ralis qui aboutit au systme de donnes. Le systme de donnes peut se dfinir comme la description du contenu des collections de donns qui constitueront la base de donnes. Le systme de donnes illustre comment on devra reprsenter, par des donns, les types dinformation et des processus de traitements de ces informations qui sont pris en compte dans ce projet.
Phnomnes rels
Analyse et Inventaires des problmes
Le systme de donnes
Processus de la conception
La base de donnes
Figure 1.1 Rle du systme dinformations dans la cration dune base de donnes.
10
Notion de systme de donnes et problmatiques de la conception II- Varit dexpression au systme de donnes : La diversit des rles qui incombent au systme de donnes et des personnes qui ont lutiliser conduit souhaiter que lexpression du systme de donns ne soit pas unique. Ainsi, dans le cas dune application de tl facturation en ligne, ces intervenants se scindent en 4 catgories : La cible et le bnficiaire principal de ce service qui est labonn ( tel quil sera dfini dans la conception dtaille de son profil). Le gestionnaire administratif (Agence commerciale de tlcommunications, centre de facturation) qui intervient pour la mise jour des donnes et lexcution doprations diverses. Lensemble de lquipe des analystes et des programmeurs qui visent le dveloppement de nouvelles applications, la modification dapplications dj exploites, loptimisation des performances des programmes et scripts daccs aux donnes. Le responsable de la base de donnes et en gros du serveur de base de donnes qui amliore lorganisation de lensemble des donnes compte tenu de la totalit des applications.
11
1-Utilisateur sans systme informatique
MONDE REEL
Ensembles dentits et dassociations du monde rel
choix du concepteur 2- Utilisateur du systme informatique E/S DE LA BASE DES DONNEES Ensembles dentits et dassociations de la base
programmes dapplications
3- Programmeur dapplication
FICHIERS LOGIQUE
Ensembles des fichiers logiques vues les usagers (sous-schmas)
systme de gestion de la base
4- Administrateur de la base
ORGANISATION LOGIQUE GLOBALE
structure globale logique de la base (schma)
systme de gestion de la base ORGANISATION PHYSIQUE DE STOCKAGE
5- programmeur systme
structure physique de la base
Figure 1.2 : Systme daccs aux donnes
12
III- Problmatiques de la conception : Si lon tente de classer les problmes rencontrs dans la dfinition dun systme de donnes, on fait apparatre trois grandes facteurs : La reprsentation : elle concerne essentiellement lexpression de la smantique Quels sont les entits, objets, actions , qui seront reprsents dans la base de donns ? Par quels concepts ou combinaisons de concepts les reprsenter ? Par quelles donns traduire chaque concept ?
Lutilisation : ayant rpondre des demandes dinformation : Quel usage peut-on faire de la reprsentation ? Quel modle retenir pour structurer les donnes qui correspondent aux concepts ? Comment structurer la reprsentation de faon y parvenir ? Quels sont les cheminements et relations logiques quil faut privilgier dans lespace des donnes ?
Lexploitation : pour rpondre de manire oprationnelle aux demandes dinformations : quelle implantation des donnes assurera une exploitation satisfaisante ? quelle organisation des donns et que moyen daccs retenir ? comment assurer la scurit et la confidentialit des donnes ?
IV- Une conception par tape : Tous les problmes que nous venons dvoquer justifient que len systmatise la tche de conception en proposant une dmarche par tapes suivre pas pas. Des mthodes danalyse gnralement utilises pour concevoir les systmes dinformation, nous retenons surtout quil y a traiter sparment les problmes dits physiques et les problmes dits fonctionnels ou logiques. Ceci nous conduit un dcoupage du processus de la conception en 3 tapes successives : -Ltape conceptuelle : elle doit permettre une bonne reprsentation des faits pris en compte . -Ltape logique : elle doit assurer la dfinition de la solution o tous les conditions dusage des donnes ont t prises en compte.
13
-Ltape physique : elle doit aboutir lexpression dfinitive de la solution technique partir de laquelle la ralisation de la base de donnes devient possible.
monde rel
Spcification et analyse
Spcifications de la base
Conception Concept
Schma conceptuel
CONCEPTEUR
-------------------------------SGBD
Transformation et modle logique
-------------------------------
Schma logique Schma interne
Conception physique
Figure 1.3 : Les tapes de la conception dune base des donnes Conclusion : Llaboration dun systme de donnes repose sur la description et la classification naturelle rel pour aboutir un schma descriptif primaire, qui, par des transformations approfondies et analyse dtaille, permettront daboutir au schma conceptuel, objectif finale de la conception de la base de donnes. Une fois le processus de la conception est dfini par tapes en fixant les exigences diverses de cohrences, fidlit, extension, lobjectif est de sy baser pour aboutir une conception satisfaisante de la base de donnes relle qui sera dcrite par le schma du modle conceptuel des donnes.
14
conception dtaille de la base de donnes
Chapitre 2 Conception dtaille de la base de donnes
Introduction : On se propose de concevoir le schma conceptuel de la base de donnes permettant la reprsentation la plus fidle possible du processus de la tl facturation en ligne ( inscription et consultation), de faon en permettre une exploitation ultrieur par les modules de traitements.
15
conception dtaille de la base de donnes I Objectifs de ltape conceptuelle : Il sagit de traduire, par une structure de donnes, la smantique du rel que lon veut prendre en compte dans le systme de donnes et cela revient : Exprimer de manire formelle le rsultat du processus danalyse de la partie de la ralit considre. Exprimer ce rsultat au moyen de types, dans une dmarche structuraliste qui dbouche sur une reprsentation clair, explicite, cohrente et surtout condense de la varit des faits rels. Exprimer ce rsultat en toute abstraction de considration dordre technique quil conviendra dintroduire au moment de la ralisation. Il importe, en effet, ce stade dassurer l indpendance de la solution conceptuelle par rapport aux solutions ultrieures de la ralisation. Sans cette indpendance, on se priverait de choisir entre plusieurs solutions de ralisation quil est encore prmatur de dfinir. Exprimer, en sefforant de les intgrer, les multiples points de vue des utilisateurs. En effet, la varit des faits rels correspond aussi la diversit des attentes des diffrents utilisateurs qui auront accs la base de donns.
II- Principes et fondement de la conception : II .1- Analyse : II .1.1-Analyse du rel : Le monde rel est peru comme un systme abstrait. Ce systme abstrait se traduit par : des classes dentits, des proprits sur ces classes, des liaison entre ces classes. Le systme abstrait est dcrit par un schma conceptuel. II.1. 2-Modlisation : Principes gnraux respecter : Le schma conceptuel doit tre libre de toute considration non significative du systme abstrait (organisation physique des donnes, aspects particuliers un usager tels que des formats de messages). Tous les aspects du systme abstrait doivent tre dans le schma conceptuel aucun deux ne doit intervenir ailleurs en particulier dans des programmes dapplication indpendants du schma conceptuel.
16
conception dtaille de la base de donnes II.2- Modle conceptuel des donnes : II. 2.1- Concepts de base : Entit (exemple abonn), attribut(exemple nom), valeur de lattribut (exemple 01837516), association(liaison peru entre entits). II.2. 2- Qualits du modle conceptuel des donnes : Il importe que le schma du modle conceptuel des donns ait les qualits suivantes : Clart et simplicit : pour dcrire les faits, le schma conceptuel intgre des notions dont la signification nest pas ambigu et reste directement parlante. Cohrence : il ny a pas de contradictions ou confusion dans les reprsentations dun mme projet. Compltude : sans rechercher l exhaustivit, qui est dailleurs sans limites, la reprsentation rend compte de lessentiel des phnomnes considrer. Fidlit : pour parvenir une reprsentation sans dformations. Non redondance : on ne prend en compte, pour la reprsentation, que les lments qui sont ncessaires. II.2.3- Les diffrents modles de bases de donnes : Les bases de donnes sont apparues la fin des annes 60, une poque o la ncessit d'un systme de gestion de l'information souple se faisait ressentir. Il existe cinq modles de SGBD, diffrencis selon la reprsentation des donnes qu'elle contient : le modle hirarchique: les donnes sont classes hirarchiquement, selon une arborescence descendante. Ce modle utilise des pointeurs entre les diffrents enregistrements. Il s'agit du premier modle de SGBD.
Figure 2.1 : Reprsentation du modle hirarchique le modle rseau: Comme le modle hirarchique ce modle utilise des pointeurs vers des enregistrements. Toutefois la structure n'est plus forcment arborescente dans le sens descendant.
17
Figure 2.2 : Reprsentation du modle rseau le modle relationnel SGBDR: les donnes sont enregistres dans des tableaux deux dimensions (lignes et colonnes). La manipulation de ces donnes se fait selon la thorie mathmatique des relations .
Figure 2.3 : reprsentation du modle relationnel le modle dductif: les donnes sont reprsentes sous forme de table, mais leur manipulation se fait par calcul de prdicats. le modle objet SGBDO: les donnes sont stockes sous forme d'objets, c'est--dire de structures appeles classes prsentant des donnes membres. Les champs sont des instances de ces classes.
Figure 2.4 : reprsentation du modle objet De nos jour les bases de donnes relationnelles sont les plus rpandues. En effet, le modle relationnel prsente plusieurs avantages, qui sont nos arguments concernant notre choix de la mthode relationnelle.
18
conception dtaille de la base de donnes III- Le modle relationnel : III .1 - Les caractristiques du modle relationnel : Il permet un haut degr dindpendance des programmes dapplications par rapport la prsentation interne des donns, en voyant que des tables logiques et tant affranchis de la gestion des mthodes de stockage et des chemins daccs. Il offre un langage de dfinition et de manipulation des donnes normalis, bas sur des requtes non procdurales qui permettent des transferts densembles de lignes constituant de vritables sous-tables. Il fournit une base solide pour traiter les problmes de cohrence des donnes, en supportant notamment des contraintes dintgrit. Cest un modle extensible permettant de modliser et manipuler simplement des donnes tabulaires, mais pouvant tre tendu pour grer des objets complexes voire structurs. III.2- Les concepts de base du modle : Le modle relationnel reprsente linformation dans une collection de relations. Intuitivement, on peut voir une relation comme une table double entre, voir mmes comme un fichier. Chaque ligne de table peut tre vue comme un fait dcrivant une unit du mode. Une colonne de la table est appele un attribut. III.2.1 Domaine : Les ensembles de donnes de dpart sont appels des domaines. Un domaine est en thorie un ensemble de valeurs . III.2.2- Relation : Le modle relationnel est bas sur le concept de relation. La relation est dfinie par son nom, sa liste de constituants et par son prdicat. Les relations modlisent les ides qui relient les objets (cods par des valeurs) des domaines entre eux. Une reprsentation des relations sous forme de tables a t retenue dans SGBD3 relationnels, si bien que lon confond relation et table. III.2.3-Attribut : Chaque colonne dune relation ou table correspond un domaine qui peut apparatre plusieurs fois . Afin de pouvoir distinguer les colonnes et rendre leur ordre sans importance tout en permettant plusieurs colonnes de mme domaine, il est ncessaire dassocier un nom chaque colonne, do la notion dattribut.
19
conception dtaille de la base de donnes III.2.4- Cl et contraintes dintgrit : Un schma de base de donnes est un ensemble de schmas de relationS={R1 , R2,,Rn} et un ensemble de contraintes dintgrit CI. Une contrainte dintgrit est une proprit du schma, invariant dans le temps. On peut distinguer plusieurs catgories de contraintes. Les contraintes structurelles, dfinissent plus prcisment la structure des associations entre les donnes(le modle de donnes les supporte en partie) et les contraintes sur les valeurs donnent des relations entre les donnes. La plupart des contraintes ne sont pas supportes pas le modles de donnes et doivent donc tre codes par le programmeurs dans des programmes dapplication. Les rgles dintgrit sont des assertions qui doivent tre vrifies par les donnes contenues dans la base de donnes. Le modle relationnel privilgie trois types de rgles de contraintes dintgrit : contraint dintgrit sur les cls, les contraintes dentit et les contraintes rfrentielles. III.2.4.1- Contrainte dintgrit sur les cls : Par dfinition, tous les valeurs dune relation sont distincts deux deux (puisquil sagit dun ensemble). Il est galement intressant de dfinir des sous-ensembles du schma qui permettent didentifier de manire unique une valeur (par exemple dans lexemple de labonn, lattribut No-CIN permet didentifier un abonn). Ces sousensembles du schma sappellent des cls. Le systme doit donc garantir lunicit des valeurs de cls(un seul valeur abonn peut avoir une valeur de No-CIN donne). Cette cl sera indique de manire graphique en mettant en gras les attributs la composant. III.2.4.2- Contrainte dentit : Elle impose lexistence dune cl documente permettent lidentification de tout valeur dun relation . Aucune composante dune cl primaire ne peut tre nulle. Une cl doit permettre un identification unique dun valeur dans la base. III.2.4.3- Contrainte rfrentielle : Elle spcifie un lien hirarchique entre deux tables, lune devenant dpendante de lautre. Une contrainte dintgrit permet en particulier de reprer les associations obligatoires entre entits. En rsum, le modle relationnel est trs simple de point de vue modlisation de donnes. Il repose sur les concepts rappels dans la figure ci-dessous. Sa simplicit fait force notamment pour le dveloppement dapplications client-serveur. III.3- Avantages et inconvnients du modle relationnel : III.3.1- avantages : 1. La simplicit pour lutilisateur qui manipule des tables. 20
2. Lindpendance de lutilisateur vis vis de la structure logique, de la structure physique et des stratgies daccs aux donnes. 3. Puissance et uniformit de reprsentation : la thorie mathmatique permet une conception rigoureuse et algorithmique du schma. 4. Puissance dexpression de la scurit des donnes : contrles dpendant du contenu, du contenant, des contextes. 5. Existence dinterfaces non procduraux pour usagers non informaticiens. III.3.2- inconvnients : 1. Ncessit dun SGBD puissant. 2. Perte dun peu dindpendance logique lord de normalisation. 3. Difficult quon a de dfinir une couverture minimale. Dans ce qui suivra, on va adopter cette mthode relationnel en commenant par un inventaire des diffrentes entits(relations et tables), leurs attributs et leurs cls, puis on applique cette conceptualisation pour tracer le modle relationnel des donnes. IV- Base de donnes du projet : IV.1- Inventaire des entits et association : Ltude et lanalyse des spcifications, du cahier de charges et dun ensemble de documents administratifs (fiche tlphonique de labonn, fiche du dossier dinscription chez lagence commerciale des tlcommunications, centre de facturation) nous ont conduit dgager les entits suivantes : Abonn ou client, numro du tlphone, type (client physique ou client moral), catgorie de labonnement (fixe ou prpay), compteur tlphonique ( initial ou journalier). IV.2- Conceptualisation : La conceptualisation consiste : Traduire par des schma de relation les entits et association qui ont t retenues lors de lanalyse . Transformer ces schma par processus les normalisations qui vise successivement : Tracer le schma de dpendance fonctionnelle entre les diffrentes entits. Supprimer les donnes redondantes pour allger lespace de stockage des donnes.
21
conception dtaille de la base de donnes Tracer le du modle relationnel des donnes.
IV.2.1- Les relations de la base de donnes : Cette tape consiste fi xer les attributs, cls et proprits de chaque relation.
Abonn et/ou relation
Dsignation symbolique dn
Dfinition & description Numro dannuaire : cl primaire de la table N de la carte didentit : cl primaire de la table Nom Prnom
abonn cin entit sociale, existe suite un raccordement au rseau tlphonique nom publique prnom
Catgorie Catgorie dabonn et dabonnement
compteur_journalier Compteur dimpulsions tlphonique (maquette EWSD) dn Numro dannuaire Cl primaire de la table catgorie Ordinaire ou prpay Physique ou moral login password Nom dutilisateur Mot de passe suprieure 6 caractres Cl primaire de la table
22
nom prnom rue ville Client_physique Informations communiques Par une personne physique Pour aboutir linscription numro code_postal
Nom Prnom Rue Ville numro code postal
login password Nom_social rue ville numro Client_moral Informations communiques Par une personne qui reprsente Une socit , entreprise Code_postal
Nom dutilisateur cl primaire de la table Mot de passe suprieure 6 caractres cl primaire de la table Nom Rue Ville Numro Code postal
Login
Nom dutilisateur cl primaire de la table
password
Mot de passe suprieure 6 caractres cl primaire de la table
23
conception dtaille de la base de donnes dn Numro dannuaire Cl primaire de la table
Compteur
compteur_initial
Valeur du compteur dimpulsions on obtenu suite au transfert Du fichier de taxation partir de la maquette EWSD . ompteur_journalier
Compteur tlphonique du dbut du trimestre
Compteur tlphonique journalier transferer ds la Maquette EWSD Nom dutilisateur
login
password
Mot de passe suprieure 6 caractres
Table 2.1 : numration des entits de la base de donnes tl facturation
IV.2.2- Le modle relationnel de donnes : Voici notre modle relationnel des donnes : abonne(dn , cin, nom, prnom, compteur_journalier) client_physique(nom, prnom, rue, ville, numro, code_postal, login, password) client_moral(nom_social, rue, ville, numro, code_postal, login, password) compteur(dn, compteur_initial, compteur_journalier, login, password) catgorie : ( dn, login, password, catgorie). Conclusion : La base de donnes reprsente le pilier de base dans ce projet puisquelle dcrit lapplication dans ses composantes (donnes) . La ralisation physique de la base de donnes ainsi que les technologies jointes seront dtailles plus loin, mais la question qui commence passer au premier plan est comment sera exploite la base donnes ? La rponse sera lobjectif du chapitre consacr aux technique du Data-W e b. Mais pour pouvoir accder une base de donnes via une architecture client -serveur (dans notre cas le protocole http et les interfaces Web), il faudra prciser et dtailler les interactions entre les postes clients ainsi que la spcification des interfaces daccs avec les serveurs dapplications et de base de donnes, permettant de dgager le schma de base de la navigation . On commence ainsi affranchir les premires tapes de la conception des traitements et cest ce qui nous conduit alors dans le chapitre qui suit entamer la conception entire de lapplication et particulirement linteraction de la base de donnes avec les autres composants du projet dont essentiellement le serveur Web.
24
Architecture de la solution propose
Chapitre 3 Plate-forme de tl facturation : architecture de la solution propose
Introduction : La solution quon va proposer au cours de ce projet , intgre des facteurs qui sarticulent autour de la base de donnes. Ce chapitre va donc tre le premier pas dans la conception de larchitecture gnrale de lapplication et la spcification des diffrents traitements effectuer au moyens des formulaires HTML prsenter dans les pages W e b du site au cours de la navigation. De la mme occasion, on propose le schma qui gre les flux de donnes entre le diffrents intervenants : le client, le serveur W e b, le serveur de base de donnes, les passerelles de linscription ainsi que la consultation de tl facturation . Finalement on donnera la configuration ralisable dans la maquette de commutation EWSD de lISETCom.
25
I-Architecture de la solution propose :
TCP/IP
Serveur de base De donnes
FTP
E T H E R N E T
C G I
Utilisateur 1 Utilisateur 2 Utilisateur n
Serveur Web TCP/IP
RTCP Serveur vocal
H T T P Fournisseur de service Internet
Routeurs
Rseau de donnes
Figue 3.1 : Architecture de la solution propose
26
Central Tlphonique 1 Via X25 ou RNIS pour le transfert des fichiers de taxation Centre de collecte de taxation
Central Tlphonique n
Mcanisme dtablissement des factures
Figue 3.1 : Architecture de la solution propose
27
II- Solution ralisable sur la maquette EWSD de LISETCOM
Maquette EWSD
X 2 5
Clients
HTTP
E T H E R N E T
TCP/IP
Serveur BD et serveur WEB
FTP
terminal
Figure 3.2 : Architecture de la solution ralisable Pour mettre en uvre cette solution sur la maquette EWSD de LISETC OM , on t obliger dinstaller les modules et dintroduire la base de donnes ncessaires pour assurer le transfert automatique des fichiers de taxation, les dtails de linstallation ainsi que lintroduction de la base de donnes vous sera communiquer dans lun des chapitres qui suivent.
28
Architecture de la solution propose III- Structure de base de la solution propose : Les composants principaux de la solution proposes sont les suivants : III.1-Le client : Cette partie concerne essentiellement laccs du client au site W e b choisi. En principe, on na pas une grande intervention ce niveau, mais on doit prendre en compte certains paramtres de lenvironnement client tel que la connexion , le type du navigateur ( supporte les protocoles de scurit comme SSL ou non,) . III.2-Le serveur Web : Le serveur joue un rle principal car il reprsente le point de connexion partir du quel sera reues ou envoyes les requtes et les rponses. Lcriture des pages au format HTML ncessite un navigateur pour visualiser le rsultat, dautres part lcriture des scripts CGI ncessite la prsence dun serveur http tournant sur la machine. On parle surtout de deux entits primordiales : III.2.1-Le site Web : Le site Web hberg dans le serveur contient la rubrique de linscription et la consultation en ligne de la facture tlphonique qui sera prsente sous forme dun lien hypertexte dans la page daccueil. III.2.2- Les modules de traitements : Ce sont les scripts logs sur le serveur et qui permettent de traiter les requtes des clients et gnrer toute information dynamique partir de la base de donnes. IV- Plan de navigation : Pour pouvoir dvelopper les modules de traitements , il est ncessaire dtablir le scnario de navigation suivre au cours de lopration de l inscription et de la consultation de la facture depuis la connexion au site jusqu la confirmation final du bon droulement de lopration. IV.1- Page daccueil : Cest la "Home-Page"du site concern. Elle doit imprativement contenir le bien vers les rubriques ; inscription client_physique , inscription client_moral, consultation de la facture.
29
Architecture de la solution propose IV.2- Activation de linscription : Ce formulaire inclut des informations gnrales sur les modalits de linscriptions des clients physiques ou morales . On doit aussi laisser loccasion aux clients de saisir leurs nom dutilisateur et leurs mot de passe qui seront utile pour la consultation de leurs factures. IV.3-Mise jour des renseignements : Cette page est envoye une fois que lidentification est bien droule et informe les clients de la russite de linscription . une mise jour dans la base de donnes est excute immdiatement. IV.4-Activation de la consultation : Ce formulaire englobe les informations de connexion prcdemment saisies dans la rubrique dinscription. IV.5- consultation de la facture : Une fois que le client ait t reconnu, la transaction seffectue et un formulaire de facture sera gnr.
V- Modle de traitement : V.1- Le modle requte-rponse : Tous les modules de traitements dvelopper se basent sur le mme principe et ce du dbut de lopration jusqu la fin : Envoi de formulaire depuis le serveur. Saisie de donnes de la part du client et retransmission du formulaire vers le serveur. Rcupration des donnes saisies et traitement adquat par un script serveur. Gnration de page HTML rponse vers le client en fonction des traitements effectues. Les script doivent tre modulaires, cest dire un ensemble de procdures et fonctions dont chacune effectue une tche particulire(identification, mise jour des donnes). Le choix de la technique de ces script et du langage de dveloppement est un dtail technique ngocier plus loin dans ce projet.
30
Architecture de la solution propose V.2- Traitement des exceptions : Rien nempche le client de communiquer des informations errones mme par inadvertance. Ces informations ne doivent pas chapper au contrles des scripts qui doivent intgrer un mcanisme de redirection en cas derreur et de vrification de donnes insrer dans la base. Un bon nombre de ces contrles dits contrles intrinsques peuvent tre transposs vers le client et en charge par des script locaux au systme hte de celui ci. Conclusion : En cette phase du projet, on vient dentamer la premire partie qui est celle de la conception. Lobjectif est ds maintenant de trouver la meilleure concrtisation de cette conception par une implmentation de la base de donnes et le dveloppement des modules de traitements par les systmes et outils garantissant le meilleur rendement en matire de fonctionnalits et robustesse. Ceci va donc nous amener dans les chapitres suivants raliser ces objectifs en adoptant chaque fois une dmarche bien prcise visant dabord ltude globale du systme ou langage utiliser, ensuite un bref comparatif des technologies utilises et finalement le choix bien fond dun outil de travail pour limplmentation et le dveloppement.
31
Ralisation et implmentation de la base de donnes
Chapitre 4 Ralisation et implmentation de la base de donnes
Introduction :
Une approche de solutions techniques aux problmes mentionnes lors de la conception passe par une organisation du systme dinformation qui doit devenir plus intgr mais aussi plus volutif. Ceci ncessite tout dabord de systmes ouverts, obissants des standards permettant le choix dun grand nombre de produit sur le march. La majorit de ces produits sont articuls autour de moteur relationnel qui apporte une meilleure matrise de linformation et une plus grande souplesse dvolution : cest le standard industriel. Ce chapitre a donc pour objectif de matriser la technologie de base des SGBDR, faire un choix technique et en expliciter les raisons et finalement dimplmenter la base de donnes du projet.
32
Ralisation et implmentation de la base de donnes I-Les SGBD relationnelles : I.1-Dfinitions : Un Systme de Gestion de Bases de Donnes est un ensemble de programmes qui permettent des utilisateurs de crer et maintenir une base de donnes. Les activits supportes sont la dfinition dune base de donnes, la construction dune base de donnes et la manipulation de donnes(principalement ajouter, supprimer, retrouver des donnes). Les SGBD commerciaux les plus connus sont Oracle, Sybase, Ingres, Informix et DB2. I.2- Fonctionnalits des SGBD : On donne ici les caractristiques souhaitables des SGBD : Contrler la redondance dinformations : la redondance dinformations pose diffrents problmes. Un des objectifs des bases de donnes est de contrler cette redondance, voire de la supprimer, en offrant une gestion unifie des informations complte par diffrentes vues pour des classes dutilisateurs diffrents. Partage de donnes :une base de donnes doit permettre daccder la mme information par plusieurs utilisateurs en mme temps. Le SGBD doit inclure un mcanisme de contrle de la concurrence bas sur des techniques de verrouillage de donnes(pour viter par exemple le fait de lire une information dont on est en train de la mettre jour). Grer les autorisations daccs : une base de donnes tant multi utilisateurs, se pose le problme de la confidentialit des donnes. Des droits doivent tre grs sur les donnes, droits de lecture, mise jour, cration, qui permettent daffiner la notion de vue utilisateur. Offrir des interfaces daccs multiples : un SGBD doit offrir plusieurs interfaces daccs, correspondant aux diffrents types dutilisateurs pouvant sadresser lui. Reprsenter des relations complexes entre les donnes :Un SGBD doit permettre de reprsenter des donnes inter-relies de manire complexe. Cette facilit sexprime travers le modle de donnes sous -jacent au SGBD. Chaque modle de donnes offre ses propres concepts pour reprsenter les relations. Vrifier les contraintes dintgrit : un schma de base de donnes se compose dune description des donnes et de leurs relations ainsi que dun ensemble de contraintes dintgrit. Une contrainte dintgrit est une proprit de lapplication modliser qui renforce la connaissance que lon en a . En peut classifier l es contraintes dintgrit, en contraintes structurelles et contraintes dynamiques. Les SGBD commerciaux se portent automatiquement un certain nombre de contraintes structurelles, mais ne prennent pas en compte les contraintes dynamiques (elles doivent tre codes dans les programmes dapplications). 33
Assurer la scurit et la reprise aprs panne : une base de donnes et souvent vitale dans le fonctionnement dune organisation, et il nest tolrable qune panne puisse remettre en cause sans fonctionnement dune manire durable. Les SGBD fournissent des mcanismes pour assurer cette scurit. Le premier mcanisme et celui des transactions qui permet dassurer un comportement atomique une squence dactions (elles seffectuent compltement avec succs ou elle est annule). Une transaction est une squence doprations qui fait passer la base des donnes dun tat cohrent un nouvel tat cohrent. Lexemple typique et celui du dbit crdit pour la gestion dune carte bancaire . ce mcanisme permet de saffranchir de petites pannes (style coupure de courant). En ce qui concerne les risques lis au panne disques, les SGBD sappuient sur un mcanisme de journalisation qui permet de rgnrer une base de donnes automatiquement partir dune version de sauvegarde et de journal des mouvements. I.3- Architecture et fonctionnement : La plupart des SGBD suivent larchitecture standard Ansi /Sparc qui permet disoler les diffrents niveaux dabstraction ncessaires pour un SGBD.
Utilisateurs A1
Schma Externe A
Utilisateurs A2
Schma conceptuel
Schma interne
Base de donnes
Utilisateurs B1
Schma Externe B
Correspondance Externe-conceptuel (indpendance logique)
Correspondance interne-conceptuel (indpendance physique)
Figure 4.1 : Architecture fonctionnelle des SGBD-R
34
Ralisation et implmentation de la base de donnes cette architecture est dfinie sur trois niveaux : Niveau interne ou physique : dcrit le modle de stockage des donnes et les fonctions daccs. Modle conceptuel ou logique : dcrit la structure de la base globalement tous les utilisateurs (limite la redondance). Le schma conceptuel est produit par une analyse de lapplication modliser et par intgration des diffrentes vues utilisateurs. Ce schma dcrit la structure de la base indpendamment de son implantation. Niveau externe : correspond aux diffrentes vues des utilisateurs. Chaque schma externe donne une vue sur le schma conceptuel une classe dutilisateurs. I.4- Le language SQL : I.4.1- Intrt de SQL : Tous les systmes de gestion de donnes utilisent SQL pour laccs aux donnes ou pour communiquer avec un serveur de donnes. SQL(Standard Query Language) est n la suite des travaux mathmatiques de Codd, travaux qui ont fond les bases de donnes relationnelles. SQL, dfini dabord chez IBM, a subi trois tentatives de normalisation en 86, 89 et 92(SQL 2 ou SQL 92). Nous prsentons trois raisons fondamentales qui justifient lutilisation de SQL. Dune part, la stucturation et la manipulation des donnes sont devenues trs complexes. Pour une application de taille moyenne, la base de donnes contient frquemment plusieurs tables fortement interconnectes. Il est donc hors de question de manipuler les donnes de faon algoritmique traditionnelle. Une requte SQL dans un langage logique simple remplace donc bien avantageusement plusieurs dizaines de lignes dun langage de programmation comme C ou Cobol. Dautrepart, larchitecture client-serveur est omniprsente, dvelopper une application dans un environnement htrogne nest possible que parce que la communication entre lapplicatif client et le serveur est ralise par des primitives SQL normalises. Enfin, les applications dvelopper sont devenues de plus en plus complexes. Le profil du programmeur a fortement chang. Il doit maintenant traiter des donnes de plus en plus volumineuses , intgrer les techniques de manipulation des interfaces, matriser la logique vnementielle et la programmation oriente objet, tout cela dans un contexte darchitecture client-serveur o se ctoient les systmes dexploitation de rseaux htrognes. Laccs et la manipulation des donnes ne sont pas que lun des aspects de la conception et de la ralisation de programmes. On cherche donc acqurir un environnement de dveloppement performant qui prend en charge un grand nombre de tches annexes. Des outils de dveloppement sont apparus pour permettre au dveloppeur de se concentrer sur 35
Ralisation et implmentation de la base de donnes lapplication proprement dite : gnrateurs dcrans, de rapports, de requtes , daide la conception de programme, de connexion des bases de donnes distantes via les rseaux. Dans tous ces outils, la simplicit et la standardisation de SQL font que SQL est utilis chaque fois quune dfinition , une manipulation, ou un contle de donnes est ncessaire. SQL est donc un lment central entre les divers composants dun environnement de dveloppement dans une architecture client-serveur. II Choix technique pour le projet : MYSQL II.1- Caractristiques de MYSQL : MySQL est un vritable serveur de base de donnes SQL, Multi -Utilisateurs et multithreades. Les principaux objectifs de MYSQL sont la rapidit, la robustesse et la facilit dutilisation. MYSQL a t originellement dvelopp suite au besoin dun serveur SQL qui puisse grer des grandes bases de donnes de manire plus rapide. Il est utilis depuis 1996 dans un environnement de plus de 40 bases de donnes contenant 10000 tables dont plus de 500 contiennent plus de 7 millions denregistrements. Cest environ 100 giga de donnes critiques. La base sur la quelle MYSQL est construite est forme dun ensemble de routines de production exigeant. Mme si MYSQL est encore en dveloppement, il propose dj un ensemble de fonctionnalits riches et extrmement utiles. II.2- Pourquoi a-t-on choisi MySQL? Notre choix pour travailler avec un SGBDR comme MySQL est essentiellement du aux caractristiques de ce systme qui rpondent aux exigences en matire de services en ligne tournant sur des serveurs pouvant atteindre des pic de charge (connexions) important : Compltement multi-thread et utilise les threads du noyau. Cela signifie quil peut utiliser plusieurs CPU ainsi quune garantie dautonomie et robustesse de fonctionnement. MySQL est lui mme crit en Cet C++ et test avec bon nombre de compilateurs diffrents. Support et compatibilit avec la majorit des langages de programmation comme C,C++, Eiffel, Java, Perl, PHP, Python, et avec la plupart des systmes dexploitation du march comme LINUX,WINDOWS, AIX,SOLARIS, FreeBSD, ce qui augmente la portabilit de nos dveloppements sans aucun souci dincompatibilit de notre code avec la plate-forme. De plus, il est compatible avec le standard ODBC (Open-Database-Connetivity) pour Windows95 (avec source). Toutes les fonctions ODBC2.5 et dautres sont disponibles et on peut, par exemple, utiliser Accs pour se connecter au serveur MySQL. Des fonctionnalits importantes en matire de manipulation, reprsentation et stockage des donnes : 36
Les fonctions SQL sont implmentes travers des classes de librairies extrmement optimises. 16 index par tables sont autoriss. Chaque index consiste en 1 et 15 colonnes ou parties de colonnes. La longueur maximale dun index est de 256 octets. Enregistrements de longueur fixe ou variable et gestion de grandes bases de donnes. Pouvant atteindre plus de 50,000,000 enregistrements. Systme flexible et scuris de droits et de mots de passe, et qui autorise une vrification faites sur ltes. Les mots de passe sont scurises depuis que la gestion des mots de passe est crypt entre le client et le serveur. Les clients se connectent au serveur MySQL en utilisant les connexions TCP/IP. II.3- Obtention : Pour obtenir le systme MySQL, il suffit de le tlcharger librement depuis plusieurs serveurs Web (comme http://www.mysql.org ou http://www.mysql.com) qui proposent diffrentes distributions, exception faite pour MySQL pour la plate-forme Microsoft Windows qui ncessitent lachat de licence dexploitation du logicielle et noffre que des versions dessais. Pour la plupart des distributions des systmes UNIX et LUNIX, MySQL figure parmi les bibliothques du systme et sinstalle directement avec celui ci. Son installation est principalement base sur le dpaquetage de certains modules et programmes en mode ligne de commande et la cration des rpertoire de travails particuliers. II.3.1- installation et Compilation : Rcuprer larchive mysql-3.22-32.tar.gz(www.mysql.org) Cd/usr/src Tar-vzxf mysql-3.22-32.tar.gz Cd/usr/src/mysql-3.22.32 /configure Make make install scripts/mysql_install_db III-Serveur MYSQL: III.1- Connexion au serveur MySQL : Mysql[ h host_name] [ -u user_name ] [-p mot de passe ] Les clients MySQL ont besoin dun certains nombre de paramtres pour se connecter un serveur MySQL : lhte qui abrite le serveur, le nom dutilisateur et le mot de passe. Par dfaut, mysql utilise les valeurs suivantes :
37
Ralisation et implmentation de la base de donnes le nom dhte par dfaut est localhost, cest dire la machine locale . le nom dutilisateur par dfaut est le nom de login Unix. aucun mot de passe nest envoy si p nest pas prcis. III.2- Systme de droit et contrle daccs : III.2.1 But : La fonction primaire du systme de droits de MySQL est dauthentifier un uti lisateur se connectant, et lassocier avec les droits dutilisation des commandes SELECT, INSERT, UPDATE et DELETE sur cette base. Les fonctions secondaires inclus la possibilit daccueillir un utilisateur anonyme, et donner des droits particuliers des fonctions spcifiques. III.2.2- Noms dutilisateurs et mots de passe : Il y a de grandes diffrences entre la gestion des noms dutilisateur et mots de passe de MySQL, et celle de Unix ou de Windows. Les noms dutilisateurs, utilis par MySQL pour lauthentification, nont rien voir avec les noms dutilisateur de Unix (Nom de login) ou de Windows. Les noms dutilisateurs MySQL peuvent avoir jusqu 16 caractres de longueur. Gnralement, les noms dutilisateur Unix sont limits 8 caractres. Les mots de passe MySQL sont crypts avec un cryptage diffrents de celui dUnix. III.2.3- Fonctionnement : MySQL sassure que tous les utilisateurs peuvent faire ce quils ont le droit de faire. Lorsquon se connecte un serveur MySQL, le serveur dtermine lidentit grce lhte depuis lequel on se connecte, et le nom dutilisateur quon spcifie. Le systme alloue les droits adquats. MySQL considre que le nom de lhte et le nom dutilisateur sont suffisants pour une identification sans ambigu t, car ily a peu de chance quun nom dutilisateur soit utilis par la mme personne, depuis tous les htes sur Internet! MySQL permet de distinguer les utilisateurs, et de donner des droits diffrents pour le mme nom dutilisateur, mais pour des htes diffrents. MySQL contrle laccs en deux temps : Etape1 : vrification de la connexion : Lorsquon se connecte un serveur MySQL, le serveur accepte ou rejette la tentative en fonction de lidentit, et de la capacit fournir le mot de passe correct. Dans le cas contraire, le serveur refuse compltement laccs. Sinon, le serveur accepte la connexion, et passe en niveau2, pour attendre les requtes. Lidentit lors de la connexion est bas sur deux lments : lhte depuis lequel on se connecte et le nom dutilisateur MySQL. La vrification de lidentit est faite en utilisant les trois champs didentit de la table user(Host, User et Password). Le serveur nacceptera une connexion que s il existe un enregistrement qui contienne lhte, le nom dutilisateur et le mot de passe.
38
Ralisation et implmentation de la base de donnes Etape2 : vrification des requtes : Une fois la connexion est tablie, le serveur passe en niveau2. Pour chaque requte entrante, le serveur va vrifier que les droits sont suffisants pour effectuer la requte, en fonction du type dopration. Pour les requtes administratives telles que shutdown, reload,, le serveur ne vrifie les droits que dans la table user, tant donn que cest la seule qui spcifie les droits administratifs. La commande est excute si les droits sont disponibles, sinon la requte nest pas autorise. Pour les requtes lies aux bases des donnes, telles que insert, update, ect.., le serveur commence par vrifier les droits globaux (droits de super utilisateur) en recherchant dans la table user. Si il trouve des droits, lexcution de la requte est autoris. III.3- Lancement de serveur MySQL : Lancer une session root sur la machine qui fait serveur. Excuter la commande /comm/soft/bin/safe_mysqldlog&.Loptionlog permet denregistrer les messages derreur ainsi que toutes les requtes qui sont faites au serveur. le fichier log/comm2/soft/mysq1/var/tecfasun1 .log est cre automatiquement sil nexiste pas encore. Si le serveur est dj actif, le systme rpond A mysql process exist. III.4- Arrt du serveur : Lancer une session root sur la machine qui fait serveur. Excuter la commande: /comm/soft/bin/mysqladmin shutdown IV Programmation Mysql : Ce paragraphe dcrit la procdure de cration de la base de donnes PFE et facturation et limport des donnes sur le SGBD MySQL. IV.1- Cration de la base de donnes PFE : mysql> create database PFE ; Crer une base de donnes ne la slectionne pas automatiquement. Il faut le faire explicitement. Pour faire de PFE notre base courante, il faut utiliser la commande : mysql>use PFE Database changed De mme pour la base de donnes facturation. mysql> create database facturation 39
mysql>use facturation Database changed La base na besoin dtre cre quune seule fois, mais il faudra la slectionner chaque fois que vous commencerez une session mysql. Il suffira alors dutiliser la mme commande que ci-dessus. Alternativement, vous pouvez slectionner une base ds la connexion, en passant le nom de la base aprs tous les paramtres de connexion : $mysql h u user p PFE/facturation enter password: ******* IV.2- Cration des tables de la base: Crer une base de donnes est facile, mais, jusqu prsent , cest vide. La commande show tables donne : mysql>show tables ; Empty set (0.00 sec) La partie la plus difficile est le choix de la structure de votre base de donnes, et des tables dont on a besoin, et quelles colonnes seront ncessaires. A titre dexemple, on va dtailler la cration des tables les plus importantes du projet : abonn , client_physique; en se rfrant sa structure. mysql>use facturation Database changed mysql>create table abonne ( Dn int(8) unsigned no null default, Cin int(8) unsigned not null default, Nom varchar(50) not null, Prenon varchar (50) not null, Compteur_journalier int (16) unsigned not null, Primary key (dn,cin) );
mysql> use PFE Database changed mysql>create table client_physique ( Nom varchar(50) not null, Prenon varchar (50) not null, Rue varchar (50) not null, Ville varchar (50) not null, 40
Numero int (4) unsigned not null, Code_postal int (4) unsigned not null, Login varchar (50) not null, Password varchar (50) not null, Primary key (login,password) );
IV.3- Test de la base : La commande show tables permet de vrifier que la base de donnes est implment sur le serveur et que les tables sont cres. mysql> show tables ;
Pour vrifier que la table a t cre comme on le dsire, on utilise la commande describe. Mysql>describe abonne ; IV.4- Alimentation de la base de donnes : Aprs avoir cre la table, il faut la charger. La fonction LOAD DATA et INSERT remplissent cette fonction. Etant donn quon commence avec une table vide, le meilleur moyen de remplir cette table est de crer un fichier texte, chaque ligne contenant les informations dun client, puis de le charger directement dans la table avec une seule commande. On cre ainsi un fichier Abonne.data contenant un enregistrement par ligne, avec des valeurs spares, et dans le mme ordre que lordre dans lequel les colonnes ont t listes dans la commande create table. mysql>load data local infile "abonne.data " into table abonne; Pour najouter quun seul enregistrement la fois, la fonction INSERT est plus pratique : Dans sa forme la plus simple, on fournit les valeurs dans lordre des colonnes. mysql>insert intonom de la table VALUES(x,y,z,) ;
Conclusion :
MySQL est un logiciel libre de base de donnes relationnelle fonctionnant en clientserveur. Il est maintenant trs rpandu et devient un standard, en particulier dans le cas 41
Ralisation et implmentation de la base de donnes dapplication W e b. il na pas la prtention de visualiser avec Oracle ou les autres gros logiciels commerciaux. MySQL peut tre utilis dans des scripts PERL et PHP ou inclus dans des documents HTML ; ce qui est le plus courant.
42
serveur Web et interfaces clients
Chapitre 5 Serveur Web et interfaces clients
Introduction : La migration des systmes informatiques vers le client-serveur est aujourdhui une tendance fondamentale de lindustrie car elle met en jeu trois notions importantes et dcisives dans tous projets informatiques orient communications : la base de donnes, les rseaux de communication et les outils de dveloppement. Limplmentation Web de larchitecture client-serveur est trs simple mais cette simplicit est impose par les besoins et les exigences en terme de rapidit et de facilit daccs car cest un environnement ouvert au grand public. Il est donc primordial dtudier larchitecture client-serveur Web en dtaillant les trois composantes principales : le client et les outils de dveloppement qui sont jointes, le protocole http et le serveur Web. Lobjectif final et de raliser, les diffrents pages et traitement du ct client, puis ltude des performances du serveur APACHE qui est utilis dans ce projet .
43
Figure 5.1 : Exemple dune configuration client-serveur I Systme client : I.1 Performances des applications orientes Web : La technologie Web nest pas la premire permettre de rcuprer des informations de la part des utilisateurs via un rseau. Cest exactement ce que font tous les programmes client serveur et notamment les applications trs tendues comme oracle ou lotus Notes. Mais en ajoutant un composant Web une application client serveur habituelle, on bnficie davantages supplmentaires
Une compatibilit instantane entre plates-formes : les navigateurs Web ont t conus pour fonctionner sur pratiquement toutes les plat formes existantes. De plus, les langages HTML et java sont indpendants et non compils. Ils sont interprtes au fur et mesure par le navigateur. On conomise ainsi une grande quantit de travail par rapport au processus de dveloppement classique. Un accs universel : un formulaire Web peut tre consult depuis nimporte quel nud dun rseau via un simple lien . Ds quon cre un formulaire sur le serveur,
44
serveur Web et interfaces clients toute personne possdant un navigateur et accdant au rseau peut louvrir. Le formulaire peut ressembler un document Web normal, et on peut mme linsrer lintrieur dun autre document. Une interface utilisateur universelle : les formulaires Web permettent de proposer des applications client-serveur via une seule interface utilisateur, celle du navigateur, qui peut tre commune des dizaines dapplications. Les diffrentes pages Web du projet de linscription de tl facturation tlphonique sont bases sur les formulaires HTML qui seront traits double reprise premirement au niveau client pour des contrles intrinsques via un langage de sripting client et deuximent au niveau du serveur par des modules spcifiques au projet. Le paragraphe suivant tudie les techniques de dveloppement cot client. I.2 Dveloppement Web cot client : La nature du projet impose que la plupart des pages Web visualises soient gnres dynamiquement depuis le serveur et ce en fonction de la situation encours qui dpend des donnes envoyes par le client. On parle alors de Web dynamique dont la technique sera tudie dans le chapitre qui suit. Ce pendant, la gnration la vole de code HTML impose la construction dun modle des diffrentes pages du scnario de navigation. Le langage de base est HTML dans sa spcification 4.06 enrichie de plusieurs fonctionnalits concernant les formulaires pour plus dinteraction et souplesse. I.3- Utilisation de formulaires : Afin d'exploiter les bases de donnes, il faut fournir une interface l'utilisateur lui permettant de visualiser des donnes en fonction de certains critres. Pour cela il existe un outil: les formulaires. Un formulaire est une interface prsentant des composants permettant d'afficher, de saisir ou slectionner des donnes. De nombreux outils permettent la cration de formulaires, c'est notamment le cas du HTML. De nombreux environnements pour crer des formulaires existent aussi pour chaque SGBD (Access, Windev, ...). Notre choix dans ce projet et dutiliser les formulaires HTML. I.4- Les formulaires HTML : Les formulaires forment un type particulier de document HTML qui en dfini les rgles. En effet, ce sont des documents Web ordinaires qui disposent demplacements permettant lutilisateur dentrer les informations. Les navigateurs Web doivent savoir comment interprter les formulaires qui peuvent utiliser toute commande de formatage lie HTML, telles que les listes ou les tableaux. Le code du formulaire doit contenir essentiellement trois lments : la mthode denvoie des donnes (METHOD), ladresse 45
serveur Web et interfaces clients du serveur qui va les recevoir (ACTION) et la fentre cible de la rponse du serveur (TARGET). METHOD : Cet attribut est utilis pour envoyer les donnes en spcifiant quelle mthode denvoi utiliser, On distingue deux mthodes : GET : elle place les donnes la fin de lURL dans la requte. Les donnes de lURL sont spares par le caractre ? . Puisque GET concatne les donnes et lURL, le navigateur lui mme peut mmoriser la requte comme un signet qui pourra tre rutiliser. Cependant, les URL ont une longueur maximale admissible et GET ne convient pas aux requtes contenant trop de donnes. En pratique, cette mthode nest utilise que dans le cas o lenvoie du formulaire ne change rien sur le site de destination qui est le cas typique des moteurs dindexation W e b. Post : elle envoie les donnes comme un message spar de lURL mais qui reste li la requte sous forme dobj et HTTP. Cela signifie que le client peut envoyer de linformation au serveur de la mme faon que le serveur envoie les donnes au client. La mthode POST permet dinstaller des documents sur le serveur mme si cette utilisation est relativement rare. Les formulaires de linscription et la consultation de facture sont les meilleurs exemple. Ces deux mthodes font lobjet des standards HTML, HTTPet CGI. Ils dpendent du type du systme utilis. Les dtails sur la manire dcrire un script pour traiter des donnes en provenance dun formulaire sont radicalement diffrentes entre les systmes de type Macintosh, Windows NT ou UNIX. Le standard CGI spcifie les diffrences relatives chaque type de systme dexploitation. Ces diffrences ne doivent pas tre apparentes pour lutilisateur, elles ne concernent que les programmeurs des scripts. ACTION : Cet attribut spcifie lURL o seront diriges les donnes. LURL indique peut tre cod sous forme absolue ou relative et peut mme spcifier certains paramtres envoyer au serveur. TARGET : Cet attribut nest pas obligatoire mais entre en jeu aprs lenvoie des donnes et au moment de la rception de rponse pour indiquer lendroit o afficher le document reu. Il peut prendre lune des valeurs suivantes : _SELF :fentre ou frame en cours. _ NEW : nouvelle fentre. _PARENT : fentre ou frame parent. Target_Name : nom explicite du cadre cible. 46
serveur Web et interfaces clients II-Le protocole http : Le serveur et le navigateur W e b communiquent entre eux par lintermdiaire du protocole http qui est simple et conu pour tre utilis sans le cadre des systmes hypermdias distribus en rseau. http a t cre spcialement pour le W e b et dfinit un mode simple de conversation selon le modle requte-rponse. Un programme client tablit une connexion avec un programme serveur et lui envoi la requte laquelle ragit le serveur en mettant une rponse contenant linformation attendue par le client. http nintervient pas dans la manire dont la connexion rseau est produite et gre ni dans la manire de transmettre linformation(ceci est la charge des protocoles de bas niveau comme TCP et IP).
Protocole TCP/IP Envoi des Enttes HTTP

Envoi des enttes
localisation du fichier
Requ te
Client
dcode
HTTP de rponse serveur Web
cration des enttes Formatages des donnes
Figure 5.2 : Reprsentation du protocole http
II.1- Requte http : Une requte http se compose des lments suivants : La mthode :qui doit faire partie de lensemble des actions lgales. Lidentificateur de ressources universelles(URL) : qui est le nom de linformation recherche. La version du protocole. Autres informations permettant de modifier ou complter la requte. Lide fondamentale vhicule par la notion de requte est que la mthode doit tre applique lobjet rfrenc par lURL. La mthode doit faire partie des choix standards lists dans la table suivante :
Mthode
GET HEAD POST
Action
Rcupre linformation. Retourne linformation concernant lobjet. Demande le stockage dune information.
47
serveur Web et interfaces clients PUT DELETE Autre Envoie une nouvelle copie dun objet existant sur le serveur . Dtruit lobjet dune manire irrversible. Dautres mthodes peuvent tre dfinies lavenir Table 5.1 : les mthodes http LURL identifie lobjet recherch. Ils doivent respecter un ensemble des rgles dfinies par un standard international. Le Web utilise un sous-ensemble des URL : les URL qui contient trois lments : lidentificateur du protocole, nom logique du serveur et le chemin complet du document. La requte peut inclure des informations complmentaires sur la manire de remplir la requte.
CHAMP
User-Agent If-Modified-Since Accepte Autorisation
INFORMATION
Type du navigateur client Rcupration si linformation est plus rcent que la date mentionne. Type de donnes(MIME) acceptes par le navigateur. Information dauthentification(mot de passe ,). Table 5.2 : information envoyes par le client
II.2- Rponse HTTP: Une rponse http contient les lments suivants : Une ligne dtat : indique le succs ou lchec de la requte. Une description de la rponse : il sagit dune information information . Linformation attendue. appele mta-
Lide de base est que le serveur rpond la requte en fournissa nt une description de linformation retourne et qui est suivie de linformation proprement dite. Le format de la ligne dtat est le suivant :
Version http
Code Result
Reason
Figure 5.3 : Format de la ligne dtat dune rponse http Le code rsultat est un nombre indiquant le succs ou lchec de la requte. La raison et une phase expliquant la signification du code.
48
Code message
200 301 401 404 500 OK moved permantly Unuthorised not found server error
Explication
La requte t accompli correctement Document migr vers autre URL Information protge Information non trouve Erreur dans le serveur
Table 5.3 : les codes de rponse HTTP
Nom de lentte server Date Content_type Content_length Content_laguage Content_encoded Last_modified
description Type de serveur Date et heure de la rponse Type de contenu du corps de la rponse exp : (text/html) Nombre doctets de rponse Langage dexpression de linformation Type de codage du corps de la rponse Date et heure de la dernire mise jours Table 5.4 : Les enttes de rponse HTTP
Le content_type est cod partir de type MIME sur la mme base que la liste des types Accept du navigateur . le MIME est un standard international dfinissant les rgles dchange dinformations pouvant contenir autre lments que de texte. Le type MIME est capitale pour les programmes est surtout pour le navigateur Web, car MIME indique comment dchiffrer et afficher linformation. Du faite que chaque navigateur peut accepter diffrent formats de donnes et que chaque serveur dispose de plusieurs type de documents , le content_type permet au serveur de renseigner le client sur le contenu de la rponse.
Type MIME Text/plain Text/html Application/octet_stream Image/gif Video/mpeg
explication Text ASCII pur et sans formatage Document html Application excutable Image au format GIF Clip vido au format MPEG
Table 5.5 : quelques type MIME les plus utiliss
49
serveur Web et interfaces clients III- Le serveur Web : III-1-Principes et fonctionnement : Un serveur web est un logiciel permettant des clients d'accder des pages web, c'est--dire en ralit des fichiers au format HTML partir d'un navigateur install sur leur ordinateur distant. Un serveur web est donc un "simple" logiciel capable d'interprter les requtes HTTPD arrivant sur le port associ au protocole HTTP (par dfaut le port 80), et de fournir une rponse avec ce mme protocole. Les principaux serveurs web sur le march sont entre autres: Apache Microsoft IIS Microsoft PWS Xitami
III.2- Performances dun serveur Web : Un systme serveur dispose typiquement dun processeur et dune mmoire en quantit limite. Lensemble doit tre partag entre le systme dexploitation et tous les programmes dapplication y compris le programme httpd et les scripts. Tous temps de calcul et toute parcelle de mmoire utilise par le systme dexploitation ne profite pas au travail effectif consistant traiter des requtes Web . III.2.1- Excution des scripts et autres programmes
Des ressources de calcul supplmentaires sont ncessaire lorsque le serveur autorise lexcution des scripts qui partagent le processeur et la mmoire avec le programme serveur httpd et le systme dexploitation et prennent gnralement plus de temps sexcuter qune simple requte GET. Les performances des scripts varient sensiblement suivant les systmes : les DLL sous Windows donnent plus de performances que sous des CGI sous Unix. III.2.2- Compression et cryptage des donnes
Lutilisation des images haute rsolution peut nc essiter des techniques de compression permettant de rduire le temps de transmission sur le rseau. Les donnes sont compresses par application dun algorithme effectuant un nouveau codage supprimant les redondances ce qui donne une version plus compacte des donnes mais consomme pas mal de temps machine. Le cryptage et dcryptage des donnes sont essentiels pour assurer la confidentialit des donnes transmises sur le
50
serveur Web et interfaces clients rseau mais peuvent demander des temps de traitement important dont limpact sur le serveur Web est significatif .
III.2.3- Accs aux donnes
Le serveur, outre ses accs aux processeurs et la mmoire, doit lire des donnes sur un dispositif de stockage permanent. Lefficacit du disque dpend essentiellement de deux facteurs : la vitesse du dispositif et lefficacit du logiciel dans sa gestion du priphrique. Le temps daccs aux donnes doit tre minime car les navigateurs nont pas t conu pour patienter plusieurs minutes. IV- Choix technique : APACHE IV.1-Pourquoi APACHE ? Apache est le serveur le plus rpandu sur Internet, il est trs puissant. Il s'agit d'une application fonctionnant la base sur les systmes dexploitation de type UNIX, mais il a dsormais t port sur de nombreux systmes, dont Microsoft Windows. Dire que la plus part de march dapache est de lordre important serait un contre-sens dans la mesure ou Apache est gratuit et ne vise donc pas conqurir les autres type de serveur commerciaux . La principale diffrence entre Apache et les serveurs se rsume en quelques points notables : Apache se configure par modifications de fichiers textes. Ce type de configuration reste le plus puissant et on peut donc dire quApache est le plus configurable des serveurs HTTP. Apache supporte les SSL mais ceux-ci ne sont pas reconnus par le SCSSI, lorganisme de validation des systmes de scuriss en France. Le couplage Apache Perl dans le monde Windows ncessite de modifier la premire ligne des scripts Perl pour les mettre sous la syntaxe : # !c:/perl/lib/perl.exe Mais part ces quelques limitations, Apache reste la solution la plus compatible entre les mondes Windows et Unix et cela constitue un intrt non ngligeable. IV.2- Installation : Aussi bien sous Windows que sous Unix, installer Apache version 1.3.14 ne pose pas de relle difficult Sous Windows la version binaire est livre avec un installateur identique pour la version NT et la version 95.les sources sont galement disponibles. Sous Unix, on prfre compiler les sources mais cela ne pose non plus de problme 51
serveur Web et interfaces clients particuliers. On va donc explorer en dtails la partie configuration du serveur. Cette configuration se fait laide de quelques fichiers . mais avant de les examiner, voici larborescence du serveur : cgi-bin : est le rpertoire par dfaut contenant les CGI . conf : est le rpertoire o sont stocks les fichiers de configuration . htdocs : est le rpertoire par dfaut o sont stocks les fichiers destins tre publis . icons : est le rpertoire par dfaut contenant toutes les icnes reprsentant les dossiers et les fichiers textes etc. logs : est le rpertoire o sont stocks les fichiers mouchards. modules : contient un certain nombre de modules optionnels qui peuvent tre adjoints au serveur. src : quel plaisir de savoir quon dispose des sources du serveur dans ce rpertoire ! IV.3-Configuration : Bien quil existe des logiciels pour configurer le serveur Apache , on donne ici les mthodes de configuration du serveur par modification textes contenus dans le rpertoire conf. Les fichiers de configuration du serveur sont placs par dfaut dans le rpertoire /etc/httpd/conf. On dnombre trois fichiers importants dans la configuration . access.conf : contient les instructions permettant de grer les droits daccs au serveur . srm.conf : contient les instructions grant les noms et les types accessibles aux utilisateurs connects aux moyens des navigateurs. http.conf : contient des directives propres au fonctionnement du serveur lui-mme. IV.4- Dmarrage du serveur Apache : Une fois le serveur est prt, ltape suivante est de la dmarrer rellement dune manire qui dpend de plate-forme et du mode dinstallation. Puisque notre plateforme est sous UNIX la procdure de dmarrage du serveur Apache est la suivante : Aprs le lancement de la commande Install, le dmarrage du serveur se fait par la commande suivante : / usr/local/web/apache/bin/apachetl start / usr/local/web/apache/bin/apachetl start: httpd started
52
serveur Web et interfaces clients V- Scurit du serveur APACHE : Le principe est de scuriser les protocoles Internet (du type HTTP) pour lesquels les donnes passent "en clair" en intercalant entre eux et la couche TCP une couche remplissant cette fonction avec les proprits suivantes : Transparence, aprs l'tablissement de la connexion, pour les 2 extrmits Authentification du serveur ou du client par certificat. Handshake incluant la ngociation des algorithmes de chiffrement les mieux adaptes au client et au serveur SSL utilise pour le chiffrement des messages une cl de session symtrique : transmise par mcanisme cryptographique cl publique. ventuellement rutilisable d'une session une autre pour diminuer le temps d'tablissement de la connexion. La couche SSL peut notamment s'intercaler entre TCP et HTTP : HTTPS implmenter dans le module apache mod_ssl . Le protocole HHTPS utilise le port 443 par dfaut, mais le changement est possible par une simple configuration.
Conclusion :
Limportance de cette tape est capitale car elle a permis dune part ltude du mode de communication en client-serveur Web et dgager les lments qui nous intresse pour ce projet dans la partie programmation de scripts CGI et dautre part de prparer lensemble de la plate-forme matrielle et logicielle sur laquelle sera implment le code source de lapplication dont il sera question dans le chapitre qui suit.
53
Chapitre 6 Interface Web base de donnes et organigrammes
Introduction : Pousss par le march, les diteurs de SGBDR ont dvelopps des passerelles de plus en plus sophistiques entre le Web et les bases de donnes. Les nouvelles architectures pour le data-Web, cest dire le couplage du Web et les bases de donnes, ncessitent dtendre HTML pour saisir les donnes et requtes, rendre dynamique les serveurs Web et augmenter la bande passante entre le SGBDR et lapplication. Ces architectures sarticulent sur trois niveaux dsormais classiques : le premier gre linterface utilisateur du navigateur, le second hberge le serveur Web et le complte par le serveur dapplication, et le troisime assure la gestion des donnes au sein du SGBDR. De mme, ce projet intgre la notion du data-Web et se base sur des passerelles qui permettent laccs aux donnes et la communication avec dautres serveurs.
43
TCP/IP
Serveur de base De donnes
FTP
E T H E R N E T
C G I
Utilisate ur1
Utilisateur2
Utilisateur n
TCP/IP
Serveur Web
Serveur vocal
H T T P
RTCP
Fournisseur de service Internet
Rseau de donnes
Figure 6.1 : Architecture de la solution propose
44
serveur Web et interfaces clients I- Choix techniques : CGI I.1- Dfinition
CGI est une norme dfinissant linterfaage dapplications externes avec des serveurs dinformation. Le programme tant initialement un fichier de commande Shell ou Perl. Rapidement, il est devenu un programme quelconque crit dans un langage compil ou interprt. En simplifiant , un script CGI est tout simplement un programme pouvant tre excut par un serveur http. I.2- Spcifications : Les spcifications CGI indiquent quelles informations doivent transiter entre le serveur et le programme CGI et de quelle faon elles doivent le faire. Les trois types de donnes sont : Des donnes dadministration concernant la requte passe au programme. Des donnes de formulaires en provenance du navigateur. Un nouveau document HTML rsultat du programme CGI pass au serveur Web pour tre renvoy au client. Comme les programmes CGI sont indpendants les uns des autres, ils peuvent tre crits dans nimporte quelle langage et le contenu de tel programme nest jamais rvl au navigateur. I.3-Istallation : Durant la configuration du serveur Apache, on doit spcifier le chemin du rpertoire contenant les scripts CGI ainsi que les extensions qui leur sont associes (cgi.pl ). Celui ci est gnralement appel cgi-bin/. Une fois le scripts est cod, on doit le rendre excutable et autoriser son excution. 1.4- Normalisation des CGI : La norme CGI spcifie une interface de communication base sur des variables dits variables denvironnements qui retournent des informations diverses et un mode dentre-sortie bas sur des flots standard de lecture et criture.
45
serveur Web et interfaces clients 1.4.1- variables relatives la requte : Variables Signification
CONTENT-LENGTH Taille en octet des informations jointes la requte CONTENT-TYPE Type de mime des donnes envoyes. Chane de caractres contenant les paramtres joints la requte En mode GET .Elle est vide en utilisant POST Contient la mthode utilise
QUERY-STRING
REQUEST-METHOD
Table 6.1 : variables CGI relatives la requte I.4.2- Variables relatives la connexion : Variable HTTP-accept HTTP-accept-langage HTTP-accept-encoding HTTP-accept-charset HTTP-accept-cookie HTTP-user-agent HTTP- reffer REMOTE-ADR REMOTE - HOST REMOTE-USER AUTH-TYPE REMOTE-PORT Signification Types MIMES supports par le client Langage utilis par le client Type dencodage support par le client Table de caractres supports par le client Liste des cookies associes par le client Information sur le client URL de la ressources ayant envoy la requte Adresse IP du client Adresse DNS du client Identifiant de lordinateur client Protocole utilis pour valider lidentit Port http utilis par le client
Table 6.2 : variables CGI relatives la connexion I.4.3- Variables relatives au serveur :
Variables
Signification
DOCUMENT-ROOT Nom du rpertoire contenant la racine du serveur GATEWAY-INTERFACE Version CGI supporte par le serveur HTTP-HOST Adresse IP du serveur SERVER-ADMIN SCRIPT-NAME Adresse e-mail de ladministrateur du serveur URL du chemin daccs au script CGI
46
serveur Web et interfaces clients SERVER-ROOT SERVER-PROTOCOL SERVER-SOFTWARE Port sur le quel le serveur a reu la requte Version du protocole http utilise par le serveur Nom et version du logiciel serveur utilis
Table 6.3 : variables CGI relatives au serveur 1.4.4- Entres- sorties : La norme CGI dfinit les rgles dentre-sortie entre le programme et le serveur Web. CGI reconnat trois entre- sortie standards : STDOUT : sortie standard. Elle est utilise par lapplication pour fournir au serveur Web les informations constituant la page HTML. STDIN : Entre standard. Elle est utilise pour recevoir les donnes en provenance du client. STDERR : Cest la sortie qui reoit les messages derreurs. II- Le langage Perl : II.1- Pourquoi Perl ? Perl est optimis pour extraire des informations de fichiers texte et gnrer des rapports bass sur ces informations. Cest aussi un bon langage pour de nombreuses taches dadministration systme. Il est crit dans le but dtre pratique. Perl combine les meilleurs fonctionnalits de C, sed, awk, sh et utilise des techniques sophistiques de recherche de motif pour pouvoir traiter trs rapidement de grandes quantits de donnes. Nous avons choisis ce langage version 5.6.0 pour ses qualits et performances dont nous citons essentiellement : Portabilit : Perl existe sue la plus part des plate-forme . Economie : il est disponible gratuitement sur Internet et dans ses versions les plus rcentes. Simplicit : quelques commandes en Perl est lquivalent dun programme de 500 lignes en code C . Robustesse : pas dallocation mmoire manipuler, chanes, piles, nom de variables illimit, Extensibilit : Perl peut tre intgr simplement dans des applications C ou C++ et peut indiffremment appeler ou tre appel par des routines travers une interface document. 47
serveur Web et interfaces clients II.2- Perl et CGI : Perl est devenu le langage numro un pour lcriture des scripts CGI. Il permet de gnrer du code HTML suite des traitements et calculs sophistiqus. Un scri pt CGI en Perl est rfrenc depuis le client soit dans lattribut ACTION dun formulaire, soit dans lattribut HREF dun lien ou par java script via lobjet location. La structure dun CGI en Perl dpend de la nature de lapplication mais il y a des points qui doivent tre respects : Indiquer le chemin de linterprteur Perl : # !/usr/bin/perl Gnrer un entte qui indique au client que le document envoy par le serveur est un document HTML : print content-type : text/html\n\n ; Utiliser des modules et des bibliothques spcifiques aux traitement des formulaires comme le module CGI : use CGI ; ou la bibliothque cgi-lib : require cgi-lib.pl ; II.3- Accs aux bases de donnes : Un des aspects les plus intressants de Perl est de permettre lintgration de requtes SQL dans un script CGI. Depuis sa version 5, on accde de la mme manire une base de donnes quelque soit le systme choisi. Et ce en utilisant les modules DBD et DBI et en spcifiant les caractristiques de la connexion.
# initialisation de la base de donnes use CGI ; # utilisation de module dinterfaage script-web use DBI ; # chargement dun module de pilote de base de donnes $ pfe =new CGI; # cration et initialisation dune variable CGI $dn=pfe->param(dn) ; # rcuprer la valeur de dn ( exemple) $dbh=->DBI connect(DBI : MYSQL : PFE ,nom dutilisateur,mot de psse,hte) # connexion la base de donnes nomme PFE. $sql= insert into client_moral vlues (.) # requte sql $dbh-> disconnect; # dconnexion de la base de donnes.
III- Aspect scurit : III.1- Aperu gnral : Proposer des formulaires et des scripts CGI est le plus grand risque en matire de scurit pour un service Web. Etant donn quun script CGI est excutable, son utilisation correspond laisser nimporte qui excuter un programme sur notre ordinateur. Mme sil est excut avec des droits limits il est possible davoir accs
48
serveur Web et interfaces clients des fichiers sensibles comme le clbre /etc/passwd contenant les mots de passe crypts des utilisateurs . III.2- Comment se protger ? Il existe trois principes gnraux en matire de prvention guidant lusage des scripts : Les donnes entres de lutilisateurs doivent tre analyses et vrifies. Un script doit tre soigneusement crit de manire vrifier les donnes reus, sassurer quelle excutent des actions lgales et non pas des instructions qui peuvent planter la serveur . Les scripts doivent tre limits au strict ncessaire en matire de puissance. Dans le cadre des serveurs Multi-Utilisateurs, les scripts doivent sexcuter avec le minimum de privilges systme et jamais avec les privilges du super user. IV- Organigrammes : Ce langage nous a permis de dvelopper les programmes dont les organigrammes sont les suivants :
49
page d'acceuil
Inscription client-moral
Consultation
Inscription client-physique
Lien hypertext
Gnration du formulaire inscription client-physique
Les champs ont ils Remplis ?
message d'erreur
Password conforme et > 6 caractres
message d'erreur
Test DN: 8digits
message d'erreur
Code postal correct?
message d'erreur
A 50
C.I.N. correct?
message d'erreur
Connexion la B.D.
Vrification du DN et C.I.N. propritaire existante de DN?
Gnration d'un formulaire derreur
Formulaire SORRY
Chargement des tables adquates
/mise jour compteur initial
Dconnexion B.D.
Gnration du formulaire inscription valid
51
serveur Web et interfaces clients 2
bouton de commande
Spcifiant le nombre des DN
Gnration du formulaire client-moral
les champs sont ils remplis?
message d'erreur
les nbres de DN ont ils corrects?
message d'erreur
les DN se rassemblent?
message d'erreur
Password correct?
message d'erreur
Code postal correct?
message d'erreur
C 52
Connexion au B.D pour vrification
Client dj Inscrit ? Gnration dun formulaire Derreur
Login utilis par un autre client ?
Chargement des tables adquates
Gnration du formulaire Inscription valid
53
consultation
lien hypertext
Gneration formulaire consultation
les champs ont ils remplis?
message d'erreur
connexion la B.D. vrification PSW/login personne physique ou moral
PSW et login Correct ?
message d'erreur
Test des dates 1/4, 1/7, 1/10,1/1
(C jour-Cinitial)*0.6
(C jour-Cinitial)*0.6+8d
Gnration de la Facture 54
Conclusion :
La mise en place des diffrents modules CGI du projet nous ont permis de matriser un bon nombre de techniques et outils de dveloppement Internet. Les notions prsentes jusquici nous permettent de passer la part ie applicative ( une dmonstration relle ) de notre projet de fin dtudes, ce qui fera lobjet du chapitre suivant.
55
Installation et mise en service de linterface X 25 la maquette EWSD
Chapitre 7 Installation et mise en service de linterface X 25 la maquette EWSD de lISETCom
INTRODUCTION : La mise au point de la maquette EWSD de lISETCom a pour but de dmontrer un cas rel du rseau tunisien , pour cela on a appliquer la procdure ncessaire Afin dassurer le transfert automatique des fichiers de taxation vers notre serveur de base de donnes . Pour connecter un terminal dexploitation et de maintenance lEWSD via une liaison de donnes X.25, deux possibilits sont offertes. Soit travers des connexions directes (point point), soit via un rseau publique de communication de donnes X.25. Dans notre cas , on se rfre aux connexions directes comme type de rseau X25LC. Les processeurs distants comme un terminal sont identifis au moyen des adresses OSI et des informations DTE (quipement de terminal de donnes) administres dans la base de donnes du processeur de coordination du centre de commutation EWSD.
67
I.1- Prsentation du rseau OSI : Un rseau OSI permet ltablissement dun circuit virtuel entre deux DTE (processeurs) selon le modle de rfrence de couche ISO 7. A laide de ladresse DTE et de ladresse NSAP (Point daccs de service de rseau), tous les processeurs ainsi que les applications appropries sont identifis de faon univoque. Un lien de communication entre des applications locales et distantes peut tre fourni, soit avec des PVC (Circuits virtuels permanents), soit avec des SVC (Circuits virtuels commuts). II- Adresses didentification du terminal : Trois adresses sont ncessaires pour identifier un terminal raccord au processeur de coordination de EWSD via une connexion de donnes X25 : II.1-Adresse X.25 : Le protocole X.25 fournit deux champs, le champ dadresse (AF) et le champ dextension dadresse (AEF) pour la transmission dadresses DTE et NSAP. Le champ dadresse (AF) est utilis pour lidentification du terminal de rseau dans le rseau X.25 et contient ladresse DTE value en couche 3. Le champ dextension dadresse (AEF) contient ladresse NSAP, avec laquelle il est possible didentifier une application particulire. Pour lexploitation et maintenance dEWSD via X.25, il faut sadresser OSI via AEF. Dfinition avec commande CR X25DTE, paramtre FACIL=AEFIN&AEFOUT. La fig. suivante indique le procd dadresse tel quil sera applicable pour un rseau dexploitation et de maintenance via X.25 standard.
Dialogue
transfert de fichier
Application , couche 7 Prsentation, couche 6 Session, couche 5 Transport, couche 4
Dialogue
transfert de fichier
NSAP adr 1
NSAP adr
Point daccs de service rseau Rseau, couche 3 Liaison de donnes, couche 2 Physique, couche 1
NSAP adr 3
NSAP adr
DTE adresse a protocole X25
DTE adresse b protocole X25
Figure 7.1 : Procd dadresse pour un rseau dexploitation et de maintenance via X25
68
II.2- Adresse DTE : Une adresse DTE est assigne une terminaison X.25 particulire et dfinit le port "physique" dans un rseau X.25. Selon les recommandations CCITT X.121, 14 chiffres dcimaux DTE peuvent tre utiliss comme adresse pour les rseaux X.25. Pour les connexions directes ( 25LC) 15 chiffres dcimaux constituent un maximum pour X ladresse DTE. Les adresses distantes DTE dans les types de rseaux X25 et ISDN sont cres avec CR X25DTE tandis que toutes les adresses locales DTE et distantes DTE dans le type de rseau X25LC doivent tre cres avec la commande MML CR X25ROUTE. Les valeurs de ladresse DTE peuvent tre choisies librement, du moment quelles nempitent pas sur des entres de base de donnes dj existantes. Cependant, si un X.25 DCN (PSPDN) public est utilis, les adresses DTE devront tre commandes depuis la gestion PSPDN. II.3- Adresse NSAP : Au moyen de ladresse NSAP, fournie dans le champ dextension dadresse du protocole X.25, une application spcifique est slectionne. Le point daccs du service rseau (NSAP) dfinit le seuil entre la couche rseau (couche 3) et la couche transport (couche 4) dans le modle de rfrence OSI. Ladresse NSAP identifie un certain point daccs du service rseau avec son application associe et se compose de 3 champs.
Ladresse DTE est assigne de faon univoque la partie IDI dune adresse OSI (NSAP) dans un rseau X.25 par l mme, toutes les adresses avec une certaine valeur IDI sont assignes au mme DTE et doivent tre attribues au mme et unique processeur. Cependant, le NSAP pour connexions directes ne contient pas de valeur IDI (IDI=0).Le type de connexion X.25 au CP dtermine la valeur AFI utiliser pour les adresses NSAP. Certaines applications (dialogue dimpression, transfert de fichier) peuvent tre slectionnes avec la partie DSP. Le tableau suivant indique les diffrences entre les types de rseau X25, X25LC et ISDN avec les formats et valeurs possibles AFI = Authority Format Identifier
Figure 7.2 : types de rseau et valeurs AFI, IDI et DSP associes IDI = Initial Domain Identifier, DSP = Domain specific
69
III- Connexion directe (Type de rseau X25LC) : Cette configuration reprsente un rseau non ouvert avec une seule connexion point point et galement dfinie comme un rseau local (X25LC). Le schma ci-dessous prsente les diffrents cas de figures adapts pour une connexion directe au systme EWSD . Dans notre projet on a choisit la premire solution , cest la plus simple raliser, et vue lindisponibilit du matriels pour les autres .
Figure 7.3 : Diffrentes possibilits de connexion de linterface X 25
70
IV- Installation et procdures de gestion : Pour installer un rseau dexploitation et de maintenance X.25, il est recommand de suivre les tapes de base suivantes. Si la base de donnes du processeur de coordination dEWSD est cre en premier, toutes les donnes ncessaires pour linstallation logicielle du terminal seront dtermines. Le DTE du terminal et les adresses NSAP ainsi que le nom du processeur tel quil est entr dans la table du processeur de coordination sont demands lors de linstallation logicielle du terminal dexploitation et de maintenance. 1. Installer IOP:LAU (cartes LCUB et LAUB) dans la baie CP (B:IOC) incluant le cblage. 2. Crer les entres de la base de donnes de processeur de coordination pour X.25 (IOP, liaisons, applications, adresses, etc.). 3. Installer le matriel requis (carte EICON X.25) et les ensembles logiciels (pilote X.25, BCTcommun, openft), sur le terminal appropri.
Figure 7.4 : Squence de gestion et dinstallation X 25
71
IV.1- Cble IOP pour connexion directe (X25LC) : Le systme EWSD offre plusieurs possibilits de raliser une liaison de donnes point point : Cble pour connexion directe locale IOP:LAU <--> terminal qui doit tre quip dune carte rseau X25 EICON. Connexion directe via modem (DAG 64) ncessitant un cble type : IOP:LAU <--> modem DAG 64 ( interface X.21) Connexion directe via ISDN ncessitant un cble type : IOP:LAU <--> Adaptateur terminal X.21/X.21bis (interface V.36):
IV.2- Base de donnes pour la cration dun lien X25 :

La procdure complte de la cration dune liaison de donnes X25 dans un centre de commutation EWSD type CP113 est comme suit : Dfinition des processeurs dentrs sorties (IOPLAU) : La position du LAUB est 273 dans les F:IOP-0 et -1 la position du LCUB est 285 dans les F:IOP-0 et -1 <CR IOP: IOC=0,BIOC=15,IOP=IOPLAU-0,BIOCR=15,IOPR=IOPLAU1,LOADTP=100; Configuration de IOP:LAU : <CONF IOP: IOP=IOPLAU-0,OST=MBL; <CONF IOP: IOP=IOPLAU-1,OST=MBL; <CONF LAU: LAU=0,OST=MBL; <CONF LAU: LAU=1,OST=MBL; Cration de la liaison de donnes X 25 : <CR X25LINK:X25LINK=2,LAU=0,CHAN=0,PRTCL=X25,NET=ISDN, #L1DTT=DTE,L1IF=X21,L1MCA=1,L2DTT=DTE,L2LAM=RESPON, #L1BAUD=B64000, #L2N1=135,L2N2=7,L2K=7,L2T1=3000,L2T2=300,L2T3=20000, #L3DTT=DTE,L3R20=1,L3R22=1,L3R23=1,L3T20=180,L3T21=200, #L3T22=180,L3T23=180,L3T24=60,L3T25=150, #L3TCB=1&&32; <CONFX25LINK:X25LINK=2,OST=MBL; <CONFIOP:IOP=IOPLAU-0,OST=ACT; <CONFLAU:LAU=0,OST=ACT;
72
<CONFIOP:IOP=IOPLAU-1,OST=ACT; <CONFLAU:LAU=1,OST=ACT; <CROSIADR:ADRNAM=OSILDG,NSADR=48-0-101,NET=X25LC; <CROSIADR:ADRNAM=OSILFT,NSADR=48-0-109,NET=X25LC; <CROSIADR:ADRNAM=OSIRDG,NSADR=48-0-1010,LOCADR=OSILDG, NET=X25LC; <CROSIADR:ADRNAM=OSIRFT,NSADR=48-0-1090, LOCADR=OSILFT, NET=X25LC; <CRAPPL:APPLID=DIALG,PRONAM="KHER2",ADRNAM=OSILDG; <CRAPPL:APPLID=NEABD,PRONAM="KHER2",ADRNAM=OSILFT; <CRAPPL:APPLID=DIALG,PRONAM="BCT",ADRNAM=OSIRDG,AUT=1; <CRAPPL:APPLID=NEABD,PRONAM="BCT",ADRNAM=OSIRFT; <CRX25DTE:DTENAM=DTELBCT,ADRNAM=OSILDG&OSILFT,NET=X25LC; <CRX25DTE:FACIL=AEFIN&AEFOUT,DTENAM=DTERBCT,ADRNAM=OSIRDG& OSIRFT,NET=X25LC; <CRX25ROUTE:ROUTNAM=RTLBCT,DTENAM=DTELBCT,DTEADR=111, X25LINK=2,FACIL=FLOWNEG,WNDSZ=7-7,PCKSZ=128-128; <CRX25ROUTE:ROUTNAM=RTRBCT,DTENAM=DTERBCT,DTEADR=11000, X25LINK=2; <CRPRO:PRONAM="BCT",PROTYP=OSS;
Activation de IOP:LAU et de la liaison X 25 : <CONF IOP:IOP=IOPLAU-0,OST=ACT; <CONF IOP:IOP=IOPLAU-1,OST=ACT; <CONF LAU:LAU=0,OST=ACT; <CONF LAU:LAU=1,OST=ACT; <CONF X25LINK:X25LINK=2,OST=MBL; <CONF X25LINK:X25LINK=2,OST=ACT; V- Protocole FTP : V.1- Prsentation : FTP est la protocole qui dfinit les transferts de donnes sur un rseau. On lutilise en gnral partir de logiciels aux noms vocateurs, qui sappellent directement FTP, ou bien qui contiennent FTP dans leurs noms ( exemple openft ) . Les objectifs de ce protocole sont de permettre un partage de fichiers ou programmes sur des machines distantes, de permettre des modifications distance sur des fichiers, et de transfrer des donnes via un rseau. Bien quutilisable par un utilisateur directement depuis un terminal, FTP est pratiquement utilis par lintermdiaire de programmes. Ce protocole a t mis en place ds 1971.
73
V.2- Les commandes FTP : Il existe plusieurs types de commandes qui peuvent tre envoyes sur la connexion de contrle. En voici quelques chantillons : V.2.1- Contrle daccs : USER NAME (user): Largument est une chane Telnet identifiant lutilisateur. Cest cette identification qui est requise par le serveur pour pouvoir accder son systme de fichiers. PASSWORD (PASS) : Largument est une chane Telnet spcifiant le mot de passe de lutilisateur. Cette commande doit tre prcde par immdiatement par USER NAME. REINITIALIZE (REIN) : Cette commande achve la commande USER, annulant toutes les informations dentres-sorties, except les transferts en cours qui sont autoriss sachever. V.2.2- Paramtres de transfert : DATA PORT (PORT) : Largument est un numro de port machine pour pouvoir tablir la connexion pour les donnes. FILE STRUCTURE (STRU) : Largument est un simple caractre Telnet spcifiant la structure du fichier ( exemple : F (file), R (record structure)). TRANSFERT MODE (MODE) : Largument est un simple caractre Telnet spcifiant le mode de transfert des donnes exemple : B (block), C (compressed). V.2.3- Services FTP : RESTART (REST) : Largument reprsente le marqueur auquel le transfert doit tre repris. RENAME FROM (RNFR) : Pour renommer un fichier. ABORT (ABOR) : Indique au serveur quil doit abandonner la commande FTP prcdente. V.3- Les rponses FTP : Les rponses sont l pour sassurer de la synchronisation entre le client et le serveur. Toute commande gnre au moins une rponse, et dans le cas ou il y en a plusieurs, elles doivent pouvoir se distinguer sans ambigu t. Les rponses sont composes 74
dun numro trois chiffres, utile pour les programmes , et dun texte, pour lutilisateur humain. Voici la signification de quelques codes renvoys par le serveur : 1yz : rponse prliminaire positive 2yz : rponse positive de ralisation 3yz : rponse intermdiaire positive Conclusion : Dans cette partie on a eu loccasion dapprofondir nos connaissances au systme de commutation lectronique EWSD, et damlior notre exprience professionnelle pour mettre la maquette au point afin de dmontrer un cas rel. Cette tape tant crucial dans le dveloppement de notre projet de fin dtudes, car cest dans cette phase que toutes nos connaissances ont t conjugues afin daboutir une ralisation cohrente .
75
Conclusion gnrale
Conclusion gnrale
Dans ce projet, il nous a t confi ltude , la conception et la ralisation dune plate forme de tl facturation tlphonique sur Web, permettant un abonn non prpay de consulter sa facture dune faon journalire. Nous avons procder de manire concevoir une base de donnes, dvelopper les modules de traitement qui permettent laccs la base ds le serveur web, ainsi dassurer le transfert automatique des fichiers de taxation depuis la maquette EWSD vers notre serveur de base de donnes, il nous a t possible dtablir une configuration rpondant aux exigences du cahier des charges. Le travail que nous avons effectu tout au long de llaboration de ce projet de fin dtude, nous t bnfique renforc nos connaissances dans ce domaine, nous pouvons dire que ce projet t un complment de formation fondamental pour regrouper plusieurs disciplines et consolider plusieurs donnes thoriques. En perspectives nous pourrons rendre notre plate forme de tl facturation tlphonique via Internet extensible vers la voie vocale sur RTCP, par dveloppement du serveur adquat, ou aller plus loin vers la voix sur IP, ce que pourrait faire lobjet dun travail dtude pour dautres tudiants.
76
Bibliographie
Bibliographie
Les ouvrages
& George Gardarin & Paul Valduriez Bases de donnes relationnelles :

analyse et conception Eyrolles 1988
& Paul Gaborit Documentation Perl Ecole des Mines dAlbi 2000 & George Gardarin & Olivier Gardarin Le Client Serveur Eyrolles 1996
Sites Web 6 6 6 6
http://www.mysql.com (manuel de documentations et cours) http://www.mysql.org (tlchargement du MySQL) http://www.linux_france.org/prj/inetdoc (documentation linux) http://www.perl.com (documentation Perl) ( prsentation des protocoles http, ftp,
6 http://www.commentamarche.net
TCP/IP)
6 6
http://www.alianwebserver.com/informatique/linux/apache.htm (installation et configuration dapache) http://www.trucsweb.com/securite/ ( scurit des serveurs web)
6 http://www.mandrake.org (obtention des logiciels)
77
Glossaire
Glossaire
Ce glossaire explique les mots cls rencontrs dans le prsent manuel. Ils sont classs par ordre alphabtique. ANSI : (American National Standards Institute) Organisation amricaine charge de dfinir des normes. APACHE : Cest un serveur Web ( logiciel). Browser: Un programme qui permet de lire des documents Web. Netscape est un browser. Le terme franais est navigateur. CGI : (Common Gateway Interface) ce sont les programmes qui sont lancs sur le serveur http aprs envoi par un lecteur d'un formulaire. Client : C'est un programme qui est utilis pour contacter un serveur. On parle alors de modle client-serveur. L'avantage du modle est que le client sait faire un certain nombre de tches et ne soumet au serveur que les informations ncessaires. D'autre part un serveur peut fournir des clients sur PC Macintosh ou machine Unix. Connexion : Installation permettant de relier un ordinateur au rseau Internet. Ethernet : protocole de communication de bas niveau (cbles, cartes et logiciel) permettant des ordinateu rs de communiquer sur un rseau local. Ethernet de base permet de communiquer 10 Mb/s, Ethernet base 100 permet de communiquer 100 Mb/s. EWSD : cest un systme de commutation lectronique fournit par SIMENS . FTP : (File Transfer Protocol) protocole d'change de fichiers entre sites informatiques. En gnral les sites ouverts au public sont dits anonymous ftp car le nom de login est anonymous. HOST : ordinateur sur lequel on se connecte (hte). HTML : (Hyper Text Markup Langage) Les pages Web sont crites dans un format assez simple, appel HTML. On peut voir le contenu d'une page HTML dans un des menus dun lecteur de Web en demandant voir le code source. HTTP : Un serveur http est un serveur charg d'envoyer les pages Web (en HTML) un ordinateur, lorsque on lis une page Web (hyper text transfer protocol). HTTPD : Hypertext transfert protocole daemon : processus qui tourne en arrire plan et qui assure le service http. 78
Glossaire HTTPS : cest du http scuris via SSL ( secure sockets layer) . Hypertexte : Ce sont des textes marqus dans un document qui permettent de naviguer vers d'autres documents. On pourrait parler de lien. Les hypertextes sont d'une couleur particulire pour tre facilement identifiables et ils changent de couleur une fois uti lise. Login : c'est votre nom de connexion sur un ordinateur. Vous donnez ce nom par un message d'invite que vous remplissez soit au moment o vous vous connectez sur un autre ordinateur, soit en commenant travailler sur votre ordinateur. Microsoft IIs : (internet information server), cest un type de serveur Web. Microsoft PWS : (personnel Web server), cest un serveur Web personnel. MIME : (Multi Purpose Internet Mail Extensions) Systme d'encodage permettant d'expdier fichiers attachs aux courriers lectroniques. Naviguer : action de se promener de site Web en site Web au moyen d'un logiciel de visualisation de Web. Le terme fureter est prfr par les Qubecois. Page d'accueil : premire page d'un site Web Password : Mot de passe accompagnant votre nom d'utilisateur (login) et permettant d'assurer la confidentialit de votre compte. Il est personnel et confidentiel (comme un numro de carte bleue). Gnralement les logiciels affichent votre mot de passe avec des toiles. Perl : ( Pratical extraction and report language) cest un langage de scripts, on peut lutiliser sans compilation. Port : Numro prcd du symbole : dans certaines adresses. Cet artifice permet de mettre plusieurs serveurs sur une mme adresse avec une diffrenciation par le numro de port. Protocole : le mot protocole dsigne en gnral les messages changs entre deux machines. L'intrt d'un protocole est de dfinir des mthodes d'change d'information, indpendantes des matriels. Ainsi, une fois le protocole dfini, chaque terminal ou client ou serveur implmente ce protocole sans se soucier des autres ordinateurs. Serveur : un ordinateur qui fournit des services des clients. Il fournit ces services des ordinateurs par des messages ce qui permet d'avoir plusieurs type de clients. SGBD : cest labrviation du systme de gestion de base de donnes. SGBD-O : systme de gestion de base de donnes objet. SGBD-R : systme de gestion de base de donnes relationnel. SQL : (Standard query language) langage standard des requtes. TCP/IP : TCP/IP est le nom de la partie cache de l'Internet. Il existe plusieurs protocoles rseau (Netware, LanManager...). TCP/IP est le plus propice aux interconnexions de rseaux. Il existe beaucoup de rseaux TCP/IP qui ne sont pas relis l'Internet.
79
Glossaire Telnet : logiciel permettant de se connecter sur un serveur pour y excuter des commandes. TN3270 : Logiciel permettant de se connecter sur un host IBM. UNIX : systme d'exploitation multitche multi -utilisateurs a temps partag. URL : (Uniformed Resources Locator) Ce sont des textes de couleur diffrente (par dfaut ils sont en bleu) dans un document qui permettent lorsqu'on clique dessus avec la souris d'aller vers l'endroit rfrenc. Web : en franais, toile d'araigne ; symbolise le rseau maill de serveurs d'informations formant une toile d'araigne. Ces serveurs vont des pages personnelles aux interfaces de base de donnes. Par extension on parle de Web pour un serveur de page HTML. WWW : (World Wide Web) Systme mondial d'interconnexion des informations par le protocole Web.
80

SUP24

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SUP24

Transféré par

Droits d'auteur :

Formats disponibles

RAPPORT DE PROJET DE FIN DETUDES

Filire Ingnieurs des Travaux

Etude, Conception et ralisation dune plate-forme de tl-facturation tlphonique journalire

Taghlet Moez Barhoumi Mourad

Anne universitaire : 2001/2002

Liste des tables

Liste des figures

Cahier des charges du projet du projet

Cahier des charges du projet

Notion de systme de donnes et problmatiques de la conception

Chapitre 1 Notion de systme de donnes et problmatiques de la conception

Analyse et Inventaires des problmes

Notion de systme de donnes et problmatiques de la conception

1-Utilisateur sans systme informatique

Ensembles dentits et dassociations du monde rel

Ensembles des fichiers logiques vues les usagers (sous-schmas)

systme de gestion de la base

ORGANISATION LOGIQUE GLOBALE

structure globale logique de la base (schma)

systme de gestion de la base ORGANISATION PHYSIQUE DE STOCKAGE

structure physique de la base

Figure 1.2 : Systme daccs aux donnes

Notion de systme de donnes et problmatiques de la conception

Notion de systme de donnes et problmatiques de la conception

Transformation et modle logique

Schma logique Schma interne

conception dtaille de la base de donnes

Chapitre 2 Conception dtaille de la base de donnes

conception dtaille de la base de donnes

conception dtaille de la base de donnes

conception dtaille de la base de donnes Tracer le du modle relationnel des donnes.

Abonn et/ou relation

Catgorie Catgorie dabonn et dabonnement

conception dtaille de la base de donnes

Nom Prnom Rue Ville numro code postal

Nom dutilisateur cl primaire de la table

Mot de passe suprieure 6 caractres cl primaire de la table

conception dtaille de la base de donnes dn Numro dannuaire Cl primaire de la table

Compteur tlphonique du dbut du trimestre

Compteur tlphonique journalier transferer ds la Maquette EWSD Nom dutilisateur

Mot de passe suprieure 6 caractres

Table 2.1 : numration des entits de la base de donnes tl facturation

Architecture de la solution propose

Chapitre 3 Plate-forme de tl facturation : architecture de la solution propose

Architecture de la solution propose

I-Architecture de la solution propose :

Serveur de base De donnes

Serveur Web TCP/IP

RTCP Serveur vocal

H T T P Fournisseur de service Internet

Figue 3.1 : Architecture de la solution propose

Architecture de la solution propose

Mcanisme dtablissement des factures

Figue 3.1 : Architecture de la solution propose

Architecture de la solution propose

II- Solution ralisable sur la maquette EWSD de LISETCOM

Serveur BD et serveur WEB

Ralisation et implmentation de la base de donnes

Chapitre 4 Ralisation et implmentation de la base de donnes

Ralisation et implmentation de la base de donnes

Correspondance Externe-conceptuel (indpendance logique)

Correspondance interne-conceptuel (indpendance physique)

Figure 4.1 : Architecture fonctionnelle des SGBD-R

Ralisation et implmentation de la base de donnes