Java et l'accès aux bases de données.


Par Xavier Leclercq


Si Java est en théorie indépendant d'une plate-forme, ce ne sera pas forcément le cas d'une base de données. Et un pilote que vous pouvez commander à partir de Java pour accéder à ces données ne sont pas toujours non plus indépendant... Cet article vous présente JDBC, une solution complète, non sans contraintes, d'accès à une base de données en Java.

Origine et raison d'être de JDBC

Les mécanismes de sécurité de Java empêchent l'accès complet et direct à des données locales (pour une applet, le stockage local est interdit). Au début de l'histoire de Java cet obstacle a posé un problème. Java de part sa nature distribuée et sa grande portabilité était naturellement destiné au développement orienté bases de données. Mais paradoxalement, seules des solutions propriétaires étaient capables d'entrer en liaison avec la base de données d'un éditeur spécifique.

Cette situation n'étant pas tenable, les concepteurs de Java ont du trouver une solution (à partir du JDK 1.02). Ils ont publiés leur propre interface API qui a été baptisée JDBC, ce qui signifie Java DataBase Connectivity.

Il existe deux niveaux à cette interface. Le premier niveau, le JDBC API, consiste à permettre à une application, ou à une applet, d'établir un lien avec une base de données, et à l'interroger ou la mettre à jour via des requêtes SQL traditionnelles.

Le deuxième niveau, le JDBC Driver API, est destiné principalement aux éditeurs des bases de données. C'est ici que les développeurs de pilotes programment une interface JDBC spécifique à leur base de données.

Les drivers JDBC ne sont pas aussi nombreux que ceux proposés par ODBC (Open Database Connectivity) de Microsoft. En fait il existe de nombreux points communs entre ces deux normes. D'abord, les concepteurs de JDBC se sont basés sur les mêmes spécifications qu'ODBC : X/OPEN SQL Call Level Interface. Ensuite, de nombreux pilotes JDBC passent en réalité la main à un pilote ODBC. Historiquement, le premier pilote JDBC a d’ailleurs été la passerelle JDBC-ODBC développée par JavaSoft...

Alors pourquoi avoir développé JDBC ? Premièrement, pour ne pas dépendre d'une solution propriétaire non Java. L'API ODBC de base est écrite pour le C et non pour le Java. Deuxièmement, un pilote ODBC doit d'abord être installé pour qu'une application puisse l'employer. Tandis qu'un pilote JDBC "natif pur" peut être chargé et exécuté "over the network". Autrement dit, l'applet et le pilote peuvent être exécutés à partir d'une machine virtuelle sans l'intervention d'un utilisateur pour configurer ou installer un logiciel tiers spécifique.

Pour votre information, Sun a développé un produit du nom de "JavaBlend" pour faciliter la vie du programmeur JDBC. Mais JavaBlend n'est pas livré avec le JDK. Ajoutons que de nombreuses autres solutions existent comme OQL qui est supporté par l'Object Database Management Group...

Différents pilotes

La passerelle JDBC-ODBC a été baptisée par les concepteurs de JavaSoft, "Pont JDBC/ODBC" de type 1. Il existe en effet, quatre types différents de pilotes. Voyons un peu les avantages et les inconvénients de ceux-ci.

- Le type 1:

Il s'agit de la colle JDBC-ODBC. Comme nous l’avons expliqué précédemment, il existe des pilotes ODBC pour la plupart des bases de données mais il est nécessaire d'installer un pilote ODBC sur chaque machine cliente. Que ce driver de type 1 soit disponible gratuitement ne change pas grand chose à cette dépendance. Par contre, il est très utilisé au sein d'un réseau local, mais ne peut être employé via un navigateur ou l'Appletviewer. Cette solution n'est pas indépendante de la plate-forme.

- Le type 2

