Als ausgereift gilt das seit den Anfaengen der DV angewandte Prinzip

der Transaktionsverarbeitung. Mit dem Client-Server-Computing setzt sich nun jedoch eine Technik durch, die den Einsatz von OLTP-Produkten

(Online Transaction Processing) grundsaetzlich in Frage stellt.

Von Georg Hermann*

Transaktionsverarbeitung ist eines der klassischen Felder der grossrechnerbasierten Informationsverarbeitung. Entsprechend ausgereift sind inzwischen die dafuer entwickelten Transaktionssysteme. Mit Ausnahme des Einsatzes relationaler Datenbanken ergaben sich bei den klassischen Transaktionssystemen in den letzten zehn Jahren jedoch keine dramatischen Veraenderungen mehr. Das Wissen und die Erfahrung beim Umgang mit diesen Transaktionssystemen ist ueber viele Jahre gewachsen und heute bei Hunderttausenden von Software-Entwicklern vorhanden.

Doch die Revolution hat bereits begonnen - in Form von Client- Server-Systemen. Ploetzlich tun sich neue Moeglichkeiten auch fuer die Transaktionsverarbeitung auf, und vormals vorhandene und akzeptierte Grenzen werden in Frage gestellt. Bisherige transaktionsverarbeitende Systeme stossen heute in zwei Bereichen an ihre Grenzen:

Alphanumerische Benutzer-Schnittstellen werden den Anforderungen komplexer Transaktionen nicht mehr gerecht. Die bisherige Beschraenkung auf typischerweise 80 mal 25 Zeichen je Bildschirm laesst nur die Darstellung einer begrenzten Informationsmenge zu. Grafische Schnittstellen mit hochaufloesenden Bildschirmen koennen ein Mehrfaches darstellen und gleichzeitig schnell und flexibel zu weiteren Fenstern verzweigen. Klassische Systeme sind bei Maskenwechseln langsam, weswegen diese moeglichst vermieden werden. Dieses fuehrt zu ueberfuellten Bildschirmmasken und relativ unflexiblen Systemen.

Heutige Geschaeftsprozesse benoetigen eine Integration der Verarbeitung von strukturierten und unstrukturierten Daten, das heisst von Transaktions- und Textverarbeitung. Dies ist heute nur auf PCs und Workstations sinnvoll moeglich und wird durch Dienste wie Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE) und der Common Object Request Broker Architecture (Corba) unterstuetzt.

Transaktionen auch unter Windows

Voraussetzung dafuer ist aber, dass auch die Transaktionssysteme als vollwertige Anwendungen unter den grafischen Umgebungen wie MS- Windows und OSF/Motif laufen - nicht nur in einer Terminalemulation.

Schon aus diesen wenigen Beispielen ist ersichtlich, dass Client- Server-Umgebungen auch fuer die Transaktionsverarbeitung Vorteile bringen. Es stellt sich jedoch die Frage nach der Rolle von TP- Monitoren im Client-Server-Umfeld. Dazu ist zuerst der Begriff Transaktionsverarbeitung eindeutig zu definieren: Als Transaktionen bezeichnet man die Verarbeitung von formalen Geschaeftsvorfaellen auf Computersystemen. Dabei werden die sogenannten ACID-Eigenschaften festgelegt:

- Atomacy: Alle Schritte einer Transaktion werden entweder vollstaendig oder gar nicht durchgefuehrt. Das vermeidet inkonsistente Daten.

- Concurrency: Mehrere Benutzer koennen gleichzeitig mit derselben Datenbasis arbeiten. Der Transaktionsmonitor oder das Datenbank- Management-System (DBMS) muessen durch geeignete Vorkehrungen einen gleichzeitigen Betrieb gewaehrleisten.

- Isolation: Keine der momentan in Verarbeitung befindlichen Transaktionen darf durch andere beeinflusst werden. Das verhindert die durch das Concurrency-Verfahren eventuell auftretende Dateninkonsistenz.

- Duration: Einmal verarbeitete Transaktionen muessen dauerhaft erhalten bleiben, das heisst, sie duerfen nicht durch Ereignisse wie Systemabstuerze verlorengehen. Das setzt entsprechende Wiederanlauf- und Recovery-Verfahren voraus.

Nicht unter den Begriff der Transaktionsverarbeitung fallen rein lesende Datenbankabfragen sowie entsprechende Zugriffe auf Dokumente. Die Verwaltung von Dokumenten in Dokumenten-Management- Systemen laeuft sinnvollerweise jedoch ebenfalls unter Transaktionskontrolle.

