|
|
Die Anbindung einer Anwendung an eine Datenbank kann auf unterschiedliche Art und Weise realisiert werden. Zwei Architekturen werden am häufigsten eingesetzt und dementsprechend im Rahmen dieses Buches kurz vorgestellt: Das Zwei-Schichten-Modell und das Drei-Schichten-Modell. Die Auswahl einer dieser Alternativen ist hierbei von der jeweiligen Anwendung abhängig. Weiterhin ist die Art des zur Verfügung stehenden Datenbanktreibers bei der Auswahlentscheidung maßgeblich. Dieses wird später noch genauer behandelt. Zwei-Schichten Modell Im Zwei-Schichten-Modell (Two Tier Model) erstellt ein Java-Applet oder eine Applikation direkt eine Verbindung zur Datenbank. Dazu wird ein JDBC-Treiber benötigt, der die Kommunikation mit dem DBMS gewährleistet. Dieser wird zuerst von der Applikation geladen und ist dann für den Datenaustausch mit der Datenbank verantwortlich. Die Funktionalität des Treibers steht anschließend der Applikation zur Verfügung. Ein JDBC-Treiber (siehe dieses Kapitel) muss weiterhin über eine Netzwerkfähigkeit verfügen, damit eine entfernte Datenquelle im Netz angesprochen werden kann. Diese Architektur, die im Wesentlichen der klassischen Client-Server-Architektur entspricht, ist in Abb. 10-2 dargestellt. Der Client lädt hierbei ein Java-Applet, das über ein DBMS-spezifisches Protokoll an die Datenbank angebunden wird, vom Server. Die Datenbank befindet sich hierbei auf der gleichen Maschine wie der Web-Server. Zu dieser Architektur ist Folgendes anzumerken:
Abb. 10.2: Darstellung des Zwei-Schichten-Modells Drei-Schichten-Modell Die Architektur des Drei-Schichten-Modells (Three Tier Model) beinhaltet zusätzlich eine Applikation, deren Funktion der von Komponentenadaptern (siehe Beans-Komponentenadapter in Kapitel 9.2) ähnelt. Die Applikation fungiert hierbei als Datenbank-Server für den Client und als Client für den Datenbank-Server. Die Applikation nimmt die Client-Anfragen entgegen und sendet SQL-Anweisungen zum Datenbank-Server, der dann die Ergebnisse der Anfrage an die Applikation zurückgibt und diese anschließend an den Client weiterleitet.
Abb. 10.3: Darstellung des Drei-Schichten-Modells Die Applikation erhält hierbei SQL-Anfragen über eine Socket- oder RMI-Verbindung und leitet die Anfrage dann an einen lokalen JDBC-Treiber weiter, der mit der Datenbank kommuniziert. Somit kann eine entfernte Datenquelle angesprochen werden, ohne dass der Treiber über eine Netzwerkfähigkeit verfügen muss. Weiterhin ist durch die Applikation, die als mittlere Schicht fungiert, eine gewisse Kontrolle von Datenbankzugriffen gegeben. Die mittlere Schicht stellt eine Reihe von Datenbankoperationen zur Verfügung, die in Form eines komfortablen APIs genutzt werden können. Wie Abb. 10-3 zu entnehmen ist, ist eine Anwendung, die aus drei Schichten besteht, dadurch gekennzeichnet, dass das System aus drei Komponenten besteht. Die erste Komponente ermöglicht eine einheitliche Datensicht (bspw. als Applet), der zweite Teil (mittlere Schicht) besteht aus einem universellen Server (z. B. HTTP, RMI oder CORBA) und der dritte Baustein wird durch das DBMS realisiert. JDBC und ODBC Die Open Database Connectivity (ODBC) ist ein weit verbreitetes und akzeptiertes Application Programming Interface (API) zum Zugriff auf relationale Datenbanken (RDBMS). Die Erstellung von Anwendungen, die ODBC nutzen, ist an keine bestimmte Programmiersprache gebunden. Die einzelnen Funktionen des ODBC-Interfaces werden von den Herstellern von DBMS in Form spezifischer Treiber bereitgestellt. Die jeweilige Anwendung ruft hierbei Treiberfunktionen unabhängig von der verwendeten Datenbank auf. Die Kommunikation zwischen Anwendungsprogramm und Datenbanktreiber wird durch einen Treiber-Manager geregelt. Das ODBC-API wurde von der Firma Microsoft in der Programmiersprache C entwickelt. Da in Java allerdings das Zeigerkonzept nicht verwendet wird, stellt das ODBC-API keine geeignete Schnittstelle zwischen Java und Datenbanken dar. Es ist zwar möglich, C-Aufrufe in Java zu integrieren (siehe hierzu das in Kapitel 3.5 beschriebene Java Native Interface), mit der Verwendung von JNI sind aber immer auch Einschränkungen der Sicherheit, der Robustheit und der Portabilität der entwickelten Programme verbunden. ODBC kann aber dennoch mit Hilfe des JDBC verwendet werden. Standardmäßig ist im JDBC-Paket eine JDBC-ODBC-Brücke vorhanden, ein spezieller Treiber, mit dem eine Abbildung von Java-Anfragen auf ODBC realisiert werden kann. Sowohl ODBC als auch JDBC verwenden die Structured Query Language (SQL) als Sprache für den Datenbankzugriff. JDBC-Treibertypen Die eigentliche Funktionalität der JDBC liegt im vorhandenen JDBC-Treiber. Ein JDBC-Treiber wird dabei über den JDBC-Treiber-Manager verwaltet. Der Manager beinhaltet Implementierungen der in Kapitel 10.3 erläuterten Interfaces. Kernstück ist hierbei das Interface java.sql.Driver, das für die eigentliche Datenbankfunktionalität verantwortlich ist. Dieses Interface greift bspw. auf die Interfaces java.sql.Connection, java.sql.Statement und java.sql.ResultSet zurück. Hiermit wird somit eine Verbindung mit einer Datenbank aufgebaut (Connection), eine SQL-Anfrage formuliert (Statement) und die Ergebnisse (ResultSet) zurückgegeben. Im SQL-Package ist ein JDBC-Treiber integriert, der eine Verbindung zum ODBC darstellt. Java-SQL-Aufrufe werden hierbei in ODBC-API-Aufrufe umgewandelt. Voraussetzung ist allerdings, dass ein ODBC-Treiber lokal installiert ist. Andere Treiber werden von den DBMS-Herstellern vertrieben oder mit Web-Servern ausgeliefert. JDBC-Treiber lassen sich in vier verschiedene Treiberkategorien oder Treibertypen unterteilen (Typ-1, Typ-2, Typ-3 und Typ-4). Die Typen 1 und 2 stellen keine Netzwerkfähigkeiten zur Verfügung. Im Gegensatz dazu verwenden die Typen 3 und 4 ein Netzwerkprotokoll, mit dem entfernte Datenbanken angesprochen werden können. Die Architektur des jeweiligen Treibertyps wird im Folgenden erläutert. |
 |
