von John Goodson

Komponenten zur Datenbankintegration (manchmal werden sie auch „Data Provider“ oder Datenbanktreiber genannt) schaffen eine Verbindung zwischen einer Applikation und den benötigten Datenquellen. Mit dem Einsatz standardisierter Data-Connectivity-Lösungen wie ODBC oder JDBC können sich Entwickler ganz auf die Umsetzung ihrer spezifischen Anforderungen konzentrieren. Bei diesen standardisierten Ansätzen unterscheidet man drei Kategorien: „Temporary Bridges“, „Dependent Components“ („Dependent“) und „Native Optimized Components“ („Native Optimized“). Stärken und Schwächen der einzelnen Methoden entscheiden über die adäquaten Einsatzgebiete.

Eine Vielzahl von Softwareherstellern, darunter Spezialanbieter und auch nahezu jeder Datenbankanbieter, offerieren Data-Connectivity-Komponenten; manchmal werden diese auch schlicht als Treiber oder Data Provider bezeichnet. Sie erfüllen jedoch immer die gleiche Aufgabe: Entwickler können damit in ihren Applikationen über Plattform- und Systemgrenzen hinweg auf Mainframe- oder Unix-Files, auf PC-Tabellen, relationale oder XML-Datenbanken zugreifen. Programmierer schaffen so die Infrastruktur, die später von den Endanwendern genutzt wird.

Die Lösungen für den Datenzugriff lassen sich in drei Kategorien einteilen:

• Temporary Bridges bieten eine schnelle Lösung zur Verbindung zwischen vorhandenen und neu entstehenden Technologien; ein Beispiel dafür ist eine JDBC-ODBC Bridge.
• Dependent-Data-Connectivity-Treiber nutzen eine Mixtur aus standardmäßig definierten Datenbankschnittstellen sowie hersteller- und plattformspezifischen Schnittstellen.
• Native-Optimized-Data-Connectivity-Komponenten verhalten sich vollständig konform zu exakt definierten Standards; darüber hinaus sind die Treiber im nativen Code einer spezifischen Architektur (etwa reines Java oder C#) implementiert und nutzen daher alle Features und Funktionen der jeweiligen Plattform beziehungsweise Architektur.

Temporary Bridges

Für die Software-Industrie sind Situationen nicht ungewöhnlich, in denen Übergänge von einer vorhandenen, als Industriestandard akzeptierten Technologie zu einer gerade entstehenden erforderlich sind. Die neuen Ansätze bieten eine bessere Performance und zusätzliche Funktionalitäten; über „Hilfskonstruktionen“ können Entwickler bereits ihre ersten Erfahrungen mit der Technologie sammeln. Beispielhaft dafür ist die von Sun verfügbare JDBC-ODBC Bridge (sie wurde ursprünglich von DataDirect Technologies entwickelt) oder der Microsoft ADO .NET-ODBC-Treiber.

Wie der Name bereits sagt, können Temporary Bridges die neuen Technologien nur unvollständig implementieren, denn sie müssen zur gleichen Zeit Rücksicht nehmen auf die bestehenden Vorgaben und deren Restriktionen – sprich: sie müssen rückwärts kompatibel sein.

Die Situation ist vergleichbar mit einem Unternehmen, das Flüssigkeiten in eckigen Röhren transportiert. Ein pfiffiger Ingenieur entdeckt nun, dass Leitungen mit rundem Querschnitt weit effizienter seien. Weit und breit gibt es jedoch keinen Hersteller, bei dem man die benötigten runden Röhren kaufen könnte; bis zur Marktreife vergehen noch einige Monate. Statt wertvolle Zeit verstreichen zu lassen, baut sich der Ingenieur eine Art Kupplungsstück, das die vorhandene Leitung mit einem ganz einfachen runden Rohr verbindet. Damit lassen sich nun eine Reihe von Tests durchführen, um denkbare Szenarien zur erkunden bis die „echte“ Lösung bereit steht.

Für unternehmenskritische Einsätze mit einem hohen Datenvolumen eignet sich diese Hilfskonstruktion allerdings nicht. Auch sollte die Lösung auf keinen Fall als Migrationspfad von der alten zur neuen Technologie missbraucht werden; dem stehen vor allem unzureichende Sicherheitsvorkehrungen entgegen. Sobald die neue Lösung verfügbar ist, empfiehlt sich ein kompletter Umstieg.

Dependent-Data-Connectivity-Treiber

Die nächste Stufe bilden Dependent-Data-Connectivity-Treiber. Sie verbinden Applikationen mit unterschiedlichen Datenquellen, sind aber nicht vollständig für spezifische Architekturen und Programmiermodelle optimiert. Viele Datenbankhersteller bieten eine solche selbst entwickelte oder auch von einem Dritthersteller lizenzierte Lösung, da sie zu deutlich besseren Ergebnissen als eine Temporary Bridge führt.

Analog dazu würde der bereits erwähnte Ingenieur in einem Eisenwarengeschäft größere runde Rohre kaufen und sie mit Dichtungskitt an die kleineren Leitungen anpassen. Dies funktioniert solange nur eine geringe Flüssigkeitsmenge zu transportieren ist, führt jedoch zu möglichen Sicherheitsproblemen (ein Leck), einer eingeschränkten Funktionalität (der Druck kann nicht beliebig erhöht werden) und Volumenbeschränkungen (Friktionen und überflüssige Verbindungen).

Beispiele für Dependent-Data-Connectivity-Treiber sind Microsofts ADO .NET Data Provider für Oracle oder IBMs Connect ODBC- und JDBC-Treiber für DB2. Die Lösung von Microsoft basiert auf so genanntem „Unmanaged Code“, einem Verfahren, von dem Microsoft selbst Anwendern abrät, wenn sie das .NET-Framework verwenden. Weitere Informationen dazu finden sich in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/seccodeguide.asp. Im Vergleich zu „Managed Code“, der vollständig unter der Kontrolle von .NET läuft, bietet die unmanaged Variante darüber hinaus deutlich weniger Performance und Funktionalität. Ähnliche Einschränkungen gelten auch für den IBM-Treiber, der nicht vollständig konform mit den Java-Standards ist. Die Auswirkung: Entwickler verlieren den gesamten Vorteil des Java-Claims „Write Once, Run Anywhere“; wollen sie ihre Anwendung von einem auf ein anderes Betriebssystem portieren, müssen sie umfangreiche Anpassungen vornehmen.

Native-Optimized-Data-Connectivity-Komponenten

Den höchsten Grad an Zuverlässigkeit und die beste Performance bieten die Native-Optimized-Data-Connectivity-Komponenten. Sie verhalten sich vollständig konform zu den Basistechnologien der Architekturen, innerhalb derer sie arbeiten: Ein Native Optimized Data Provider für Microsofts ADO .NET enthält nur Code, der vollständig in der .NET Common Language Runtime (CLR) abläuft. Ebenso ist ein Native-Optimized-JDBC-Treiber zu Hundert Prozent in Java programmiert.

Bei den Native-Optimized-Data-Connectivity-Komponenten unterscheidet man zwei Untergruppen:

• erstens solche, die eine direkte Verbindung zu den Datenquellen herstellen und die lediglich entsprechende Software auf dem Client-Arbeitsplatz benötigen,
• zweitens solche, die aus einer Server-basierten Middleware sowie Client-Komponenten bestehen.

Produkte der ersten Untergruppe kommunizieren direkt über den Wire Protocol-Layer mit Datenbanken. Dadurch lassen sich besonders schnelle, zuverlässige und sichere Verbindungen herstellen. Im Fall von ODBC bedeutet dies, dass keine Client-Librarys wie Oracle Net oder ct-Lib von Sybase installiert werden müssen. Der Wire Protocol ODBC-Treiber für Oracle-Datenbanken von DataDirect verbessert die Performance von Zugriffen auf Oracle-Datenbanken um bis zu 500 Prozent, zudem reduzieren sich die Verwaltungs- und Wartungskosten.

Server-basierte Native-Optimized-Data-Connectivity-Komponenten binden die Datenquellen über einen Intermediate Layer (Connectivity Server) ein. Ein Beispiel dafür bildet die DataDirect SequeLink-Produktlinie. Auf dem Client arbeitet eine Datenbank-unabhängige Software, die vermittelt über die Server-Komponente die benötigten Datenquellen ansteuert. Wichtige Merkmale dieser Lösung sind Funktionen für ein zentrales Management sowie die Überwachung. Stärken bei der Administration und der Kontrolle stehen allerdings Einbußen bei der Performance gegenüber – im Vergleich zu Lösungen, die mit einem direkten Treiber arbeiten. Wo die reine Geschwindigkeit im Vordergrund steht, sollten sich Entwickler in ihren Anwendungen für den direkten Zugang entscheiden.

Auch hier ließe sich die Parallele zu dem bereits erwähnten Ingenieur ziehen, der nun vollständig konforme runde Rohre zur Verfügung hat. Die schnellste Verbindung erhält er, wenn er lediglich einen Punkt A mit einem Punkt B zu verbinden hat. Hier sind die Fließgeschwindigkeit und das Datenvolumen am größten. Ist jedoch eine Verbindung zu mehreren anderen Punkten erforderlich, bietet sich eine zentrale Schaltstelle an, woran einzelne runde Verbindungsstücke angedockt werden können. Nicht anders funktioniert die Wasserversorgung in einer Stadt: Sie kann von einer zentralen Stelle aus ständig überwacht werden und es können bei Auftreten von Problemen die entsprechenden Gegenmaßnahmen eingeleitet werden.