Application de commerce électronique

Etape 1 - Serveur GICOM minimal

F. Boyer, S. Chassande, D. Feliot, S. Krakowiak, D. Donsez

Projet de DESS-GI option SRR  et RICM3 option SR

Année Universitaire 2001-2002

Université Joseph Fourier, Grenoble

PLAN

1. Fonctions fournies aux clients
2. Principes d'implémentation
3. Architecture du serveur GICOM
3.1 Choix
3.2 Servlets
3.3 Utilisation des servlets pour le serveur GICOM
3.4 Gestion des sessions client
4 Gestion des données
4.1 Principes d'implémentation
4.2 Base proposée
4.3 Driver JDBC
5. Utilisation des services support
5.1 Java
5.2 Servlets
5.3 JDBC
5.4 MySQL

URL des services utilisés

 J2SE au minimun 1.3 :  http://java.sun.com/products/jdk/1.3/docs/api/index.html
 Un support d'exécution des servlets ou/et de JSP : jswdk ou  Jakarta Tomcat (conseillé)
 La programmation des servlets http://java.sun.com/products/servlet/2.3/javadoc.

Bases SQL :
 MySQL : www.minet.net/devel/mysql et un driver JDBC fonctionnant avec MySQL : www.gwe.co.uk/java/jdbc

McKoi : http://www.mckoi.com/ (driver JDBC intégré)

 Informations générales sur les drivers JDBC :java.sun.com/products/jdk/1.3/docs/guide/jdbc/ et  java.sun.com/products/jdbc


 

L'étape 1 consiste à réaliser une première version du serveur de commerce électronique, dans laquelle on ne se soucie pas de son interaction avec les applications bancaires. La gestion des ordres d'achats n'est donc pas prise en compte dans cette étape.

1. Fonctions fournies aux clients du serveur GICOM

Le serveur GICOM doit rendre accessibles les fonctions de commerce électronique au travers du Web, c'est à dire qu'un client doit pouvoir utiliser ce serveur en lanceant un browser tel que Netscape. Pour cette raison, le "noyau" de l'application de commerce électronique sera mis en place sur un serveur Web, capable de recevoir et de traiter des requêtes HTTP.
Les fonctions principales fournies par le serveur sont les suivantes :

·        Sélection d'un magasin

·        Consultation des produits d'un magasin donné

·        Sélection d'un produit dans le but de le placer dans le cadie

·        Modification du contenu du caddie

·        Achat du contenu du caddie

2. Principe d'implémentation

Un client doit être capable d'accéder simplement aux catalogues de produits proposés par le serveur GICOM. Un navigateur (Explorer /  NetScape)  aux fonctionnalités minimales doit être suffisant. Deux approches sont possibles pour la conception de cette interface :

Cette dernière approche permet de "faire participer" la machine cliente à la gestion de la session de commerce électronique. En particulier, le "caddie " peut être géré côté client. L'applet cliente peut en outre se connecter au serveur GICOM via RMI (Remote Method Invocation), CORBA ou des sockets. Par contre, l'utilisation d'une applet rend inapplicable le principe des liens contenus dans des documents HTML. Le développement d'une véritable IHM est donc nécessaire. Du point de vue du développeur, l'effort de conception est plus important.

La solution retenue est celle des documents  HTML, dont la manipulation est bien connue des utilisateurs. Ces documents seront donc retournés par le serveur GICOM en réponse à des requêtes HTTP.

3- Architecture du serveur GICOM

3.1 Choix
Les services que propose le serveur de commerce sont plus complexes que le simple envoi d'un document HTML figé. Ils nécessitent l'exécution de programmes générant des réponses dynamiques. Par exemple, la page HTML qui sera retournée lors de la réception d'une requête de consultation du caddie client, sera dépendante du contenu de ce caddie.

Ces programmes qui vont générer les pages HTML peuvent être implémentés sous la forme de scripts CGI (Common Gateway Interface). L'interface CGI définit un standard dans la manière d'appeler un script et dans la manière de transmettre les données entre le démon HTTP et le script.
L'équivalent des scripts CGI proposé par Java est l'API des  Servlets. Les Servlets sont simples à développer et plus performants que les scripts CGI (cf 3.2). Nous avons donc choisi cette solution.

