Database Connectivity
JDBC

Schon lange vor der Entwicklung von Java haben die RDBMS die Welt der Datenbanken beherrscht. Um die angepasste Client-Entwicklung durchführbar zu machen, veröffentlichten die Anbieter verschiedene proprietäre Schemen. Am häufigsten offerierte ein RDBMS-Anbieter eine Client-Komponente, die einen gewissen Grad der Programmierbarkeit besaß (mittels der herstellereigenen Version einer Computerspra­che, die häufig als die nächste Fourth Generation Language 4GL vorgestellt wurde). Mit der Zeit, nach­dem sich der Rummel um 4GL gelegt hatte, erkannten Entwickler und Anwender gleichermaßen die pro­prietäre, anbieterspezifische Natur dieser 4GL-Schemen und verlangten freieren Zugang zu den Datenbanken. In den Anfangstagen erschienen diese »verbesserten Zugangsmechanismen« als C- oder (später) C++-Schnittstellen zur Datenbank. Doch noch immer sind häufig »Super-Code-Generatoren«, Compiler-Plug-ins und/oder proprietäre Bibliotheken der Anbieter erforderlich, damit dies alles funktioniert.

Während dieser Entwicklung veränderte sich die Architektur im Hinblick darauf, wie eine SQL-Anwei­sung vom Client zum Server übermittelt wird und wie die Ergebnisgruppe vom Server zurück zum Client wandert. Dadurch, dass all die konkurrierenden Anbieter um denselben Kundenstamm wetteiferten, sind viele mögliche architektonische Varianten ausprobiert worden.

Als schließlich die "offenen" Schemen wie JDBC und ein naher Verwandter von Win32 namens ODBC (Open Database Connectivity von Microsoft) aufkamen, stellen die Datenbankanbieter fest, dass die Tage ihrer proprietären 4GL und Entwicklungsumgebungen vorbei waren. Viele RDBMS-Anbieter tendierten aus geschäftlichen Gründen für einen langsamen Wechsel zum freien Zugang, anstattJDBC/ODBC sofort zu übernehmen. In der Zwischenzeit bastelten die JDBC- und ODBC-Handwerker an der serverseitigen Programmiertechnologie eines jeden Anbieters herum, um ihre Treiber zu implementieren. Die verschie­denen Treiberarten sind ein vollkommenes Zeugnis für die Art, wie die verschiedenen Anbieter ihre Cli­ent-Kommunikations-Architektur ausgewählt haben und was die Implementeure der JDBC-Treiber getan haben, um diese unterzubringen.

 

Die flexibelste und am meisten wünschenswerte Architektur für die flüssige Arbeit mit Java ist Typ 4. Erst unlängst haben Typ-4-Treiber angefangen, viele der größeren Datenbanken zu berücksichtigen. RDBMS beginnt, die neuen, offenen und miteinander verbundenen Technologien im großen Stil zu verwenden -viele entwickeln ihre eigenen optimierten JDBC-Treiber, um die Fähigkeiten ihrer RDBMS-Engines zu demonstrieren.

Die bewegte Geschichte und Entwicklung der Technologie für den freien Datenbankzugang hat zu einer Unzahl von Treiberarchitekturen geführt:

□      Typ-1-Treiber.

Mit diesem Treiber wurde JDBC eingeführt. Als JDBC aufkam, waren schon viele ODBC-Treiber erhältlich.

Anstatt auf einen vollständigen Design-/Entwicklungszyklus für stabile JDBC-Treiber zu warten, übernahm die Java-Gemeinde, das »Brückenkonzept« , das ihnen ermög­lichte, die Fülle der schon existierenden ODBC-Treiber zu verwenden. Auch heute noch sind im Lieferumfang von J2EE und J2EE JDK die JDBC-ODBC-Typ 1-Treiber enthalten. Typ-1-Treiber sind per defmitionem keine lOO°/oigen Java-Elemente. Ein 100%iger Java-Treiber erhöht nicht nur die Performance (kein Übergang aus dem Java-VM notwendig), sondern gestattet auch einer deterministischen Anwendung ein Tuning, das mit nicht 100%igen Java-Implementierungen schwierig ist.

 

□       Typ-2-Treiber.

Diese Treiber sind Fassade auf den bestehenden nativen Code-Treibern der Datenbankanbieter. Es sind »schnelle und einfache« Implementierungen. Typ-2-Treiber erlauben einem RDBMS-Anbieter, einen JDBC-Treiber zur Verfügung zu stellen, der das anbietereigene optimierte Datenzugangsprotokoll in kürzester Zeit verwendet (eingebettet in ihre bestehenden nativen Code-Treiber), ohne mit irgendwelchen Einschränkungen klarkommen zu müssen, die vom ODBC-Bridging auferlegt werden. Typ-2-Treiber sind kein reines Java.

 

□       Typ-3-Treiber.

Diese Treiber sind nicht wirklich Treiber: Sie bilden Frontends für Datenbank-Zugangsserver und Konzentratoren. Manche sagen, diese Lösungen seien reinrassiges Java. Das, was zum Client heruntergeladen wird, ist definitiv 100% Java - aber es ist kein JDBC-Treiber im engeren Sinn, sondern eher ein Proxy. Der Proxy-Treiber »spricht« mit dem Konzentrator/Zugangsserver der mittleren Schicht. Der Konzentrator/Zugangsserver verwendet im Gegenzug das ODBC- oder anbieter- spezifische Protokoll, um mit der Datenbank zu kommunizieren. Die Anforderungen an den zusam­menarbeitenden mittelschichtigen Server haben diese Lösungen ziemlich schwerfällig (und oft sehr teuer) gemacht.

 

□   Typ-4-Treiber.

 

Diese Treiber sind echtes, 100% reines Java, echte JDBC-Treiber. Der ganze Mechanis­mus des Zugangs zum Client ist komplett in Java codiert. Es gibt keine Aufrufe aus dem oder in das VM seitens des nativen Codes, und es besteht kein Bedarf an kostspieligen Servern auf der mittleren Schicht. Einige Implementierungen kommunizieren direkt mit dem RDBMS über das »native« Netz­werkprotokoll, das vom RDBMS unterstützt wird. Es war ein langer und steiniger Weg, aber die Typ-4-Treiber sind schließlich für beinahe alle größeren RDBMS-Anbieter erhältlich. Die Tage des mitter­nächtlichen Nachbauens sind vorbei.

Wie JSP und JDBC zusammenpassen

Das "klassische" JDBC-Entwicklungsszenario wird in der Abbildung unten dargestellt. JSP kann diesem Szenario ohne weiteres gerecht werden, obwohl das Schema keinen Nutzen aus der von JSP angebotenen Flexibilität zieht.

 

[Home] [Stuff] [Fotogalerie] [IT] [OCI_Treiber] [JDBC] [JSP] [LDAP] [SOAP] [Diplomarbeit] [JAVA] [Profile] [Contact] [MyDomains]