1.) Zweischichtiges Modell (englisch two-tier model)
Im zweischichtigen Modell unterhält sich ein Java-Applet oder eine Anwendung direkt mit der Datenbank. Dies erfordert einen JDBC-Treiber, der mit dem DBMS kommunizieren kann. Hierbei werden die Datenbankanfragen (SQL-Anweisungen) direkt an die Datenbank gesendet und andersherum das Ergebnis der Anfrage direkt an den Benutzer zurückgesendet. (Client/Server-Konfiguration, wenn die Datenbank auf einer anderen Maschine ist und dann über ein Netzwerk (Intranet) mit dem Benutzer verbunden ist. Dann ist die Maschine mit der Datenbank der Server und die Maschine des Benutzer der Client)
Abbildung zweischichtiges Modell :
Dreischichtiges Modell (englisch three-tier model)
In diesem Modell werden die Befehle an eine mittlere Schicht mit Diensten geleitet, die an die Datenbank SQL-Anweisungen sendet. Die Datenbank sendet die Ergebnisse an die mittlere Schicht zurück, die diese dann an den Benutzer weiterleitet. Ein Vorteil dieses Modells ist die Möglichkeit, die mittlere Schicht für die Kontrolle über die Zugriffe als auch über die Art von Updates auf die Datenbank zu verwenden. Außerdem bietet die dreischichtige Architektur in vielen Fällen Performanzvorteile. Zur Zeit in die mittlere Schicht typischerweise in C oder C++ programmiert worden, allerdings ist mit der Einführung bessere Compiler die Implementierung der mittleren Schicht in Java möglich. Dies ist ein großes Plus wegen der Java Vorteile wie Robustheit, Multithreading und Sicherheitsmerkmale, die jetzt genutzt werden können.
Abbildung dreischichtiges Modell :
Es gibt vier Arten von Treibern :
Treiberkategorie
komplett in Java ?
Netzprotokoll
1-JDBC-ODBC-Brücke
nein
direkt
2-natives API als Basis
nein
direkt
3-JDBC-Netz
ja
erfordert Konnektor
4-natives Protokoll als Basis
ja
direkt
Wie die Treiber der einzelnen Treibertypen arbeiten, wird jetzt erklärt :
Typ 1 : JDBC-ODBC-Brücke plus ODBC-Treiber
Bei diesem JavaSoft-Brückenprodukt erfolgt der JDBC-Zugriff über einen ODBC-Treiber. Hierbei ist zu beachten, daß der ODBC-Binärcode und in vielen Fällen der Datenbankcode der Clients auf jeder Client-Maschine geladen werden muß. Diese Art von Treiber ist am besten für Unternehmensnetze geeignet, wo Client-Installationen kein großes Problem darstellen oder für Servercode von Anwendungen, die in einer dreischichtigen Architektur geschrieben sind.
Typ 2 : Natives API und teilweise in Java geschriebene Treiber
Hier wandelt der Treiber JDBC-Aufrufe in Aufrufe solcher Clients-API für die verschiedenen DBMS (z.B.: Oracle, Sybase, Informix usw.) um. Hier ist zu beachten, daß auch hier der Binärcode auf jeder Client-Maschine geladen werden muß.
Typ 3 : JDBC-Netz mit in purem Java geschriebenem Treiber
Der Treiber wandelt den JDBC-Aufruf in ein DBMS unabhängiges Netzprotokoll, welches durch einen Server in DBMS-Protokoll übersetzt wird, um. Dieser Netzserver-Middleware ist es möglich, pure Java-Clients mit vielen verschiedenen Datenbanken zu verbinden. Dies ist im allgemeinen die flexibelste Lösung. Die Hersteller werden für diese Lösung Produkte anbieten, die sich zur Nutzung im Intranet und Internet eignen, wobei im Internet die zusätzlichen Anforderungen wie Sicherheit usw. erfüllt werden müssen.
Typ 4 : Natives Protokoll mit in purem Java geschriebenen Treiber
Die JDBC-Aufrufe werden direkt in das vom DBMS verwendete Netzwerkprotokoll
umgewandelt. Dadurch ist ein direkter Aufruf des DBMS-Servers von der Client-Maschine
möglich und es stellt eine excellente Lösung für den Intranetzugriff
dar. Da viele dieser Protokolle herstellerabhängig sind, werden die
Hersteller selbst die primäre Quelle sein.
c.) Anforderungen an JDBC-Treiber
SQL-Konformität
SQL ist die Standardsprache für Zugriffe auf Datenbanken. Es ist allerdings momentan so, daß SQL nicht so ein Standard ist, wie es wünschenswert wäre. Es gibt zum Beispiel Schwierigkeiten bei Datentypen, die von verschiedenen DBMS verwendet werden, doch leider bei diesen unterschiedlich sind. Dies wird allerdings von Java durch eine Menge generischer SQL-Typbezeichner, die in der Klasse java.sql.Types stehen, abgefangen. Weitere Probleme liegen darin, daß zwar die DBMS für ihre Grundfunktionalität eine Standardform von SQL benutzen, doch bei weitergehenden Funktionen (stored procedures, outer joins) sich nicht an Syntax und Semantik des kürzlich definierten SQL-Standard halten. Das sich der Anteil von Standard SQL ausweitet, wäre wünschenswert.
JDBC-compliant
Diese Bezeichnung wurde geschaffen, um ein Standardniveau von JDBC-Funktionalität
zu setzen, auf welches sich der Benutzer verlassen kann. Damit ein Treiber
sich JDBC-compliant nennen kann, muß er mindestens den ANSI SQL-2
Entry Level unterstützen. Um dies zu festzustellen, kann man die mit
dem JDBC-API verfügbare Testsuite nutzen. Die Bezeichnung JDBC-compliant
gibt also an, daß der Konformitätstest bestanden wurde. Diese
Tests sind natürlich nicht erschöpfend, allerdings geben diese
Tests ein gewissen Grad an Vertrauen in eine JDBC-Implementation. Durch
die immer größere Akzeptanz wird JDBC schnell der Standard für
Datenbankzugriffe in Java.
Last Updated on $Date: 1998/11/02 20:21:23 $