Auf Grossrechnersystemen werden zur Transaktionsverarbeitung fast ausschliesslich entsprechende Monitore wie IBMs CICS eingesetzt. Auf Unix-Systemen und anderen Minicomputern wurden sie meist ohne ein derartiges System realisiert. Dass das moeglich ist, hat zu Glaubenskriegen ueber Sinn und Zweck von Transaktionsmonitoren gefuehrt. Beide Moeglichkeiten haben jedoch ihre Berechtigung (siehe nebenstehende Abbildung).

Auf Grossrechnern mit Batch-orientierten Betriebssystemen wurde die Funktionalitaet fuer den Online-Betrieb in die Transaktionsmonitore integriert. Die Hauptfunktionen dabei sind das Terminal- sowie Datastream-Handling, das Transaction-Scheduling und das Sicherstellen der Transaktionsintegritaet.

Weitere Funktionen betreffen das Leistungsverhalten bei grossen Benutzerzahlen und Sicherheitsaspekte.

In Unix-Umgebungen beispielsweise werden das Terminal-Datastream- Handling und Scheduling der Anwendungsprozesse von den Betriebssystemen uebernommen, waehrend ein DBMS die Sicherung der Transaktionsintegritaet uebernimmt. Bei hohen Benutzerzahlen ist hier jedoch die Leistung durch fehlende Serialisierung der Transaktionen und die grosse Zahl von Anwendungsprozessen (einer pro Benutzer) eingeschraenkt. Durch die Verwendung von Datenbankprozeduren, die allerdings proprietaer sind, koennen die DB-Systeme dieses zu einem guten Teil wieder ausgleichen, indem sie auf Transaktionsebene serialisieren und die Vielzahl der Benutzer ueber wenige zentrale Datenbankprozesse bedienen.

Es ist somit ersichtlich, dass sich auf beiden Arten von Systemen zuverlaessige und leistungsfaehige transaktionsverarbeitende Anwendungen erstellen liessen. Der Schritt zu Client-Server- Systemen bringt jetzt aber neue Anforderungen, so dass zusaetzliche Betrachtungen notwendig werden. Dabei sind die wichtigsten Faktoren fuer gute Client/Server-Implementierungen zunaechst unabhaengig vom Einsatz eines Transaktionsmonitors.

Bisherige Host-basierende Anwendungen hatten eine monolithische Struktur. Auf Client-Server-Systemen ist mindestens eine Zweiteilung erforderlich, naemlich ein Client-Teil und ein Server- Teil. Durch das zwischengeschaltete Netzwerk sind zusaetzliche Ueberlegungen zum Erzielen eines guten Leistungsverhaltens auch hier noetig. Es zeigt sich, dass die Bandbreite der LANs bei einer vernuenftigen Netzstruktur durchaus ausreicht, da Transaktionen typischerweise nur Daten von einigen Kilobyte Groesse uebertragen. Das laesst oft auch den Einsatz von WANs zu.

Bedeutender ist die Frage, wie haeufig Client und Server miteinander kommunizieren. Dabei stellt sich in der Regel nicht das Netzwerk, sondern der Server als Flaschenhals heraus. Jeder Aufruf eines Clients an einen Server erzeugt einen Interrupt, der bearbeitet werden muss. Zu haeufige Kommunikation zwischen Clients und Servern fuehren daher zwangslaeufig zu inakzeptablen Antwortzeiten. Steigt dann noch die Anzahl der Benutzer, dann wird jeder noch so grosse Server frueher oder spaeter die Grenze beim Transaktionsdurchsatz erreichen. Wie haeufig darf also kommuniziert werden? Die Antwort liegt in der geeigneten Aufteilung der Anwendung zwischen Client und Server. Betrachtet man die Kommunikation zwischen den verschiedenen Schichten eines gesamten Transaktionssystems, und zwar Applikations- und Systemkomponenten, dann ergibt sich eine Haeufigkeitsverteilung, wie sie in der Abbildung auf Seite 51 dargestellt ist.

Bei klassischen Block-Mode-Anwendungen wird ungefaehr einmal pro Transaktion kommuniziert. Deshalb lassen sich die Systeme leicht entsprechend der Benutzerzahl dimensionieren.

Character-Mode-Anwendungen dagegen erzeugen einen Host-Interrupt bei jedem Tastendruck jedes einzelnen Benutzers. Dadurch erreichen selbst die groessten Rechner ihre Auslastung bei wenigen hundert Benutzern. Fairerweise muss hier gesagt werden, dass Benutzer- Schnittstellen mit Character Mode eine hoehere Funktionalitaet haben und eine bessere Ergonomie zulassen als solche mit Block Mode.

