Der Client-Server-Trend macht auch vor der Transaktionsverarbeitung nicht halt. Fuer die Umsetzung der Mainframe-Anwendungen auf verteilte Techniken gibt es heute zwei konkurrierende Konzepte. Das datenbankbasierte Verfahren orientiert sich am Datenbedarf der Anwender, waehrend die Unix- OLTP-Systeme (Online Transaction Processing) auf Applikationsbasis arbeiten. Wolfgang Haid* nimmt beide Optionen unter die Lupe.

Die IT-Abteilungen stehen unter dem staendigen Druck, Hardwarekosten einzusparen, gestiegene Erwartungen an Benutzeroberflaechen zu erfuellen, die Herstellerabhaengigkeit zu minimieren sowie flexibel und schnell auf sich aendernde Unternehmensstrukturen zu reagieren. Die Einfuehrung von Client- Server-Computing ist eine weithin akzeptierte Strategie, um diesen Anforderungen zu begegnen.

In den meisten Unternehmen haben sich bereits unabhaengig von IT- Strategien Ansaetze von Client-Server-Loesungen etabliert. PCs oder Workstations, die ueber ein Netz verbunden sind, finden in Arbeitsgruppen, Abteilungen oder Filialen hohe Akzeptanz. Solche dezentralen Systeme arbeiten auf netzlokalen Daten, die offline mit den zentralen Unternehmensdaten abgeglichen werden.

Die Grenzen von Client-Server-Loesungen

Derartige Architekturen erfuellen ihren Zweck, solange es darum geht, kleinen Gruppen von Anwendern einen raschen und flexiblen Zugriff auf ihre taeglichen Arbeitsdaten zu ermoeglichen. Mit der wachsenden Benutzerzahl steigen jedoch auch die Anforderungen: Verlangt wird der Online-Zugriff auf zentrale Unternehmensdaten, Interaktion mit anderen dezentralen Systemen, parallele Bearbeitung der Daten innerhalb der Inselnetze. Gleichzeitig soll jedoch die Datenkonsistenz bei hoher Systemverfuegbarkeit gewahrt bleiben.

An dieser Stelle muessen sich die Anwender vom zentralen DV- Management sagen lassen, dass Client-Server-Computing Funktionen unternehmenskritischer Anwendungen wie Transaktionsbetrieb, Ausfallsicherheit, Wiederanlauf und Ressourcen-Management keineswegs automatisch gewaehrleistet.

Client-Server-Architekturen bestehen haeufig aus heterogenen und verteilten Systemen. Enterprise-Computing erfordert daher eine Transaktionsverarbeitung, die eben diese heterogenen und verteilten Ressourcen mit einbezieht.

Unix-Server im Verbund mit PC-Clients werden von den IT-Anwendern zunehmend als die Zielkonfiguration schlechthin angesehen. Gruende dafuer sind:

- hohe Wachstumsraten hinsichtlich Verarbeitungsleistung und Speicherkapazitaet;

- komfortable, ergonomische Benutzeroberflaechen und umfangreiches Software-Angebot der PC-Clients sowie

- moderne, skalierbare Hardware- und Betriebssystem-Architekturen der Server (Stichworte: symmetrisches Multiprocessing, Cluster, MPP).

Realisierungsstrategien fuer transaktionsorientiertes Client- Server-Computing setzen daher bei den OLTP-Systemen fuer den Unix- Bereich an. Zwei Klassen von Produkten stehen im Brennpunkt heutiger Client-Server-Architekturen: relationale Datenbank- Management-Systeme (RDBMS) und Transaktionsmonitore (TP-Monitore).

Client-Server-Computing auf der Basis einer RDBMS-Umgebung allein ist ein Weg. Datenbankhersteller wie Informix, Oracle und Sybase schaffen die Basis fuer entsprechende Loesungen.

Dazu gehoeren Productivity-Tools wie "Painter" fuer grafische Praesentations-Interfaces oder 4GL-Tools, Connectivity-Produkte zur Anbindung heterogener Netz- und Datenbankwelten machen den Einstieg attraktiv.

