20.4 Datenbanktreiber für den Zugriff
Damit wir JDBC nutzen können, benötigen wir einen passenden Treiber für die Datenbank. JavaSoft definiert vier Treiber-Kategorien:
| 1. |
JDBC-ODBC-Bridge-Treiber |
|
Da es am Anfang der JDBC-Entwicklung keine Treiber gab, haben sich die Entwickler etwas ausgedacht: Eine JDBC-ODBC-Brücke, die die Aufrufe von JDBC in ODBC-Aufrufe der Client-Seite umwandelt. Die Methoden sind nativ. Im Folgenden werden wir die Brücke einsetzen, wenn wir Access über ODBC ansprechen. |
| 2. |
Native-API Java Driver |
|
Diese Treiber übersetzen die JDBC-Aufrufe direkt in Aufrufe der Datenbank-API. Die Methoden sind ebenfalls nativ. |
| 3. |
Netz-Protokoll All-Java Driver |
|
Hier wird ein in Java programmierter Treiber genutzt, der beim Datenbankzugriff auf den Client geladen wird. Der Treiber kommuniziert nicht direkt mit der Datenbank, sondern mit einer Middleware. |
| 4. |
Native Protocol All-Java Driver |
|
Diese Treiber sind vollständig in Java programmiert und kommunizieren direkt mit dem Datenbankserver. |
Versuchen wir daher, einige Unterscheidungsmerkmale herauszuarbeiten. Ein Kriterium ist, ob sie in Java implementiert sind oder plattformabhängigen Programmcode beinhalten. Die Treiber von Typ 3 und 4 sind vollständig in Java implementiert und daher portabel. Treiber vom Typ 0 oder 1 sind das nicht, da sie zum einen für die JDBC-ODBC-Brücke auf die Plattform-Bibliothek für ODBC zurückgreifen müssen, und zum anderen auf plattformspezifische Zugriffsmöglichkeiten für die Datenbank. Damit ist der Nachteil verbunden, dass Applets mit diesen Treibern nichts anfangen können. Ein Applet erlaubt es nicht, nativen Code von anderen Quellen zu laden und auszuführen. Das ist auch schwierig, wenn etwa ein Macintosh mit Power-PC-Prozessor einen binären Treiber für eine MS-SQL-Datenbank installieren möchte. Die Quintessenz ist: Applets können damit keine Verbindung zu einer externen Datenquelle aufbauen.
Besonders eine Definition der Typ 3-Treiber fällt schwer, da die Definition von Sun nicht unbedingt auf den ersten Blick klar ist. Zum Vergleich beginnen wir mit Typ 4. Diese Treiber sprechen über das datenbankspezifische Protokoll direkt mit der Datenbank über einen offenen IP-Port. Dies ist in einer Direktverbindung die performanteste Lösung. Jedoch ist sie nicht immer möglich. Ein Grund ist, dass manche Datenbanken wie MS-Access, dBase oder Paradox kein Netzwerkprotokoll definieren. Hier erfüllen Typ 3-Treiber eine Vermittlerrolle, denn dieser Treibertyp spricht nicht mit der Datenbank, sondern mit einer Softwareschicht, die zwischen der Anwendung und der Datenbank sitzt: die so genannte Middleware. Sie kann etwa in der Mitte die Anweisungen entgegennehmen und an die Datenbank weiterleiten. Für Applets und Internetdienste hat ein Typ 3-Treiber zudem den Vorteil, dass ihre Klassendateien oft kleiner als Typ 4-Treiber sind, da ein komprimiertes Protokoll eingesetzt werden kann. Über das spezielle Protokoll zur Middleware ist auch eine Verschlüsselung der Verbindung möglich. Kaum eine Datenbank unterstützt verschlüsselte Datenbankverbindungen. Da zudem das Middleware-Protokoll unabhängig von der Datenbank ist, müssen auf der Client-Seite für einen Datenbankzugriff auf mehrere Datenbanken auch nicht mehr alle Treiber installiert werden, sondern im günstigsten Fall nur noch ein Typ 3-Treiber von einem Anbieter. Die Ladezeiten sind damit deutlich geringer.
|