Le cheminement d'un requête SQL au travers d'une liaison JDBC-ODBC est multiple. Il y a d'abord une traduction JDBC vers ODBC, puis ODBC attaque le driver spécifique à la base de données. Avec le type2, JDBC interroge directement le pilote spécifique à la base de données. Les performances sont donc meilleures mais le prix à payer est le même : il est nécessaire d'installer le driver spécifique sur toutes les machines (et évidemment cela ne fonctionne pas d'avantage avec un navigateur ou l'AppletViewer). Cette solution reste, tout comme le type 1, dépendante de la plate-forme.

- Le type 3 et le type 4

Le pilote est ici du java pur en code natif. Cela "tourne" avec une machine virtuelle à l'aide d'un navigateur par exemple. Le type 3 nécessite un logiciel middleware installé sur un serveur distant pour pouvoir servir "de colle" entre ce serveur distant et la base de données qui se situe sur un autre serveur distant, quelque part sur le réseau. Le type 4 ne nécessite pas de middleware intermédiaire : le serveur contacté est celui sur lequel tourne la base de données.

Le problème avec les types 3 et 4 sont de deux ordres : premièrement la lourdeur pour charger le code java, deuxièmement, les pilotes ne sont pas disponibles pour toutes les bases de données...

Vous pouvez obtenir la liste des pilotes (selon un type déterminé) à l’adresse http://industry.java.sun.com/products/jdbc/drivers (121 pilotes sont actuellement disponibles).

 

Un exemple concret

Nous supposons que vous avez à votre disposition un environnement de développement Java. Vous avez besoin du pilote ODBC spécifique à votre base de données car nous allons employer la colle "JDBC-ODBC".

import java.net.URL;
import java.sql.*;
class simpleselect {
public static void main {String args[]} {
try {
class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");
connection con = DriverManager.getConnection ("jdbc:odbc:mon-dsn","utilisateur","mot-de-passe");
VerifieConnection (con.getWarnings ());
Statement smt = con.createStatement ();
ResultSet rs = smt.executeQuery ("SELECT * FROM VotreTable);
AfficheResultats (rs);
rs.close
smt.close();
...

Remarque : Le code des routines VerifieConnection() et AfficheResultats() sont disponibles avec l'exemple JDBC-ODBC livré par SUN. Ils ne figurent pas ici pour que le schéma de base vous apparaisse comme le plus simple possible.

Explications

Une base de données est désignée par une URL sous la forme <protocole>://<nom_hote>[:<port>/<chemin>/<nom_fichier>

Une connection se présente sous la forme d'un canal de communications réseau TCP entre Java et la base de données. C'est le DriverManager qui crée et gère les connections. Il crée les connections TCP, gère la liste des pilotes chargés et mappe les URLs vers des connexions. La connexion est générée à partir des données URL décrivant le protocole et le service.

La connexion étant établie (et validée via VerifieConnection), pour pouvoir envoyer des requêtes SQL vous devez créer une instance de Statement sur laquelle vous allez appliquer une des méthodes executeQuery ou encore executeUpdate. Vous pouvez comprendre Statement par "requête" et "ResultSet" par "Résultats".

Les résultats sont retournés dans une instance de la classe ResultSet. Chaque jeux de données est constituée d'une série de lignes. En appliquant la méthode "next", il est possible de lire (.getstring) le jeux de données complet et de l'afficher.

while (resultat.next()) {
...

Note : Il existe deux versions pour la méthode get : resultat.getInt et resultat.getString.

La requête peut se présenter sous diverses formes. Via Statement, il s'agit d'une requête simple, qui est directement compréhensible par les pilotes. Via PreparedStatement, vous pouvez préparer une requête en vue de plusieurs exécutions (gain de temps, car il y a déjà eu une pré-interprétation). Enfin il existe aussi la possibilité d'exécuter des procédures stockées via CallableStatement (une procédure stockée est une procédure créée en langage natif de la base de données et qui est exécutée par le SGBD).

Conclusion

Il reste de nombreux points à explorer, comme les gestions des erreurs, les métadonnées (cataloguant la base de données elle-même) et les jeux de résultats multiples. Néanmoins, si vous avez assimilé convenablement cet article, vous avez maintenant le bagage suffisant pour aller de l'avant.