Zweite Realisierungsmoeglichkeit ist Client-Server-Computing auf der Basis eines Unix-TP-Monitors. UTM (Unix) von Siemens-Nixdorf, Tuxedo von Novell und CICS/6000 beziehungsweise Encina von IBM sowie Transarc sind hier bekannte Produkte.

Die beiden Alternativen unterscheiden sich nicht nur durch die eingesetzte Technik, sie fuehren auch zu unterschiedlichen Software- und Verarbeitungsstrukturen:

- zu datenzentrierten Architekturen bei der Verwendung von RDBMS und

- zu applikationszentrierten Architekturen beim Einsatz von TP- Monitoren.

Dennoch muessen sich beide Konzepte nicht ausschliessen: Unix-TP- Monitore in Verbindung mit Datenbanken koennen Clients, Kundenapplikationen und Datenhaltung in einem einheitlichen Client-Server-Verarbeitungsrahmen zusammenfassen.

Grundsaetzlich gilt aber, dass zwischen der Struktur der IT-Loesung und der Unternehmensstruktur und -groesse eine enge Abhaengigkeit besteht, die der Anwender bei der Wahl seines Realisierungswegs beachten sollte.

Bei der Verwendung von RDBMS greifen Client-Applikationen, die vielfach auf PCs laufen, ueber Remote Data Access

(RDA) auf die Datenbank zu, indem sie SQL-Aufrufe an den Server abschicken, die dort bearbeitet und beantwortet werden. Der Server stellt den Clients Datenhaltungs- und Zugriffsfunktionalitaet zur Verfuegung. Diese Vorgehensweise wird als "datenzentriert" bezeichnet (vgl. Abbildung 1).

Komplexere datenzentrierte Architekturen entstehen, wenn Clients auf mehrere verteilte Server zugreifen. Das wird durch verteilte RDBMS oder durch den Einsatz von Connectivity- und Gateway- Produkten ermoeglicht. Ein aktuelles Beispiel sind die Produkte, die im Umfeld der ODBC-Spezifikation (Open Database Connectivity) von Microsoft entstanden sind. Diese machen es dem Windows-PC moeglich, parallel auf unterschiedliche RDBMS-Server zuzugreifen.

Die meisten einschlaegigen Tool-Hersteller arbeiten derzeit an Schnittstellen zu ODBC. RDBMS-Anbieter und unabhaengige Softwarefirmen entwickeln Connectivity-Programme, die die Microsoft-Schnittstelle auf die verschiedenen Datenbanken abbildet. Fuer den Anwender eroeffnen sich dadurch Moeglichkeiten, offene Client-Server-Systeme zusammenzustellen, die auf Client- Seite Productivity-Tools seiner Wahl bieten und auf Server-Seite Zugriff auf verschiedene RDBMS unterstuetzen.

Den Vorteilen, die der Einsatz moderner Datenbanktechnologie und hochproduktiver Tools mit sich bringt, sind jedoch klare Grenzen gesetzt, die aus der "Datenzentriertheit" resultieren:

- Die Kommunikation zwischen Client und Datenbank-Server findet auf SQL-Ebene statt. Diese Vorgehensweise hat hohe Netzbelastungen und gegenueber lokaler Verarbeitung verlaengerte Antwortzeiten zur Folge.

- Die Applikationslogik in den Clients setzt direkt auf den Datenbankstrukturen (Tabellen, Feldern) auf. Strukturinformationen ueber die Datenbank werden zwangslaeufig aus dem Server exportiert. Bei Aenderungen am Schema der Server-Datenbank sind daher meist alle Clients betroffen.

Diesen Einschraenkungen begegnen die aktuellen Versionen einiger Datenbanken mit der Moeglichkeit, "Stored Procedures" zu definieren: Programmteile, die im RDBMS, also auf dem Server, gehalten und ausgefuehrt werden. Sie fassen Teile der Applikationslogik und Datenoperationen auf dem Server zusammen und reduzieren damit Kommunikation und Abhaengigkeit zwischen Client und Server. Auf diese Weise ermoeglichen sie die funktionale Verkapselung von Anwendungen in wiederverwendbare Verarbeitungseinheiten. Das ist zweifellos sinnvoll, hat jedoch seine Tuecken:

