documentation partie Java - Département Informatique

Projet de fin d’étude
Option ILR
Passerelle WEB/ORACLE
Antoine Sejournet
Jérôme Pellegrin
2
Table des matières
1. Technique côté serveur .............................................................................................. 3
1.1. CGI ............................................................................................................................................. 3
1.2. Servlets Java .............................................................................................................................. 4
2. Présentation de la passerelle ..................................................................................... 4
2.1. Aperçu de son rôle ..................................................................................................................... 4
2.2. Les paramètres d’utilisation ....................................................................................................... 4
3. Description de l’application ...................................................................................... 6
3.1. Systèmes et structure de l’application ....................................................................................... 6
3.2. Code JAVA ................................................................................................................................ 7
3.3. Modèle de données XML et les feuilles de style XSL .............................................................. 8
3.4. Méthode de développement ....................................................................................................... 8
4. TODOS ........................................................................................................................ 9
3
1. Technique côté serveur
Il y a quelques années, la seule solution permettant d’envoyer des données dynamiques sur le
Web était l’interface CGI. Les programmes CGI offraient un moyen simple de créer des applications
WEB acceptant les données de l’utilisateur, et interrogeant une base de données, puis envoyant les
résultats au navigateur. Les développeurs de serveur WEB ont élaboré des interfaces de programmation
(API), afin de développer du code in-process utilisé pour traiter les requêtes WEB. Les dernières
technologies WEB côté serveur sont appelées servlets Java, JSP (Java Server Pages) et pages ASP
(Active Server Pages).
1.1. CGI
CGI est la technologie WEB côté serveur la plus courante. C’est pourquoi les programmes CGI
sont pris en charge par la plupart des serveurs WEB actuels. Un programme CGI peut être écrit dans
presque tous les langages de programmation. Pourtant le langage le plus utilisé est le langage PERL.
Les serveurs WEB qui mettent en œuvre CGI agissent comme une passerelle entre la requête de
l’utilisateur et les données dont elle a besoin. Pour cela, ils commencent par créer un processus dans
lequel le programme sera exécuté (voir figure 1). Ensuite, ils chargent les environnements d’exécution
nécessaires, ainsi que le programme. Enfin, ils transmettent une requête et appellent le programme. Une
fois le programme terminé, le serveur WEB lit la réponse dans le STDOUT.
Figure 1: Fonctionnement d’un CGI
L’inconvénient majeur de CGI réside dans son manque d’évolutivité. En effet, chaque fois que le
serveur WEB reçoit une requête, un processus est créé. Il est aisé de deviner ce qui se produit sur le
serveur lorsqu’un grand nombre de requêtes sont reçues au même moment. Dans ce cas, le serveur est
très sollicité et peut même planter.
Serveur WEB
Interface CGI
Processus 1
Environnement d’exécution
Variable d’environnement
Programme
Processus 2
Environnement d’exécution
Variable d’environnement
Programme
Processus 3
Environnement d’exécution
Variable d’environnement
Programme
4
1.2. Servlets Java
Une alternative aux scripts CGI est la technologie servlet Java. Cette technologie est intégrée à
l’API J2EE permettent l’interconnection des programmes avec les services et les données de
l’entreprise. Elle permet de créer facilement des pages dynamiques et d’enrichir les fonctionnalités
d’un serveur WEB.
Une servlet Java est un programme côté serveur qui traite les requêtes HTTP et renvoie des
résultats sous forme de réponse HTTP. A cet égard, Java ressemble beaucoup au CGI, mais la
comparaison s’arrête là. Une servlet est comme une applet dépourvue d’interface graphique, qui
s’exécute sur le serveur WEB. Son cycle de vie est semblable à une applet et elle s’exécute au sein
d’une machine virtuelle.
Un des avantages des servlets sur les CGI est que lorsqu’un utilisateur émet une requête relative à
une servlet particulière, le serveur utilise simplement un autre thread et non un autre processus, puis
traite la requête en question. Les performances n’en sont qu’améliorées car plusieurs requêtes ne
génèrent pas systématiquement plusieurs processus. L’autre avantage majeur est la portabilité due à
l’utilisation de la machine virtuelle pour l’exécution des servlets.
2. Présentation de la passerelle
2.1. Aperçu de son rôle
Le principe de fonctionnement de la passerelle est rigoureusement identique à celui de sa
précédente version écrite par Bruno Defude en Pro C et appelée par l’intermédiaire d’un script CGI. Un
ensemble de formulaires plus ou moins complexes font appel à la passerelle pour interagir de manière
structurée avec un serveur Oracle. La construction de ces formulaires est l’œuvre du webmaster mais
n’entre pas dans la conception de la passerelle.
Dans le cas de la passerelle CGI, tous les formulaires font appel à un script CGI unique résidant
sur le serveur dont la réponse est modulable selon les valeurs des paramètres transmis par le formulaire
de départ. Au niveau du serveur, un serveur WEB reçoit les requêtes HTTP des utilisateurs et transmet
ces requêtes à la passerelle qui analyse les paramètres, interroge le serveur Oracle, puis formate le ou
les résultat(s) au format HTML.
2.2. Les paramètres d’utilisation
La description des paramètres se trouve en ligne sur le site BD de l’INT. Néanmoins, leur
utilisation est légèrement différente avec notre version finale de la passerelle.
Nous allons voir la liste des variables à positionner avec les valeurs possibles et leurs inter-
dépendances. Nous donnons ici la liste des variables en précisant celles qui sont obligatoires ou non.
Les noms de variables sont donnés ici en minuscules et doivent être déclarée en minuscules :
uid : obligatoire, donne la chaîne de connexion à Oracle (par exemple
sqlstatement : obligatoire, donne la requête SQL à soumettre à Oracle (si elle n'est pas utilisée,
comme dans le cas d'une insertion, on peut lui mettre une valeur vide). Par exemple « select *
from applivins ».
mode : obligatoire, donne le mode avec lequel on veut lancer le programme. Les différentes
valeurs sont les suivantes (doivent être données en majuscules) :
- NOR (pour NORmal) : c'est le mode standard dans le sens ou aucun traitement
particulier n'est fait, si ce n'est exécuter la requête transmise et afficher le résultat.
5
- INS (pour INSertion) : c'est le mode qui permet de sélectionner une relation (indiquée
dans la variable table qui doit alors être positionnée) pour produire un formulaire
d'insertion d'un tuple dans celle-ci.
- MAJ (pour Mise A Jour) : c'est le mode qui permet de sélectionner une relation
(indiquée dans la variable table qui doit alors être positionnée) pour produire un
formulaire d'insertion d'un tuple dans celle-ci.
- COP (pour COPie) : ce mode permet de générer un formulaire permettant de copier la
valeur d'un attribut retourné dans une variable d'un autre formulaire
- QBE (pour Query By Example) : c'est le mode qui permet de générer un formulaire
d'interrogation la QBE" pour la relation sélectionnée (donnée dans la variable table
qui est donc obligatoire pour ce mode). L'interrogation se fait en saisissant les
contraintes dans les colonnes de la relation (cela s'exprime sous la forme d'un opérateur
de comparaison, = par exemple, suivi d'une constante ou d'un nom d'attribut.
- HYP (pour (HYPpertexte) : c'est le mode qui permet une navigation dans la base. Le
point de départ doit être une requête SQL de type SELECT. Le principe de la navigation
est d'interpréter les clés primaires comme donnant un accès en mode NOR au tuple
sélectionné et les clés étrangères comme donnant un accès en mode NOR au tuple
sélectionné. Les clés primaires et étrangères peuvent être soit calculées à partir du
dictionnaire de données (si la requête spécifiée porte sur une seule relation) ou bien
données dans les variables pkey et fkey. Pour distinguer à l'affichage les clés primaires
et étrangères, nous utilisons la couleur bleu dans les boutons représentant les clés
primaires et la couleur rouge pour les clés secondaires. Lors du premier appel en mode
HYP, les boutons permettant la génération des formulaires d'interrogation type QBE et
d'insertion d'un tuple sont générés.
pkey, obligatoire en mode HYP si la requête porte sur plus d'une relation (sauf si fkey est
présente). La valeur de pkey est une liste (d'au moins un élément) de couples nom d'attribut,
nom de relation. Le séparateur entre attribut et relation est le caractère « : » et le séparateur
entre couples est le caractère « ; ».
Par exemple NUM:VINS;NVIN:RECOLTES .
Il faut noter qu'il ne faut pas de caractères blancs et que les noms d'attributs et de relations
doivent être en majuscules.
Les attributs et relations cités dans la variable pkey doivent apparaitre dans la requête donnée
dans la variable sqlstatement. Celle ci peut être multi-relations (c'est pourquoi un nom de
relation est associé au nom de l'attribut).
Seules les clés mono-attributs peuvent être utilisées. De même, l'ordre d'énumération des
couples doit être conforme à celui des attributs dans la clause SELECT de la requête.
fkey, obligatoire en mode HYP si la requête porte sur plus d'une relation (sauf si pkey est
présente). La valeur de fkey est une liste de triplets (d'au moins un élément) nom d'attribut (dans
la relation source), nom de relation cible, nom d'attribut dans la relation cible. Le séparateur à
l'intérieur du triplet est le caractère « : » et le séparateur de triplets est le caractère « ; ».
Si on veut indiquer que l'attribut NVIN de la requête est clé étrangère sur l'attribut NUM de la
relation VINS, on notera :
NVIN:VINS:NUM .
Si par hasard, le nom de l'attribut cible est le me que celui de l'attribut source, il peut être
omis (on aura alors un couple et non un triplet).
On retrouve également les contraintes de pkey portant sur les caractères majuscules et blancs,
l'appartenance des attributs sources à la requête, le fait que la clé doit être mono-attribut ainsi
que l'ordre d'écriture des triplets.
table, obligatoire en mode INS ou en mode HYP si pkey et fkey ne sont pas présentes. Par
exemple RECOLTES.
copy, optionnel, permet de produire comme résultat un formulaire permettant de copier la valeur
d'un attribut retourné dans une variable d'un autre formulaire. Ceci n'est possible qu'en mode
1 / 9 100%
La catégorie de ce document est-elle correcte?
Merci pour votre participation!

Faire une suggestion

Avez-vous trouvé des erreurs dans linterface ou les textes ? Ou savez-vous comment améliorer linterface utilisateur de StudyLib ? Nhésitez pas à envoyer vos suggestions. Cest très important pour nous !