|||||||||
|
|
|
Tab. 10.3: JDBC-Treiberkategorien Treiber Typ-1 Typ-1 ist eine JDBC-ODBC-Bridge zuzüglich eines ODBC-Treibers. Bei diesem Treibertyp wird für den Datenbankzugriff ein ODBC-Treiber, der in native Code implementiert ist (z. B. herstellerabhängiger, in C-geschriebener Treiber), verwendet, der lokal beim Client installiert werden muss und über die JDBC-ODBC-Bridge der Firma Sun angesteuert wird. Mittels dieses Treibertyps können lediglich lokale Datenquellen angesprochen werden. Zum Zugriff auf entfernte Daten muss auf die Drei-Schichten-Architektur zurückgegriffen werden. Wie in Abb. 10-4 dargestellt ist, bindet eine Java-Applikation bzw. ein Applet den Treiber der JDBC-ODBC-Bridge über den JDBC-Treiber-Manager ein. Der Treiber kommuniziert über eine in native Code implementierte Schnittstellen (z. B. Windows-DLL) mit dem ODBC-Treiber-Manager und dementsprechend mit dem lokal installierten ODBC-Treiber. Er ist für die Datenbankanbindung zuständig.
Abb. 10.4: Treiber vom Typ-1 in JDBC Treiber Typ-2 Der Treiber vom Typ-2 wird auch als native API Partly Java Driver bezeichnet. Hierbei werden JDBC-Aufrufe des Clients in die entsprechenden Datenbank-API-Aufrufe umgesetzt, wodurch auf Client-Seite entsprechende APIs zur Verfügung stehen müssen. Dies impliziert, dass der Treiber lokal beim Client installiert werden muss, was in der Regel durch vorab geladene Treiber sichergestellt wird. Hier wird der in native Code implementierte ODBC-Treiber durch einen in native Code implementierten herstellerabhängigen Treiber (z. B. Informix-, DB2- oder Oracle-Treiber) ersetzt. Die Java-Applikation bzw. ein Applet binden über den JDBC-Treiber-Manager einen in Java geschriebenen JDBC-Treiber ein, der über in native Code implementierte Schnittstellen (z. B. Windows DLLs) die Anbindung der Datenbank herstellt. Dieser Vorgang ist in Abb. 10-5 dargestellt.
Abb. 10.5: Treiber vom Typ-2 in JDBC Treiber Typ-3 Der Treiber vom Typ-3 wird auch als JDBC Net Pure Java Driver bezeichnet. Anfragen werden in ein datenbankunabhängiges Netzwerkprotokoll übersetzt, das vom Server in die entsprechenden Datenbankprotokolle transformiert wird. Dieser Ansatz bietet den Vorteil, dass beim Client keinerlei Installationen notwendig sind, da der universelle Treiber vom Server geladen werden kann und der tatsächlich notwendige Treiber auf dem Server ausgeführt wird. Hierbei müssen entsprechende Werkzeuge des Datenbankherstellers existieren, um die notwendige Konvertierung vornehmen zu können. Wie in Abb. 10-6 dargestellt ist, bindet die Java-Applikation (bzw. ein Applet) einen universellen Java-JDBC-Treiber über den JDBC-Treiber-Manager ein, der die Aufrufe in ein DBMS-unabhängiges Protokoll (bspw. HTTP, CORBA oder RMI) übersetzt. Anschließend werden die Aufrufe an eine auf dem Server installierte Middleware-Applikation (bspw. in CORBA oder DCOM realisiert) gesendet. Diese wandelt die Aufrufe entsprechend wieder in datenbankspezifische Aufrufe um und realisiert damit die Datenbankanbindung.
Abb. 10.6: Treiber vom Typ-3 in JDBC Treiber Typ-4 Der Treiber vom Typ-4 wird auch als Native Protocol Pure Java Driver bezeichnet. Bei diesem Treibertyp werden Treiber verwendet, die ausschließlich in Java programmiert sind. Dementsprechend entfällt die Einbindung von native Code. Dieser Treibertyp muss vom Datenbankhersteller entwickelt werden, wodurch zusätzliche Kosten entstehen. Er wird aber als portabelste und effektivste Lösung betrachtet, da durch die fehlende Einbindung von native Code einerseits die Plattformunabhängigkeit von Java unterstützt und andererseits das Herunterladen der Treiber vom Web-Server auf den Client ermöglicht wird. Wie in Abb. 10-7 dargestellt ist, bindet die Java-Applikation (bzw. das Applet) einen DBMS-spezifischen Java-Treiber über den JDBC-Treiber-Manager ein, der nun auf direktem Weg die Datenbankanbindung herstellt.
Abb. 10.7: Treiber vom Typ-4 in JDBC Nachdem alle JDBC-Treibertypen kurz erläutert wurden, sollte ersichtlich sein, dass die Treibertypen 3 und 4 eher zu empfehlen sind als die Typen 1 und 2, da durch die Netzwerkprotokolle, auf die die Treiber aufsetzen, ein Datenbankzugriff durch ein Applet über das Internet möglich wird. Diese Treibertypen weisen allerdings gegenüber dem Treibertyp 1 das Defizit auf, dass sie nicht für alle Datenbanken erhältlich sind. Der Treibertyp 1 ist der am einfachsten zu realisierende Treiber, da Java die JDBC-ODBC-Bridge direkt anbietet. Tab. 10-4 listet die wichtigsten Datenbanken mit den entsprechenden JDBC-Treiber-Typen auf (ab JDBC in der Version 2.0). |
|
|
|
Tab. 10.4: Datenbanken mit entsprechenden Treibertypen |
|
|