- Stored Procedures werden in proprietaeren Sprachen geschrieben.

- Fehlende Debugging-Moeglichkeiten erschweren Test und Fehlersuche.

- Datenbankfremde Ressourcen (etwa Betriebssystem- und Kommunikationsfunktionen) lassen sich aus Stored Procedures heraus nicht ansprechen.

Trigger- und Constraint-Mechanismen, die von einigen Systemen unterstuetzt werden, sind weitere Moeglichkeiten, die Applikationslogik direkt im Datenbank-Server zu verarbeiten. Aber auch sie gehoeren zu den Spezifika des jeweiligen RDBMS-Produkts und muessen, da sie direkt mit sensiblen Datenbestaenden operieren, sehr sorgfaeltig definiert, validiert und dokumentiert werden.

Netzkommunikation und Datenmodellierung sind Punkte, die Anwender in jedem Fall vor der Entscheidung fuer eine datenzentrierte Loesung kritisch beleuchten muessen. So sollte Transaktionsverarbeitung ueberwiegend lokal stattfinden. Bei Online-Interaktionen von Clients mit entfernten Servern muessen Netzinteraktionen und Datenmengen, die dafuer auf SQL-Ebene erforderlich sind, beachtet werden.

Die Datenbankschemata am Server und die Client-Applikationen beziehen sich aufeinander. Daher ist eine praezise Datenmodellierung, die zu stabilen Anwendungsdatenmodellen und Schemata fuehrt, eine wesentliche Voraussetzung.

Client-Systeme sollten einfach organisiert sein. Die IT-relevanten Geschaeftsdaten sind dazu in den Datenbankschemata moeglichst in der Form zu verankern, wie sie dem Endbenutzer zur Bearbeitung praesentiert werden.

Die Beschraenkung der Anzahl paralleler Benutzer und die Ausfallsicherheit der Datenbank-Server sind inzwischen geloeste Probleme. Dispatching- und Threading-Mechanismen in den RDBMS, parallele Server und Spiegelplattentechnik schaffen einen hohen Durchsatz auf leistungsfaehiger Unix-Hardware bei einer gleichzeitig hohen Nutzbarkeit durch redundante Betriebsmittel.

Auf diese Weise sind die Daten selbst bei einem Ausfall eines kompletten Server-Rechners ueber den Partner-Knotenrechner weiter im Zugriff. Allerdings reduziert sich die je Anwendung verfuegbare Rechnerleistung.

Client-Server-Computing auf der Basis eines Unix-TP-Monitors stellt die Applikationen in den Mittelpunkt der Architektur. Die Serviceleistung des Servers fuer die Clients ist in diesem Fall die Ausfuehrung von Applikationsfunktionen, die Geschaeftsteilprozesse realisieren.

Diese Services werden von den "Applikationskernen" erbracht. Das sind Programme, die auf dem Server unter der Kontrolle des Unix- TP-Monitors transaktionsgesichert ablaufen. Sie verkapseln Anwendungslogik und Datenzugriffe, enthalten jedoch keine Praesentationslogik, die bei den klassischen TP-Applikationen auf dem Mainframe 40 bis 80 Prozent des Codes ausmachen.

Als Datenhaltungssysteme werden auch bei dieser Architektur in der Regel relationale Datenbanksysteme eingesetzt, die sich meist zusammen mit den Applikationen auf den Servern befinden. Die Anwendungen greifen lokal, ohne Performance-Verluste durch Netzkommunikation auf die Daten zu. Der TP-Monitor uebernimmt bei der Interaktion zwischen Applikation und RDBMS die Transaktionssteuerung.

Die Clients beschraenken sich auf die Benutzerinteraktion und die Ablaufsteuerung; Praesentation, Applikationslogik und Daten- Management sind somit klar getrennt.

Diese in der Abbildung 2 dargestellte Software-Architektur besitzt folgende Vorteile:

- Die Datenbankstrukturen bleiben hinter den Applikationskernen verborgen (Data Hiding); damit wird eine voellige Unabhaengigkeit der Clients von der Datenmodellierung erreicht.

- Die Applikationskerne koennen interagieren. So laesst sich der aufgerufene Kern ueber Kommunikationsmechanismen des TP-Monitors als Service in Anspruch nehmen.

- Die Gliederung der Anwendungen in wiederverwendbare Komponenten ist moeglich. Standard-Verarbeitungsschritte werden auf Applikationskerne abgebildet und von weiteren Anwendungen durch Aufrufe von Servicefunktionen genutzt.

- Die Kommunikation zwischen Client und Server findet auf Applikations- nicht auf Datenzugriffsebene statt; daraus resultiert eine erhebliche Reduktion der Interaktionen, der uebertragenen Datenmengen und der Response-Zeiten.

- Die Anwendungen sind nicht ueber alle Clients verstreut, sondern auf Server-Seite zentralisiert. Dadurch wird ihre Wartung und Administration wesentlich vereinfacht.

Aus den gennanten Punkten ergibt sich, dass die applikationszentrierte Architektur durchaus fuer komplexe und verteilte Client-Server-Loesungen tauglich ist. Der TP-Monitor mit seinen funktionalen Staerken bei Ressourcen-Management, Transaktionsverarbeitung und Netzeinbindung laesst dem Anwender ausreichende Freiheit fuer die Realisierung von "Large-scale"- Loesungen.

So werden Systemressourcen wie Prozesse und Hauptspeicher mit hoher Effizienz genutzt. Dispatching-Strategien und die Replikation haeufig benoetigter Applikationskerne sorgen fuer eine optimale Lastverteilung auch auf Multiprozessorhardware. Auf diese Weise kann eine hohe Anzahl von Clientsystemen parallel bedient werden.

Ausserdem sorgt die Auftragsverwaltung im TP-Monitor bei einer grossen Zahl von Usern fuer eine erhebliche Reduktion der parallel in den Datenbanksystemen offenen Transaktionen. Im Netz verteilte Server sind zudem in der Lage, zu kooperieren und sich gegenseitig Services unter TA-Sicherung zur Verfuegung zu stellen. Ein weiterer Vorteil in umfangreichen Umgebungen ist, dass sich heterogene Datenbanksysteme unter einheitlicher und uebergreifender Transaktionssteuerung in die Verarbeitung einbinden lassen. Aehnliches gilt fuer die Eigenschaften unterschiedlicher Netze und Protokolle, von denen die Anwendungen dank TP-Monitor nichts zu wissen brauchen.

Weitere transaktionsorientierte Mechanismen wie Print-Queues, Message-Queues oder Benutzer-Login ermoeglichen eine umfassende transaktionsgesicherte Anwendungsverarbeitung.

Applikationszentrierte Client-Server-Architektur bedeutet also, dass die unternehmenskritische DV auf Server-Seite konzentriert wird. Dort sorgt ein TP-Monitor fuer Konsistenz und Sicherheit der Unternehmensdaten sowie fuer Durchsatz, Verfuegbarkeit und Verteilung der Leistung. Der TP-Monitor stellt der Client-Seite die Applikationsservices zur Verfuegung. Aus Desktop-Anwendungen und Workgroup-Netzen werden die Dienste aufgerufen und fuer die Enduser nutzbar gemacht.

Die Umstellung von "monolithischen" Anwendungen auf Client-Server- Computing erfordert erhebliche Investitionen sowie ein Redesign der Software in beiden Architekturen. Derartige Umstrukturierungen erstrecken sich daher besonders in groesseren Unternehmen ueber einen laengeren Zeitraum. Um einen "sanften" Uebergang zu Client-Server- Strukturen mit dem Schutz bisheriger Investitionen und einer Minderung der Risiken ohne Beeintraechtigung des Produktivbetriebs zu gewaehrleisten, ist die Ankoppelung der Mainframe-Systeme waehrend dieser Umstellung unumgaenglich. Das gilt um so mehr fuer Anwender, die den Grossrechner weiterverwenden wollen.

Kein Mangel an Middleware

