20.16 DataSource
 
Die Arbeit mit dem DriverManager sah bisher so aus, dass wir ihn mit der genauen Datenquelle parametrisiert haben. Wir mussten also immer Name der Datenbank und auch (optional) Benutzername, Passwort angeben. Diese feste Verdrahtung im Quellcode ist allerdings nicht so toll, denn Änderungen führen zu einer zwangsläufigen neuen Übersetzung – was sich allerdings mit Konfigurationsdateien verändern ließe – doch die Daten stehen auf der Client-Seite, wo sie nicht immer gut aufgehoben sind. Besser ist eine zentrale Stelle für die Konfigurationsdaten und auch für die Datenbank. Nehmen wir an, ein Unternehmen entscheidet sich spontan von MySQL auf Firebird um, so müsste ein Client-Programm an allen Stellen, an der der Datenbanktreiber geladen wird, und die URL für die Datenbank aufgebaut wird, Quellcode geändert werden. Das ist unflexibel. So gibt es in Java noch eine andere Möglichkeit, nämlich die Konfigurationsdaten an einer zentralen Stelle zu hinterlegen – und das heißt in Java Zugriff über JNDI. Im zentralen Namensdienst werden Informationen über Treibername, Datenbankname uns so weiter abgelegt und dann zum nötigen Zeitpunkt erfragt. Wenn sich die Datenbank einmal ändern sollte, dann muss nur an dieser zentralen Stelle eine Änderung eingespielt werden und alle, die anschließend den JNDI-Dient erfragen, bekommen die neue Information.
 20.16.1 Die Schnittstelle DataSource
Verbindung zu einem Datengeber (es muss nicht unbedingt eine Datenbank sein) wird über ein DataSource-Objekt realisiert, was von der JDNI-Zentrale zu erfragen ist. Mit getConnection() wird anschließend das Connection-Objekt besorgt, und wir sind an der gleichen Stelle, wo uns auch der DriverManager hinführte.
Context ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup( "jdbc/datenbank" );
Connection con = ds.getConnection( "benutzername", "passwort" );
Das javax.naming.Context-Objekt und dessen Methode lookup() erfragen das mit dem Namen assoziierte Objekt vom Verzeichnisdienst. Vorher muss natürlich irgendjemand dieses Objekt da abgelegt haben – zu neudeutsch deployed haben – doch das schauen wir uns später an. Mit dem Verweis auf das DataSource-Objekt können wir getConnection() aufrufen und Benutzername und Passwort angeben.
interface javax.sql. DataSource
|
|
Connection getConnection(String username, String password)
Versucht unter Angabe des Benutzernamens und Passworts eine Verbindung aufzubauen. |
|
|
Connection getConnection()
Versucht eine Verbindung aufzubauen ohne Angabe von Benutername und Passwort. |
Die DataSource-Triologie
Von der Schnittstelle DataSource gibt es drei unterschiedliche Ausführungen:
| 1. |
Ein Standard-DataSource-Objekt. Mindestens das muss ein JDBC-2.0 kompatibler Treiber anbieten. |
|
|
|
| 2. |
Ein DataSource-Objekt, was gepoolte Datenbankverbindungen zulässt (ConnectionPoolDataSource), so dass eine beendete Verbindung nicht wirklich beendet wird, sondern nur in einen Pool zur Wiederverwendung gelegt wird. Damit er zurückgelegt werden kann, muss die Verbindung einfach nur geschlossen werden – ein Vorgang, der in jedem Programm mit Verbindungen zu finden sein sollte. |
|
|
|
| 3. |
Ein DataSource-Objekt für verteilte Transaktionen (XADataSource). |
|
|
|
Das schöne ist, dass der konkrete Typ verborgen bleibt und das damit leicht eine Umstellung von einer einfachen DataSource auf etwa eine ConnectionPoolDataSource vorgenommen werden kann.
Deployen eines DataSource-Objekts
Der Administrator ist nun verantwortlich dafür, dass das DataSource-Objekt, also die Beschreibung der Datenbank-Parameter, im Namensdienst eingetragen ist. Im Allgemeinen macht das der Container über eine XML-Beschreibungsdatei oder über eine Gui, so dass Programmieraufwand von Hand nicht nötig ist.
Wie die JNDI-DataSource bei Tomcat am Beispiel von MySQL integriert werden kann, zeigt die Webseite http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/jndi-datasource-examples-howto.html. Oftmals existieren für EJB-Server grafische Dienstprogramme, mit denen sich der JNDI-Name für die Ressource setzen lässt. Für den Sun-Standard-EJB-Container ist das etwa das Programm deploytool. Bei Tomcat kann der Namensserver über das admintool administriert werden.
|