Grafische Benutzer-Schnittstellen nun wuerden die Server-Maschinen gaenzlich ueberlasten. Deshalb ist es sinnvoll, hierfuer die Leistung von PCs oder Workstations zu nutzen. Grundsaetzlich sollte es das Ziel sein, von einer Anwendung soviel wie moeglich auf den Client und nur soviel wie noetig auf den Server zu verlagern.

Kann dann nicht die ganze Anwendung auf dem Client laufen und nur das Datenbank-Management-System auf dem Server?

- Ja, wenn Datenbankprozeduren zur Implementierung der Transaktionen verwendet werden sollen. Dann ist der Transaktionsteil der Anwendung innerhalb des DBMS implementiert. Dieses kann zu Performance-Vorteilen durch bessere Optimierungsmoeglichkeiten des DBMS fuehren. Datenbankprozeduren sind aber herstellerspezifisch, was einen spaeteren eventuellen Datenbankwechsel ziemlich teuer macht.

- Nein, wenn die Standard-SQL-Schnittstelle verwendet werden soll. Dann muessen die Datenbanktransaktionen mit einer herkoemmlichen 3GL-Sprache implementiert werden, was Herstellerunabhaengigkeit gewaehrleistet.

In beiden Faellen kann eine Anwendungsarchitektur gewaehlt werden, die die Haeufigkeit der Kommunikation zwischen Client und Server auf ein oder wenige Male pro Transaktion beschraenkt und damit die Voraussetzung fuer eine gute Skalierbarkeit bis hin zu grossen Benutzerzahlen bietet.

Ziel der Transaktionsverarbeitung ist es allgemein, den Anwender bei Abwicklung eines Geschaeftsvorfalls zu unterstuetzen. Die Flexibilitaet der grafischen Benutzeroberflaeche gibt dazu die Moeglichkeiten. Jede Art eines Geschaeftsvorfalls wird als Benutzertransaktion implementiert. Auch komplexere Geschaeftsvorfaelle lassen sich als Ganzes auf dem Client erfassen und bearbeiten.

Mit dem Abschluss der Benutzertransaktion wird auf dem Server zum Verbuchen die zugehoerige Datenbanktransaktion aufgerufen. Diese vereinigt alle zu diesem Vorgang noetigen Operationen. Lesezugriffe werden von der DBMS als isolierte Operationen ausgefuehrt. Das ermoeglicht sogenannte zustandslose Server und damit mehr Leistung.

Auf Grossrechnern mit IBMs CICS ist es gaengige Praxis, sogenannte pseudokonversationale Transaktionen zu implementieren. Sie vermeiden das Halten von Sperren (Locks) innerhalb von Datenbanken waehrend Benutzereingaben und ermoeglichen dadurch ein vernuenftiges Leistungsverhalten. Die in der Abbildung gezeigte Anwendungsarchitektur erlaubt es, durch nicht-konversationale Transaktionen das Leistungsverhalten noch zu verbessern.

Waehrend einfache Plausibilitaetspruefungen einfach lokal auf dem Client durchgefuehrt werden koennen, verursachen Pruefungen auf Vorhandensein bestimmter Daten (referentielle Integritaet) oft Performance-Probleme. Ab etwa 50 bis 100 Benutzern laesst sich die referentielle Integritaet noch direkt nach der Eingabe einzelner Werte ueberpruefen, bei sehr grossen Benutzerzahlen sollte sie, wenn immer moeglich, erst innerhalb der Datenbanktransaktion geprueft werden. Je nach Skalierungsanforderungen sind auch Kompromisse zwischen beiden Verfahren moeglich.

Die gezeigte Anwendungsarchitektur stellt ein Basismodell dar, das zur Implementierung spezifischer Anforderungen erweitert werden kann: Durch Kaskadierung laesst sich eine dreistufige Client-Server- Architektur realisieren, um etwa mehrere Geschaeftsvorfaelle, die zusammen eine hoehere Einheit bilden, von einem lokalen auf einen zentralen Server zu uebertragen.

Ebenso lassen sich lokale Server zur schnellen und zuverlaessigen Erfassung von Daten verwenden, die beispielsweise durch einen asynchronen Hintergrundprozess auf zentrale Server uebertragen werden. Auch hier erfaehrt das Architekturmodell einfach eine Kaskadierung. Es lassen sich aber auch Transaktionen zum lokalen Server mit solchen zu zentralen Servern mischen.