Sowohl fuer Unix-Datenbanken als auch fuer Unix-TP-Monitore sind Connectivity-Produkte verfuegbar. In RDBMS-Umgebungen wird der Link zur Mainframe-Welt durch Gateway-Produkte realisiert, die Remote- SQL-Schnittstellen von Mainframe-DBMS in Unix oder auf PC bieten. Ein Beispiel ist das "Informix-Gateway with DRDA", das Zugriff auf die IBM-DB-Welt ueber das Informix-API erlaubt. Auch die "Oracle Open Gateway Technology" bindet eine ganze Palette von Mainframe- DB-Systemen in die Oracle-Plattform ein. Die Kommunikation zwischen den Datenbanksystemen findet allerdings generell auf Datenzugriffsebene statt.

Das ist bei TP-Monitor-basierten Client-Server-Loesungen anders. Sie bieten Mainframe-Connectivity auf Applikationsebene. Die Kommunikation mit dem Mainframe-TP-System erfolgt vorwiegend ueber die IBM-Protokolle LU6.1, LU6.2 oder ueber OSI-TP. Unter Verwendung dieser Protokolle sind unterschiedliche Arten gekoppelter Verarbeitung moeglich. Die wesentlichen sind:

- verteilte Transaktionsverarbeitung zwischen Client-Server- und Mainframe-Anwendungen;

- transaktionsgesicherte asynchrone Verarbeitung durch Transfer von Verarbeitungsauftraegen zum und vom Mainframe unter Steuerung von Reliable Message-Queues und

- kooperative Verarbeitung durch Applikationen. Das heisst, die Applikationsprogramme kommunizieren zwar systemuebergreifend miteinander, nutzen jedoch keine anwendungsuebergreifende Transaktionssicherung.

Der Anwender muss bei seiner Entscheidung fuer ein OLTP-Basisprodukt die Mainframe-Einbindung als wichtiges Kriterium im Auge behalten und pruefen, ob die mit dem Produkt realisierbare Interoperabilitaet seinen Anforderungen an Interaktionsraten, Datenvolumen und Transaktionssicherheit standhaelt.

OLTP-Standards fuer Multivendor-Loesungen

Basissoftware fuer den Client-Server-Bereich muss den Einsatz von Soft- und Hardwarekomponenten unterschiedlicher Anbieter unterstuetzen: Offene, standardkonforme Schnittstellen, Unabhaengigkeit von Hardwareplattformen und Interoperabilitaet mit Produkten anderer Anbieter sind gefordert.

Unix-OLTP-Produkte genuegen diesen Forderungen bereits in einem hohen Masse:

- Plattformunabhaengigkeit und SQL als einheitliche Zugriffssprache gelten bei Unix-RDBMS bereits als Selbstverstaendlichkeit.

- Plug and play von Client-Tools mit RDBMS und Interoperabilitaet unterschiedlicher RDBMS im Rahmen von Client-Server-Architekturen entwikkeln sich derzeit rapide im Umfeld der Schnittstellen- Standards ODBC, IDAPI und DBA.

- TP-Monitore mit Marktbedeutung sind auf unterschiedlichen Hardwareplattformen verfuegbar. Ein gleichzeitiger Einsatz von Servern verschiedener Hersteller unter einer einheitlichen TP- Monitor-Plattform ist problemlos moeglich.

- Zunehmend werden von den TP-Monitoren standardkonforme APIs und Protokolle angeboten. Vor allem die X/Open-Schnittstellen XATMI, CPIC und TxRPC sowie das ISO-Protokoll OSI-TP sind wichtig fuer eine erhoehte Portabilitaet und Interoperabilitaet der Applikationen.

- Die XA-Schnittstelle von X/Open standardisiert die Interaktion von TP-Monitoren und RDBMS und gibt dem Kunden die freie Wahl bei der Produktentscheidung. Die XA-Schnittstelle wird schon heute von den meisten Produkten unterstuetzt.

* Wolfgang Haid ist Mitarbeiter der Product Division Network and Database Systems bei der Siemens-Nixdorf Informationssysteme AG in Muenchen.