20.16 DataSource
 
Die Arbeit mit dem DriverManager sah bisher so aus, dass wir ihn mit der genauen Datenquelle parametrisierten. Wir mussten also immer den Namen der Datenbank sowie (optional) den Benutzernamen und das Passwort angeben. Diese feste Verdrahtung im Quellcode ist allerdings nicht so toll, weil Änderungen zu einer zwangsläufigen neuen Übersetzung führen – 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 rüstet spontan von MySQL auf Firebird um, so müsste ein Client-Programm an allen Stellen, an der der Datenbanktreiber geladen und die URL für die Datenbank aufgebaut wird, Quellcode geändert werden. Das ist unflexibel. So gibt es in Java eine weitere 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 dort abgelegt – auf Neudeutsch deployed – haben, doch das sehen 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 Benutzername 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, das gepoolte Datenbankverbindungen zulässt (ConnectionPool-DataSource), sodass 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 daran ist, dass der konkrete Typ verborgen bleibt, und mühelos eine Umstellung von einer einfachen DataSource auf etwa eine ConnectionPoolDataSource vorgenommen werden kann.
Deployen eines DataSource-Objekts
Der Administrator ist nun dafür verantwortlich, 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, sodass kein Programmieraufwand von Hand nötig ist.
Wie die JNDI-DataSource bei Tomcat von MySQL integriert werden kann, zeigt die Webseite http://jakarta.apache.org/tomcat/tomcat-5.5-doc/printer/jndi-datasource-examples-how-to.html. Oft 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.
|