Burgy Zapp
08-05-04, 17:39
[]NEWSartikel für Gäste im Orginal jetzt lesen (http://www.newsolutions.de/news400/artikel/biblio/dataint.php)
Artikel Auszug
Datenbankintegration: Methoden und Einsatzgebiete
von John Goodson
Über den AutorJohn Goodson ist Vice President Product Operations bei DataDirect TechnologiesTabellenAlle Tabellen zu diesem Artikel befinden sich in dieser (http://www.newsolutions.de/news400/artikel/biblio/dataint/tabellen.htm) HTML Datei.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 (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.
...
Kommentare und Diskuse sind willkommen.
(discuss away ...)
Artikel Auszug
Datenbankintegration: Methoden und Einsatzgebiete
von John Goodson
Über den AutorJohn Goodson ist Vice President Product Operations bei DataDirect TechnologiesTabellenAlle Tabellen zu diesem Artikel befinden sich in dieser (http://www.newsolutions.de/news400/artikel/biblio/dataint/tabellen.htm) HTML Datei.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 (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.
...
Kommentare und Diskuse sind willkommen.
(discuss away ...)