Le serveur GICOM aura en outre à gérer des données permanentes (catalogues de produits, etc). La gestion de cette permanence peut être assurée au travers de fichiers. Cependant, des accès associatifs devant être effectués au niveau de ces données, nous choisissons d'utiliser une base de données relationnelle (MySQL ou McKoi par exemple). L'accès à la base de données depuis les servlets Java nécessite l'emploi d'une interface de programmation. L'API standart Java Data Base Connectivity (JDBC) remplit cette fonction.

L'architecture résultant de ces choix est représentée sur la figure ci-dessous.

3.2 Servlets
Un servlet est un module pouvant s'exécuter à l'intérieur d'un serveur Web. Les servlets sont un substitut aux scripts CGI en étant plus simples à développer et plus rapides à l'exécution. En effet, le mécanisme CGI nécessite pour chaque requête le démarrage d'un processus " lourd ". Les servlets s'exécutent comme des threads dans un même interprête. Les changements de contexte sont donc plus rapides.
Le principe d'appel est le suivant. Par défaut, étant donné le nom d'une requête N, le serveur Web recherche la classe mettant en œuvre le servlet de nom N et l'exécute. Le lien entre le nom d'un servlet et sa classe est défini dans un fichier de déploiement fourni au serveur Web. Par exemple, la requête http://carbone:8080/ShoppingServer/ HelloWorldExample peut entrainer l'exécution du servlet HelloWorldExample.class. La méthode appelée dépend du type de la requête HTTP (GET, POST, PUT, etc). Bien entendu, dans l'exemple donné, un serveur Web doit tourner sur la machine carbone et être connecté au port 8080.
 

Traitement de requêtes HTTP :
Le diagramme de classes simplifié de l'interface Servlet est le suivant.



Lorsque le serveur charge un servlet pour la première fois, il exécute la méthode init, qui est implémentée par la classe abstraite GenericServlet et qui peut être surchargée par l'application pour effectuer certains traitements. La méthode service est implémentée par la classe HttpServlet.
La classe HttpServlet doit être étendue pour développer des servlets répondant à des requêtes HTTP.
Le protocole HTTP définit un mode simple de communication selon le modèle requête-réponse. Une requête HTTP est principalement composée du nom d'une méthode (action à réaliser) et d'une URL (Universal Ressource Locator) désignant l'objet recherché (document html, script à exécuter ... ). Les méthodes sont présentées dans le tableau ci-dessous :
 

Méthodes

Actions

GET

Retourne l'objet* spécifié. Dans le cas où l'objet est un servlet, la méthode doGet est exécutée.

POST

Demande le stockage d'une information. DoPost est exécutée. Les paramètres d'appel sont passés dans le flux d'entrée (InputStream)

PUT

Envoie une nouvelle copie d'un objet existant au serveur (beaucoup de serveurs refusent cette méthode)

DELETE

Détruit l'objet de manière irréversible (beaucoup de serveurs refusent cette méthode)

* le terme objet fait référence à un document au sens large (html, script CGI, bytecode java ...)

Dans notre cas, la méthode doGet sera principalement utilisée (Post est plus généralement utilisé pour transférer de grosses quantité de données au serveur. Dans notre cas, peu de données doivent être transmises au serveur GICOM par le client). L'accès à l'URL http://carbone:8080/HelloWorldExample engendrera automatiquement l'appel de la méthode doGet sur le servlet HelloWorldExample. Si ce servlet est chargé pour la première fois dans le serveur Web, alors la méthode init sera appelée avant l'appel de doGet. Depuis un formulaire, il en sera de même :
           <form  method = GET  ACTION=/ShoppingServert/PutProduct?>
                   ...
           <input type='hidden' name ='product' value= 1>           // envoi d'un champ caché avec le formulaire
                <input type='text' name='quantity' value='' size='10'>
                ...
                 </form>
engendre l'appel automatique de la méthode doGet du servlet PutProduct, lorsque le formulaire est validé par le client.
 

Récupération de paramètres

L'interface ServletRequest permet au servlet d'accéder aux paramètres passés par le client, au protocole utilisé et aux noms des machines cliente et serveur. La sous-classe HttpServletRequest permet d'accéder à des informations spécifiques au protocole HTTP comme par exemple les paramètres d'appel ou les cookies (cf. 3.4) présents dans l'entête des requêtes. Par exemple :

Coté client : envoi de la requête : http://carbone:8080/ShoppingServer/MyServlet?product=32456&store="NG+GRENOBLE"
(le caractère + est utilisé pour encoder les espaces dans les arguments).

