Tout langage de programmation d'envergure se doit de proposer à ses développeurs des méthodes de connexions à des SGBDR (Système de Gestion de Bases de Données Relationnelles). Java ne déroge bien entendu par à cette règle, et n'oublie pas d'y imprimer sa marque.

Le problème de la connexion à une base de données n'est pas tant le fait du langage utilisée par leur moteur (SQL est devenu un standard de facto), mais celui du très grand nombre de moteurs disponibles sur le marché, qui sont bien entendu totalement incompatibles entre eux (inutile de chercher à accéder à une base MySQL au moyen des méthodes prôné par Oracle).
Chaque éditeur propose donc son propre pilote (driver) pour accéder à sa base, avec son API évidemment optimisée pour cette base seulement.

L'idée de créer une API générale, pouvant se connecter à un grand nombre de bases sans différence côté développeur, a donc vite germé. Microsoft a créé son "standard" sous le nom d'ODBC (Open Data Base Connector). Cette API fonctionne avec Windows et est écrite en C.

Les concepteurs de Java ont créé leur propre architecture : JDBC (Java Data Base Connector). Celle-ci repose sur trois couches : le noyau (JDBC Manager), les classes et interfaces (JDBC API, contenues dans java.sql) et les pilotes (JDBC Drivers). Ces pilotes sont eux-mêmes répartis en quatre types, que nous allons étudier ici.

Type 1 : le pont JDBC-ODBC
Le premier driver créé fut évidemment celui utilisant l'existant. ODBC étant déjà bien répandu et utilisé, un pont JDBC-ODBC (JDBC-ODBC bridge) fut créé. Comme on peut s'y attendre, ce type de driver a l'immense intérêt de pouvoir utiliser directement les fonctionnalités auparavant accessibles uniquement aux langages pour lesquels ODBC a été conçu. C'est d'ailleurs, jusqu'à aujourd'hui, le driver le plus souvent utilisé lors de développement Windows.

C'est malheureusement également sa limite : impossible de faire appel à ce type de driver en dehors des environnements ODBC. Par ailleurs, nous avons ici affaire à une certaine surcharge : une application Java fait appel à un pilote, faisant appel à une surcouche logicielle, qui fait elle-même appelle à une API spécifique au SGBDR utilisé, qui enfin accède au SGBDR. Cela fait beaucoup de couches à "traverser", et les performances peuvent singulièrement en pâtir.

Type 2 : les drivers natifs
Après JDBC-ODBC, l'évolution naturelle était de répliquer ODBC au sein de l'API Java : cela nous donne les drivers natifs, qui sont donc écrits en Java et permettent d'utiliser directement l'API spécifique du SGBDR. C'est déjà un pas en avant dans l'accessibilité aux bases de données, mais cette technique révèle tout de même certaines limitations : les drivers de type 2 ne peuvent être utilisés que dans les environnements disposant d'une API propriétaire (ce qui, selon les moyens de l'éditeur du SGBDR, peut sérieusement limiter les possibilités), et il est impossible de ce servir de ces drivers à partir d'une Applet Java (à cause de la sécurité renforcée pour ce type d'application, limitant ses droits d'accès).

Type 3 : les drivers Pont Réseau
Ce type de driver répond à une demande précise : centraliser les accès en utilisant un serveur d'application intermédiaire pour faire transiter les requêtes vers la base. Le principal intérêt de l'exercice est de ne pas laisser l'application cliente faire les appels à la base de données : le driver se charge de contacter le serveur, qui traduit la requête et l'envoi au SGBDR directement.
C'est probablement la méthode la plus sûre : les applications deviennent totalement portables, la sécurisation se fait directement sur le serveur, les connexions sont gérées selon la demande et donc optimisées, les modifications et reconfigurations se font directement sur le serveur sans devoir modifier les applications clientes…
Léger souci : tous les fournisseurs de serveur d'application ne fournissent pas forcément ce type de drivers sur leur système, ou ne reconnaissent pas tous les SGBDR.

Type 4 : les drivers Java
Les drivers natifs sont certes écrits en Java, mais ils doivent toujours passer par l'API propriétaire de l'éditeur. Le type 4 correspond à ces pilotes qui sont des portages en Java des API propiétaires (généralement écrites en C), et utilisent l'interface java.net pour accéder à la base.
Cependant, les contraintes réseau et sécurité de Java jouent encore : par exemple, si une applet n'est pas reconnue comme étant de confiance (trusted applet), elle ne pourra se connecter qu'à une base qui se trouve sur son serveur d'origine.
Par ailleurs, le problème de l'ouverture se représente : il faut un pilote pour chaque base…

Forum

Réagissez dans les forums de JDN Développeurs

Le type de driver que vous utiliserez dépendra de beaucoup de vos besoins : un type spécifique n'est pas forcément à mettre pour toujours de côté du fait de ses limitations. Face au grand nombre de possibilités, Sun propose aux développeurs un site leur permettant de connaître leurs possibilités face à une problématique d'accès à un SGBDR : JDBC Drivers.