Die Erfahrung mit Client-Server-Projekten hat in allen Faellen gezeigt, dass die Wahl einer geeigneten Anwendungsarchitektur den groessten Einfluss auf den Erfolg oder Misserfolg des Projekts hat. Die vorgestellte Architektur wurde bei Hewlett-Packard auf der Basis von mehr als sechs Jahren Erfahrung mit Client-Server- Projekten entwickelt.

Monitore fuer Client-Server-DV

Transaktionsverarbeitende Anwendungen im Client-Server-Umfeld benoetigen nicht unbedingt einen Transaktionsmonitor. Bei Verwendung eines zuverlaessigen Kommunikationsdiensts koennen je nach System Anwendungen fuer bis zu 1000 aktive Benutzer entwickelt werden.

Fuer den Einsatz von Transaktionsmonitoren in Client-Server- Umgebungen gibt es hauptsaechlich vier Gruende:

- die einfachere Kommunikation zwischen den Rechnerebenen;

- die Leistungssteigerung;

- die Migration von bestehenden Systemen;

- die Moeglichkeiten verteilter Transaktionen und

- andere Features wie die hoehere Sicherheit und Wiederanlauf nach Systemabstuerzen.

Die einfachere Kommunikation zwischen Client und Server wird dadurch erreicht, dass die Transaktionsmonitore diese auf hoeherer Ebene anbieten als die sonst verfuegbaren Kommunikationsdienste. So laesst sich ein Remote Procedure Call (RPC) innerhalb einer verteilten CICS-Umgebung einfach durch ein Exec-CICS-Link- Konstrukt (Distributed Program Link) erzeugen. Transarcs Encina- Monitor bietet transaktionelle RPCs mit gleichem Komfort. Leistungssteigerung vor allem bei vielen Benutzern erreicht man auch unter Unix durch die klassischen Methoden der Serialisierung und Reduzierung der Server-Prozesse.

Bei Leistungstests mit Kundenanwendungen auf HP9000-Servern konnten so mehr als 7500 aktive Benutzer unterstuetzt werden. Eingesetzt wurde dabei der Tuxedo-Transaktionsmonitor, der zu den ausgereiftesten Vertretern seiner Klasse gehoert.

Bei der Migration sind verschiedene Aspekte zu beruecksichtigen:

- Wie koennen bestehende Grossrechneranwendungen in eine Unix-Welt portiert und dort in Richtung Client-Server weiterentwickelt werden?

- Wie koennen Client-Server-Anwendungen mit bestehenden Grossrechner-Anwendungen kommunizieren?

- Wie lassen sich die vorhandenen Kenntnisse der Anwendungsentwickler in einer bisherigen Grossrechnerwelt auch in einer Client-Server-Welt mit Unix-Systemen nutzen?

Um den Aufwand moeglichst gering zu halten, greifen viele Anwender zu einem System, das dem bisherigen Mainframe-Produkt so aehnlich wie moeglich ist. In den meisten Faellen ist das IBMs Unix-CICS. Es laeuft auf Plattformen mehrerer Hersteller, verfuegt ueber eine kompatible Funktionalitaet und ein identisches API zu anderen CICS- Implementierungen sowie ueber eine einfach zu verwendende Intersystemkommunikations-Schnittstelle.

Der Einsatz verteilter Transaktionen bringt es mit sich, dass Veraenderungen in Datenbanken mehrerer Server vorgenommen werden. Um dabei Integritaetsprobleme zu vermeiden, wird ein Two-phase- Commit-Verfahren eingesetzt, das oft auch von Datenbank- Management-Systemen angeboten wird, dann aber nur innerhalb einer homogenen Datenbankumgebung.

Wenn Server und Datenbanken unterschiedlicher Hersteller zum Einsatz kommen, schlaegt die Stunde des Transaktionsmonitors. Ueber das durch X-Open genormte XA-Protokoll koennen Transaktionsmonitore mit Datenbank-Management-Systemen kommunizieren und fuer ein zuverlaessiges Two-phase-Commit sorgen.

Durch verteilte Transaktionen laesst sich der Trend zu einer immer engeren Koppelung verschiedener Anwendungen und den daraus resultierenden zunehmend komplexeren Transaktionen mittelfristig auffangen. Die Lastverteilung auf mehrere Server gestattet eine parallele Verarbeitung auf hoher Ebene. Unterstuetzt wird dieses durch die Moeglichkeit, mittels Threads gleichzeitig Remote Procedure Calls zu verschiedenen Servern abzusetzen.

Eine andere Option bietet das Distributed Transaction Processing unter CICS, das aber weniger gut strukturierte Programme ergibt.

