Von Johann Baumeister*
Waehrend die Vor- und Nachteile von Client-Server heftig diskutiert werden, arbeiten die Softwareproduzenten bereits an den Programmen. Im folgenden Bericht werden exemplarisch einige Produkte und ihr Zusammenspiel dargestellt. Dass diese das Versprechen von Offenheit nicht nur im Namen fuehren, zeigt ihr Einsatz in der Praxis.
Obwohl die Architektur der Client-Server-Verarbeitung noch nicht eindeutig definiert ist, haben sich mehrere Szenarien als De- facto-Standards etabliert. Dabei wird die Applikation in die Komponenten Praesentation, Verarbeitung und Datenzugriff aufgeteilt. Alternativ existieren weitere Formen mit einer staerkeren Zergliederung. Die Verarbeitungsmodelle unterscheiden sich darin, an welcher Stelle der Schnitt zwischen den Modulen vorgenommen wird.
Vor allem fuer das Betriebssystem Windows sind die Hersteller von Entwicklungswerkzeugen dabei, dem Client-Server-Konzept auf die Beine zu helfen. Fuer jede Kategorie der beteiligten Komponenten (Back-end-Datenbank, Kommunikations-Middleware, Entwicklungswerkzeug, Benutzer-Front-end) gibt es mittlerweile eine Reihe von Produkten.
Als Middleware bietet sich das von Microsoft zusammen mit der SQL Access Group (SAG) geschaffene ODBC (Open Data- base Connectivity) an: ein einheitliches Interface fuer die Kommunikation mit der Datenbank beziehungsweise dem Entwicklungs- oder Front-end- Werkzeug. Der Vorteil liegt darin, dass sich Applikationen unabhaengig von einem speziellen Datenbanksystem entwickeln lassen.
Beim Zugriff und der Manipulation der Daten unterstuetzt die Schnittstelle den Standard Structured Query Language (SQL). Mit ODBC laesst sich auch die Entwicklungs- von der Runtime-Umgebung trennen, was beispielsweise teure Rechnerkosten auf dem Host erspart, wenn die Programmentwicklung auf den PC verlagert wird. ODBC weist derzeit, was umfangreiche Loesungen und die Performance betrifft, durchaus Schwaechen auf. Dennoch ist es fuer den Aufbau von Applikationen leistungsfaehig genug.
Ob sich die Datenbankanbindung durch ODBC langfristig auf dem Markt etablieren wird, ist zumindest bei den Microsoft- Konkurrenten Borland, IBM, Novell und Wordperfect umstritten. Sie planen mit IDAPI (Independent Database Application Programming Interface) ein umfangreicheres Konzept. Es soll ODBC enthalten beziehungsweise darauf aufbauen. Fakt ist allerdings, dass sich IDAPI noch in der Designphase befindet.
In der Zwischenzeit implementieren die Softwarehersteller das ODBC-Interface in ihre Produkte. Ueber vierzig Datenbankproduzenten haben ihre ODBC-Unterstuetzung bekundet. Momentan gibt es Treiber fuer ueber 25 Datenbanken sowie eine Reihe von Schluesselapplikationen. Weitere 30 Anwendungen und 20 Treiber sind in Vorbereitung. Daneben werden Treiber von Drittherstellern angeboten.
ODBC in Treibern nicht einheitlich implementiert
Das ODBC-Pack von Q+E ist die umfangreichste Sammlung dieser Art und bietet derzeit den Zugriff auf ueber 20 Datenbanksysteme: HP Allbase und Turboimage/SQL, Btrieve, Dbase, Excel, Informix, Ingres, MDI Database Gateway (DB2, Teradata), Netware SQL Driver, Oracle, OS/2 DB2/2, Paradox, Progress, SQL Server, SQL Base, Textdateien, XDB und Flat File Driver fuer SQL. Das Unternehmen Openlink Software (vertreten durch Diva in Nuernberg) kuendigte die Freigabe seiner Treiber fuer Oracle, Informix, Ingres, Progress, Unify, SQL Base und den SQL Server an. Die Software soll in den Varianten "Single Tier" und "Multi Tier" verfuegbar sein. Der Single-Tier-Driver benoetigt zusaetzlich die Netzprotokollsoftware (SQL*Net, I-Net etc.) der Datenbankanbieter. Die Multi-Tier- Version ermoeglicht einen Datenbankzugriff auch ohne die spezifische Netzwerksoftware.
Fuer die Desktop-Seite hat Microsoft Treiber fuer den Zugriff auf sieben Datenquellen im Angebot. Allerdings ist die Implementierung des ODBC-Standards in den Treibern verschieden weit vorangeschritten, was voruebergehend zu Unstimmigkeiten beim Einsatz fuehren koennte.
Innerhalb der naechsten Mo- nate wird das zweite Release des ODBC- Software-Development-Kits (SDK) zur Verfuegung stehen. Neben der Unterstuetzung von 32-Bit-Code fuer Windows 3.1 und Windows NT soll damit die Implementierung eines scrollbaren Cursors und die Navigation beim ISAM-Datenzugriff (Index-sequential Access Method) moeglich sein. Damit bleibt Windows auch BS/2000- und AS/400- Datenbestaenden nicht mehr verschlossen. Als Back-end eignen sich alle Datenbanksysteme, fuer die ein ODBC-Treiber existiert. Erfolgreich getestet wurden Vertreter aus dem Midrange, Netz- und PC-Bereich: HP Turboimage mit Allbase- Interface, Gupta SQL Base, Watcom SQL, MS-Access sowie der Zugriff auf Dateien im Dbase- Format.
SQL Base von Gupta ist fuer die Systeme Unix (SunOS), Unixware, Novell Netware, OS/2, Windows NT, Windows und DOS verfuegbar. Durch SQL Network schlaegt Gupta die Bruecke zu weiteren Datenbanken wie beispielsweise DB/2 oder Oracle. Das korrespondierende Entwicklungssystem fuer die Gupta-Datenbank SQL Windows zaehlt zu den besten seiner Art.
HPs Turboimage enthaelt ein hierarchisches Datenbanksystem und kommt auf den Rechnern der Serie HP 3000 unter MPE/iX zum Einsatz. Vom Leistungsumfang her ist es als typisches Midrange-System mit Multiuser-Support einzuordnen. Darauf aufbauend, liefert HP mit Image/SQL eine kompatible Schnittstelle zum Allbase/SQL-Interface.
Watcom SQL ist ein Datenbanksystem nach ANSI SQL89 Level 2 sowie Erweiterungen nach ANSI SQL92 (ANSI = American National Standards Institute). Die Multiuser-Variante des Produkts basiert auf Netbios/IPX unter Novell Netware. Als Host-Sprache bietet sich C mit Embedded SQL an.
Microsoft Access erzielte innerhalb des ersten Jahres einen beachtlichen Erfolg im Desktop-Bereich. Das System zeichnet sich vor allem durch seine komfortable Benutzer-Schnittstelle aus. Die in Kuerze freigegebene Version 2.0 wurde in bezug auf Performance, ODBC-Zugriff und Connectivity-Faehigkeiten verbessert. Die Programmierung erfolgt in dem als Access Basic bezeichneten Dialekt von Visual Basic.
Einen Standard in der PC-Umgebung hat das Dbase-Format geschaffen. Die meisten Entwicklungs- und Anwendungssysteme sind in der Lage, dieses Format zu schreiben oder zu lesen. Folglich ist es als Kommunikations-Schnittstelle oder zum Prototyping praedestiniert.
Die groesste Vielfalt der Produkte mit ODBC-Interface wird aber im Bereich der Front-end-Werkzeuge erwartet. Bekannte Vertreter dieses Genres sind Visual Basic und Visual C++ von Microsoft. Fuer ersteres spricht sein Komfort und die einfache Programmierung. Der Zugriff auf Datenbanken erfolgt direkt durch ein Visual-Basic- Kontrollelement.
Viele Schnittstellen gehen zu Lasten der Performance
Die Programmierung laesst sich mit Multilink/VB von Q+E noch weiter vereinfachen: Das Werkzeug erweitert den Funktionsumfang von Visual Basic um leistungsfaehige Kontrollelemente wie beispielsweise Tabellen oder Auswahlboxen. Zum Erzeugen von performanten Applikationen ist nach wie vor 3GL erforderlich. Im neuesten Release des C++-Entwicklungspakets hat Microsoft dem Rechnung getragen und die ODBC-Anbindung als Klassen realisiert. Aber auch MS-Access laesst sich als Front-end-Werkzeug einsetzen. Das Access-Distribution-Kit ermoeglicht darueber hinaus das Erzeugen von Runtime-Systemen ohne zusaetzliche Lizenzgebuehren.
Wichtig fuer Server-Zugriffe ist folgende Neuerung in Access 2.0: Durch die Generierung eines Unique Index lassen sich die Daten von eingebundenen SQL-Tabellen aendern. Darauf basierend, koennen Updates an der Server-Datenbank durch Access-Formulare durchgefuehrt werden.
Mit 36000 Entwicklerstationen nimmt SQL Windows den ersten Platz im Markt der grafischen Entwicklungsumgebungen fuer SQL-Datenbanken ein. Im zweiten Quartal 1994 wird das Produkt laut Hersteller mit einer ODBC-Schnittstelle ausgestattet sein. Einem Einsatz gegen ODBC-Datenbanken steht dann nichts mehr im Wege. Gleiches gilt fuer Quest, das visuelle Abfrage-Tool aus dem Gupta-Repertoire.
Einen anderen Ansatz der Implementierung des ODBC-Interfaces verfolgt Q+E mit der Database Library. Durch diese Bibliothek ist der Zugriff auf ODBC-Server-Datenbanken auch aus Produkten heraus moeglich, die das Interface nicht unterstuetzen. Statt dessen benoetigt der Client der Library lediglich ein DLL-Interface (Dynamic Link Library), womit sich einer ganzen Reihe von Windows- Programmen das Tor zu SQL-Datenbanken oeffnet.
Impromptu (Cognos) ist ein Werkzeug zum Generieren von Reports und Auswertungen. Durch die Verbindung mit Powerplay (ebenfalls Cognos) lassen sich Management Information Systems aufbauen. Auch Impromptu importiert unter anderem via ODBC seine Reportdaten und schleust sie bei Bedarf zu Powerplay durch.
In verschiedenen Szenarien wurden der Zugriff auf die Datenbank und die Arbeit mit den Werkzeugen evaluiert. Dabei sind die Softwarekomponenten in der Regel beliebig austauschbar. Beispiele hierfuer sind der Zugriff mittels Visual Basic Data Control auf SQL Base oder die Integration eines Impromptu-Reports als OLE-2.0- Objekt in Visual Basic. Die Daten fuer den Report werden online aus Watcom SQL uebernommen. MS Access holt sich ebenso erfolgreich die Daten ueber das Netz von HP-Allbase. Auch parallele Zugriffe in n:n-Relationen (n Datenbanken, n Front-ends) lassen sich durchfuehren. Natuerlich sind dies kuenstlich erzeugte Bedingungen, die so - zumindest derzeit - nicht in der Praxis auftreten. Als Beweis fuer die Machbarkeit sollten sie jedoch genuegen.
Bei der Menge der involvierten Komponenten von unterschiedlichen Herstellern ist das nicht unbedingt selbstverstaendlich. Die vielen Schnittstellen zwischen den Produkten fordern allerdings ihren Laufzeittribut. Fuer hohe Transaktionsraten und schnelle Systemreaktionen sollten dedizierte Produkte eines Herstellers herangezogen werden. Liegt der Schwerpunkt jedoch in der Austauschbarkeit von Produkten und ist weniger zeitkritisch, so stellt ODBC sicherlich eine gute Wahl dar.
Die bei der Arbeit auftretenden Probleme sind eher nebensaechlicher Natur. So gilt es Passworte, Benutzernamen, die Zuordnung der Datenquelle (dsn) im ODBC-Administrator, Zugriffsrechte, Views der Tabellen, PATH- und INI-Inhalte des PCs richtig zu setzen. Dennoch ist die Beschaeftigung mit der Thematik nicht trivial. Schwierigkeiten wird in der Regel eher die Fuelle der involvierten Komponenten bereiten. Daraus resultieren zwangslaeufig die Anforderungen an den Entwicklungsstab: Er muss umfangreiche systemuebergreifende Kenntnisse besitzen, um die richtigen Produkte auszuwaehlen und deren Einsatz zu gewaehrleisten.
Die Client-Server-Verarbeitung bringt eine Reihe von Vorteilen, die kurzfristig positive Auswirkungen haben:
-Durch den transparenten Zugriff auf Host-Datenbanken lassen sich neben der bestehenden Systemumgebung neue Applikationen aufbauen und integrieren. Der Uebergang ist weich und gleitend.
-Durch Cross-Development (Entwicklungsplattform unterscheidet sich von Zielplattform) werden unter anderem Kosten fuer Rechenzeiten und Anschluesse gespart. Ausserdem vereinfacht es die Vergabe von Auftraegen sowohl nach aussen als auch in Nachbarabteilungen.
-Die im PC-Bereich angebotenen Tools sind um ein Vielfaches leistungsfaehiger als die Programmierung in 3GLs wie Cobol oder RPG. Folglich sinken die Entwicklungskosten.
-Die Werkzeuge foerdern die Modularitaet und Dokumentation der Programme. MS-Access ist beispielsweise in der Lage, zu Dokumentationszwecken ein Entity-Relationship-Diagramm zu generieren.
-Mit Windows hat sich ein Standard etabliert, der den Markt bestimmt. Das Risiko, auf das falsche Pferd zu setzen, ist wohl nirgendwo so gering wie in diesem Bereich.
-Schliesslich steigert eine Applikation mit grafischer Benutzeroberflaeche die Effizienz des Endanwenders.
Die Schwachpunkte der PCs und PC-Netze sollen aber nicht verschwiegen werden: Dazu zaehlen neben den Sicherheitsaspekten vor allem Systemwartung und Management. Hier fehlen noch Tools. Aber auch dieses Feld geraet mittlerweile deutlich in Bewegung: Produkte wie SQL Console (Gupta), Global View (Alldata), Hermes (Microsoft), die Transaktions-Verarbeitung durch Tuxedo oder das an RACF angelehnte Sicherheitskonzept von IBM fuer OS/2 sind Vorboten der neuen Produktkategorie.
Die Ansammlung von Softwarekomponenten fuehrt jedoch nicht zwangslaeufig zu sinnvollen Client-Server-Applikationen. Bei allem Komfort und der vordergruendigen Einfachheit der Entwicklungsumgebungen sind dennoch ein durchdachtes Konzept und ein klares Design unerlaesslich. Andernfalls steht zu befuerchten, dass die erzielten Ergebnisse wunderschoene State-of-the-Art- Oberflaechen aufweisen, darunter aber inkonsistent sind und fehlerhafte Datenbestaende generieren.
Die groesste Herausforderung am Client-Server-Computing liegt nicht in seiner technischen Realisierbarkeit, sondern in der intelligenten Umsetzung durch die Entwicklungsabteilungen. Vom Standpunkt der Produk- te und der technischen Mach- barkeit aus gesehen, ist die Zeit reif fuer Client-Server. Und wie heisst es doch: "Wer zu spaet kommt ..."