Coté serveur :
import javax.servlet.*;
import javax.servlet.http.*;
public class MyServlet extends HttpServlet {
 ...
public void init (ServletConfig conf) throws ServletException {
 super.init(conf);
 ...
}

public void doGet(HttpServletRequest req, HttpServletResponse res)
 throws ServletException {
 Enumeration e = req.getParameterNames();
 while (e.hasMoreElements()) {   // récupération des paramètres
  String attribute = (String)e.nextElement();
  if (attribute.equals("product")) {
    try {
     int productRef = Integer.parseInt(req.getParameter("product"));
   } catch (...) ... }
 else if (attribute.equals("store")) {
    try {
     int productRef = Integer.parseInt(req.getParameter("store"));
   } catch (...) ... }
 ...
}

public void doPost(HttpServletRequest req, HttpServletResponse res)
 throws ServletException {
 doGet(req,res);
}

Retour de résultats

L'interface HttpServletResponse fournit au servlet des méthodes permettant de fixer le type MIME du contenu (text/html, text/plain, image/gif, application/postcript, text/vnd.wap.wml ...). Ce contenu est envoyé au client au travers d'un flux ServletOutputStream. Par exemple :

import javax.servlet.*;
import javax.servlet.http.*;
public class MyServlet extends HttpServlet {
 ...
 public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException {
  ...
  ServletOutputStream out = res.getOutputStream();
  res.setContentType("text/html"); // type le contenu du corps de la réponse
 out.println("<HTML><HEAD><TITLE> Caddie content </TITLE></HEAD><body>");
 ...
 out.println("</body>");
 ..
}

Remarques :

3.3 Utilisation des servlets pour le serveur GICOM

L'application serveur est constituée d'un ensemble de servlets. Deux méthodes HTTP permettent de soumettre des informations au serveur : GET et POST. POST n'a pas de limite sur la quantité d'information contenue dans le formulaire en soumission. Par contre, GET permet d'encoder les paramètres dans l'URL. Chaque servlet peut répondre de manière identique aux requêtes de type GET (implémentation de la méthode doGet) et POST (implémentation de la méthode doPost). A titre d'exemple :

De manière plus précise, à partir du document HTML généré par le servlet Welcome (page d'accueil), on peut envisager permettre au client de :

3.4 Gestion des sessions
Le protocole HTTP fonctionne en mode déconnecté (les requêtes sont indépendantes les unes des autres). Il ne gère donc pas de sessions clientes. Or, l'application de commerce électronique suppose d'identifier le client qui effectue une requête. La technique des cookies permet de répondre à nos besoins.

Un servlet peut inclure dans l'entête de sa réponse à une requête HTTP un ensemble d'informations appelé cookie, que le navigateur enregistre de façon persistante. Toutes les requêtes faites par le client en direction de certaines URL inclueront alors ce cookie. Ces URL doivent correspondre en particulier au serveur ayant créé le cookie.

Un cookie possède les attributs suivants :

Le schéma ci-dessous montre le déroulement des opérations.

Dans ce contexte, le servlet Welcome peut donc créer un cookie clientId, contenant une chaîne de caractères identifiant le client.
Par exemple :
import javax.servlet.*;
import javax.servlet.http.*;
public class MyServlet extends HttpServlet {
 ...
 public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException {
 Cookie cookie[];

 if ((cookie = req.getCookies() != null) {
   for (int i = 0; i < cookies.length; i++) {
    if (cookies[i].getName().equals("clientId")) {
      clientId = cookies[i].getValue();
      ...
   } else {
    ...
    Cookie c = new Cookie("clientId", clientId);
   c.setPath("/");
   c.setMaxAge(12*60*60);
   res.addCookie(c);
   ...
 }
 ...
}

4- Gestion des données

4.1  Principes d'implémentation
Les données permanentes (magasins, produits, commandes, etc) seront stockés dans une base relationnelle, et accédés au travers  de l'API JDBC. On propose de définir une interface Java (appelée DataStore par exemple), dans laquelle toutes les fonctions Java de consultation et de modification de cette base sont définies. Cette interface pourra, lors de l'exécution du serveur, être disponible via un objet singleton chargé de gérer les accès à la base. Les accès concurrents sont gérés par la base de données.

4.2 Base proposée
Pour gagner du temps, une base "pré-remplie" est fournie. Cette base peut bien entendu être modifiée ou étendue pour les besoins de l'application.
La base proposée contient les tables suivantes :

Toutes les tables de produits possèdent au moins sept attributs : référence, type, nom, magasin, unité, prix et commentaires. Les attributs restants sont dits complémentaires. La clé primaire de la relation est constituée de la référence et des attributs complémentaires. Par exemple :

Deux magasins sont enregistrés sous les noms de Jardin-de-Provence et Disquaire.

Référence

Nom

Adresse

Ville

Description

Banque

Compte

JAR

Jardin-de-Provence

?

Grenoble

?

BNP

?

DIS

Disquaire

?

Grenoble

?

Société Générale

?

Table Magasins

 

Référence

type

nom

Magasin

unité

prix *

Commentaires

espèce

1

fruit

pomme

JAR

kg

1.0

" ? "

granny

1

fruit

pomme

JAR

kg

1.2

" ? "

golden

2

fruit

cerise

JAR

kg

5.0

" ? "

burlat

3

légume

carotte

JAR

kg

0.5

" ... "

nouvelles

Table PDT_Jardin-de-Provence(référence,type,nom,magasin,unité,commentaires,espèce)

 

Référence

type

nom

Magasin

unité

prix *

Commentaires

titre

support

1

jazz

Coltrane

DIS

nombre

20.0

" ... "

Giant Steps

CD

1

jazz

Coltrane

DIS

nombre

15.0

" ... "

Giant Steps

Vinyle

1

jazz

Coltrane

DIS

nombre

16.0

" ... "

My Favourite things

Vinyle

2

jazz

Hancock

DIS

nombre

15.0

" ... "

Speak like a child

Vinyle

3

baroque

Kenneth Gilbert

DIS

nombre

22.0

" coffret

3 disques "

Préludes de Couperin

CD

4

indies

Pixies

DIS

nombre

18.0

"   "

Bossanova

CD

4

indies

Pixies

DIS

nombre

11.0

"   "

Bossanova

K7

Table PDT_Disquaire(référence,type,nom,magasin,unité,commentaires,titre, support)

Si l'unité est un nombre, cela signifie que le produit se vend à l'unité. Dans chaque table, la référence identifie le type du produit. Pour le magasin Jardin-de-Provence, l'attribut espèce est le seul attribut complémentaire. Le prix est déterminé par le couple (référence, espèce).

4.3 Driver JDBC
JDBC est une API permettant de se connecter à n'importe quelle base de données relationnelle, d'exécuter des requêtes SQL et de lire les résultats.

Pour cela, chaque base de données doit proposer un driver spécifique. On peut trouver l'ensemble des drivers existant sur le site de Java consacré à JDBC (voir les références en annexe).

Le driver JDBC utilisé transforme les appels de méthodes JDBC en requêtes adressées au serveur de la base de données (protocoles propriétaires).

Un driver JDBC implémente trois interfaces principales de l'API :

Connexion et requêtes
Une connexion avec la base est établie par l'appel de la méthode statique getConnection de la classe DriverManager. Les arguments sont :

Par défaut, la connexion valide automatiquement les changements après l'exécution de chaque Statement (mode auto-commit).

Pour gérer les connexions depuis le serveur GICOM, nous avons deux possibilités :

·  établir une connexion par requête

·  gérer un pool de connexion

La première possibilité est plus simple à réaliser que la seconde, mais elle présente l'inconvénient d'alourdir les performances d'accès à la base. Les exemples ci-après illustrent comment se connecter aux bases McKoi et MySql via JDBC, comment exécuter une requête auprès de ces base et comment récupérer le résultat de cette requête. Pour des détails précis sur ces aspects, il est conseillé de regarder la documentation java (package java.sql).

 

Avec McKoi :

   import java.sql.*;

 

   try {  

         Class.forName("com.mckoi.JDBCDriver").newInstance(); // load the driver

   catch (SQLException e) { …}

    String url = "jdbc:mckoi://localhost/";                                        // the URL of the local database

    String username = "admin_user";                                               //username / password to connect under

    String password = "aupass00";

 

    try {                                                                                                  // make a connection with the database

      connect = DriverManager.getConnection(url, username, password);

 

  Statement stm = con.createStatement();                    // create an empty request
  String query = "select * from PDT_CLOTHES";      // initialize request

   ResultSet res = stm.executeQuery(query);                 // execute request

   while (res.next()) { // res contains a sequence of  nuplets, res.next gives the next nuplet
      XXX x = res.getXXX(i);   // i = index of the field or name of the field
      ...                                     // XXX = type of teh field [Byte, Short, Int, String, ...]
                                             // ex: int x = res.getInt(3);
  }
  res.close();
  stm.close();   // free the request (which can now be reused )

 con.close();    // close connexion

    }

    catch (SQLException e) {…}

   … 

Avec MySQL :

import exjava.sql.*;
import exgwe.sql.*;
...
try {
   Class.forName("exgwe.sql.gweMysqlDriver");           // load the driver
   String url = "jdbc:mysql://kernighan.imag.fr:3306/base2";    // the url of the database
  Connection con = DriverManager.getConnection(url, "user2", "user2"); // connexion

  Statement stm = con.createStatement();                    // create an empty request
  String query = "select * from PDT_CLOTHES";      // initialize request

   ResultSet res = stm.executeQuery(query);                 // execute request

  while (res.next()) { // res contains a sequence of  nuplets, res.next gives the next nuplet
      XXX x = res.getXXX(i);   // i = index of the field or name of the field
      ...                                     // XXX = type of teh field [Byte, Short, Int, String, ...]
                                             // ex: int x = res.getInt(3);
  }
  res.close();
  stm.close();   // free the request (which can now be reused )

 con.close();    // close connexion
} catch ...

Remarques :

5. Utilisation des services supports

5.1 Java
On utilisera un JDK version 1.3 ou ultérieure. Vous devez mettre à jour les variables d'environnement nécessaires pour pouvoir utiliser les différents services supports. En particulier :

La documentation générale de Java est accessible à l'URL http://java.sun.com/products/jdk/1.3/docs/api/index.html.

5.2 Servlets (version Jakarta TomCat)

Pour  lancer un serveur Web chargé d'exécuter les servlets, on utilisera TomCat, pour des raisons de simplicité de configuration et d'utilisation, ainsi que de charge des stations d'acceuil. Jakarta TomCat est un container d'exécution de Servlet (Catalina) et un container d'exécution de Java Server Pages ou JSP (Jasper) qui peuvent être déclenchés à partir de Connecteurs. Un des connecteurs est le connecteur HTTP 1.1 pour s'interfacer directement à un client HTTP, un autre le connecteur AJP13 pour s'interface avec un client HTTP via le serveur Apache.

Les classes Java définissant des servlets devront importer les packages suivants :

import javax.servlet.*;
import javax.servlet.http.*;

 

5.2.1 Lancement des serveurs Tomcat sur PC (conseillé)

Des documents d'aide à l'installation de Tomcat sur votre PC (et donnant des exemples de servlets), sont disponible aux URLs :

 

5.2.2 Lancement des serveurs Tomcat sur stations Unix

Tomcat se trouve installé dans le répertoire ${GICOM_ENS}/jakarta-tomcat-3.3. sur la station kernighan. Pour lancer Tomcat, votre environnement doit être configuré comme suit.

setenv TOMCAT_INSTALL ${GICOM_ENS}/jakarta-tomcat-3.3
setenv TOMCAT_HOME ${GICOM}/Java/Tomcat
 

Puis, vous devez taper la commande suivante (après avoir mis à jour votre environnement au travers du fichier CONFIGENV):

Pour stopper le serveur, vous tapez la commande

     (un alias de cette commande (stoptomcat)  est défini dans le fichier de configuration CONFIGENV).

Pour le développement de servlets, votre environnement doit être configuré comme suit.


Si vos servlets utilisent des classes (par exemple, les classes gérant les accès à la base de données) se trouvant sous un répertoire X : setenv CLASSPATH ${CLASSPATH}:X

A partir de cette configuration, vous pourrez accéder au serveur via un browser NetScape Communicator, Mozilla ou MS Internet Explorer, en demandant un accès à une URL de type http://kernighan.imag.fr:808<i>/<nom de service>/servlet/<nom de servlet> si kernighan est la machine sur laquelle tournent vos servlets. Le chemin d'accès aux classes sources ainsi qu'aux classes exécutables de vos servlets est précisé dans le fichier de configuration du serveur (webserver.xml). La contrainte qui doit être respectée est que ces classes doivent être situées dans un répertoire classes, lui-même situé dans un répertoire WEB-INF placé dans le répertoire de nom <nom de service> dans le workdir du serveur.

A titre d'exemple, vous pouvez accéder à l'URL http://kernighan.imag.fr:808<i>/ShoppingServer/servlet/HelloWorldExample, qui exécute le servlet HelloWorldExample qui vous est fourni dans votre répertoire Java/ShoppingServer. Dans votre environnement, vous pouvez aller consulter le répertoire ShoppingServer/WEB-INF/classes qui contient le source de la classe HelloWorldExample.
La configuration des Servlets (nommage, paramêtres d'initialisation, ...) est réalisée dans le fichier web.xml du répertoire WEB-INF.
Pour disposer de documentation supplémentaire, vous pouvez accéder a l'URL http://kernighan.imag.fr:808<i>/examples, ou vous trouverez des exemples de servlets et de JSPs distribués avec Tomcat. Vous remarquerez que la Web application examples est installée dans le répertoire webapps sous la forme d'un fichier .war (Web Archive au format JAR).
La documentation générale sur les servlets se trouve à l'URL http://java.sun.com/products/servlets.  Des informations précises sur les classes fournies sont accessibles à l'URL http://java.sun.com/products/servlet/2.3/javadoc.  

5.3 Base de donnée

5.3.1 McKoi (driver JDBC intégré)

Voir le document http http://sardes.inrialpes.fr/people/boyer/cours/SERVEURWEB/McKoi.htm.

5.3.2 MySQL (URL : www.minet.net/devel/mysql)
Une base MySQL commune se trouve installé sur le serveur kernighan, sous ${GICOM_ENS}/BD/mysql. Toutes les commandes de manipulation de la base données ci-apres sont en fait des alias définis dans le fichier de configuration de votre environnement surle serveur de l'UFR kernighan CONFIGENV.
L'utilisation d'une base MySQL implique qu'un démon, appelé safe_mysqld, soit lancé. Ceci est réalisé par la commande suivante :

mysql/bin/safe_mysqld --log &

Normalement, le démon sera lancé par les enseignants ou par les administrateurs système de l'UFR IMA, sur la machine kernighan. En cas de problème néanmoins, vous pouvez essayer de le relancer vous même (il faut en général lancer la commande deux fois pour arriver à un succès). La configuration du serveur qui est lancé est décrite dans le fichier bin/safe_mysqld (port, répertoire de sauvegarde, etc).

Pour arrêter le démon, il faut taper la commande suivante (normalement, vous n'avez pas à utiliser cette commande):

mysqladmin -u root shutdown


La base est normalement réinitialisée chaque année par les enseignants, au travers des commandes suivantes :

- détruire les bases des années précédentes (rm mysql/data/base*)
- lancer le démon
-Interprêter le fichier bases.sql depuis le répertoire GICOM_ENS/BD/dataStorage:
  mysql/bin/mysql -u root mysql < bases.sql
- Valider la base créee : mysql/bin/mysqladmin -u root reload

La base à été initialisée pour fonctionner avec plusieurs utilisateurs, identifiés par leur nom sous la forme user<i>, i étant l'identification de votre binome. Vous pouvez :


- mysqlshow montre la liste des bases. Une base de nom user<i> a été créée par binome.
- mysqlshow -u<user<i>> -p<user<i>> -h<machine d'execution du démon> <base<i>>  montre la liste des tables contenues dans la base base<i>.
Exemple : mysqlshow -uuser12 -puser12 -hkernighan base12


mysql -u<user<i>> -p<user<i>> -h<machine d'execution du démon>  base<i> < ${GICOM_ENS>/BD/dataStorage/products_new.sql


mysql  -u<user<i>> - p<user<i>> -h<machine d'execution du démon> <base<i>>
Les principales commandes disponibles au niveau de l'interprête sont (vous avez un exemple d'utilisation de ces commandes dans le fichier products_new.sql)

5.4 Driver JDBC EXGWE ( URL : www.gwe.co.uk/java/jdbc )

Un driver JDBC EXGWE se trouve dans le répertoire DESS_GI/BD sur kernighan. Il fournit deux packages principaux à télécharger : exgwe.sql et exjava.sql, que vous devez télécharger et importer dans toute classe utilisant JDBC. L'import de ces packages implique l'import du package java.net.
L'environnement conseillé est le suivant:

Les classes Java utilisant les fonctions JDBC devront importer les packages suivants.

import exjava.sql.*;
import exgwe.sql.*;

 

Documentation
Une documentation sur les drivers jdbc disponibles est donnée à l'URL : java.sun.com/products/jdbc

 

Remarques :

Vous pouvez tester l'accès à la base de données via le serveur Web et JDBC avec les JSP sql.jsp et xsql.jsp déclenchée avec l'URL http://kernighan:8081/jsp_sql

 

Quelques adresses utiles ?

www.amazon.com

www.mercurycyber.com

www.creditmutuel.fr