Haeufig werden heute transaktionsverarbeitende Anwendungen mittels Sprachen der vierten Generation (4GL) implementiert. Wird das Werkzeug eines Datenbankherstellers verwendet, so schliesst das die Verwendung eines TA-Monitors in aller Regel aus, da er nicht unterstuetzt wird. 4GL-Systeme, die nur die Client-Seite unterstuetzen, sind auf der Server-Seite auf Datenbankprozeduren angewiesen und kommunizieren daher direkt mit der Datenbank.

Unzulaenglichkeiten im Client-Server-Betrieb

Ein anderes Problem stellt der weithin uebliche Einsatz von

PCs als Clients dar. Die durch unzureichendes Memory-Management und ungenuegende Multitasking-Faehigkeiten der DOS/Windows-Umgebung immer wieder auftretenden Programmabbrueche, lassen sich bei echt verteilt laufenden Client-Server-Anwendungen, wie sie in der Transaktionsverarbeitung notwendig sind, nicht durch einfaches Neustarten des PCs auffangen.

Stuerzt ein isolierter Rechner ab, dann muessen die Anwendungen neu gestartet und die - in der Regel nicht allzu umfangreiche - verlorene Arbeit nachgeholt werden. Bei verteilten Systemen sind in einem solchen Fall die Server-Komponenten noch aktiv, aber der PC kann sie nicht mehr finden. Das hat zum Beispiel zur Folge, dass sich der Benutzer nicht mehr am Server anmelden kann, weil dort noch sein alter Prozess laeuft.

Trend zum Workflow

Der Betrieb laesst sich stabiler gestalten, indem zwischen PC und Datenbank-Server ein Applikations-Server mit Unix-Betriebssystem geschaltet wird, der die Rolle des Clients gemaess dem bereits beschriebenen Architekturmodell uebernimmt. Der PC stellt dann etwa ueber X-Windows nur noch die Oberflaeche dar, waehrend die Verarbeitung der Benutzertransaktion auf dem Applikations-Server erfolgt, der zwischen 50 und 100 PCs sinnvoll bedienen kann. Mit dieser Aufteilung sind die Transaktionsanwendungen unempfindlich gegen Abbrueche und "Re-Boots" der PCs, und neue Versionen der Applikationen muessen nicht auf jeden einzelnen PC verteilt werden.

Der wichtigste Trend der kommenden Jahre ist im Bereich Transaktionsverarbeitung mit Sicherheit das Workflow-Management. Obwohl Transaktionen bisher atomar definiert wurden, stellen sie doch nur einzelne Schritte von globaleren Geschaeftsprozessen dar. Workflow wird daher verantwortlich fuer nicht-atomare Transaktionen wie fuer die Verarbeitung eines Auftrags von der Auftragsannahme bis zur Auslieferung. Bei solchen komplexen Vorgaengen reicht die reine Transaktionsverarbeitung nicht mehr aus, weil die Dokumentenverwaltung integriert werden muss.

Kurzes Glossar zur Transaktionsverabeitung

ACID: Die Attribute einer Transaktion, naemlich Atomicity, Consistency, Isolation, Durability

Application-Server: ODTM-faehiges Transaktionssystem

CICS: Customer Information Control System (Kunden-

Informations-Steuerungs-System), dasTransaktionssystem von IBM (fuer OS/2, AIX, OS/400, VSE, MVS, ESA) und HP, DEC, Sun, Apple, Novell und Vorbild

aller anderen einschlaegigen Produkte.

Logical Unit of Work (LUW): Teil einer Transaktion, die unter allen Umstaenden als Ganzes behandelt werden muss, um die Konsistenz nicht zu gefaehrden.

ODTM: Open Distributed Transaction Management, die offene und verteilte Version von OLTP.

OLTP: Online Transaction Processing, bisher vorwiegend zentralisierte Transaktionsverarbeitung.

Transaktion: Kleinster unteilbarer Anwendungsprozess

einer Anwendung.

Transaktionssystem: Summe aus Transaktions-Manager und -monitor, ermoeglicht heute ODTM.

Transaktions-Manager: Optimiert die gemeinsamen Ressourcen, ermoeglicht gleichmaessige Antwortzeiten, verwaltet und sichert die Transaktionen ( vgl. ACID), serialisiert gleichzeitige Anforderungen usw.

Transaktionsmonitor: Beinhaltet die einheitliche Programmier- Schnittstelle quer ueber alle Plattformen.

* Georg Hermann ist Leiter Vertriebs-Marketing im CSO-Bereich von Hewlett-Packard in Boeblingen.