Konkret sind die neuen OLTP-Entwicklungen auf grafische Benutzeroberflaechen (GUIs)

angewiesen, unter Verwendung von Icons und Maus fuer Eingabe und Kontrolle. Es besteht ferner Bedarf an zusaetzlichen System- und Netzwerk-Verwaltungsmoeglichkeiten.

Gleichzeitig muss bestaendig das Preis-Leistungs-Verhaeltnis verbessert werden. Ausserdem interessieren sich die Benutzer kontinuierlich fuer CASE- und Repository-Technologien; hohe Verfuegbarkeit und Robustheit der Systeme bleiben ebenfalls ein staendiges Thema.

Bekannt sind traditionelle zentralistische Anwendungen, die ueber relativ langsame Netze mit dem zentralen Host kommunizieren. Ein solches System behandelt verhaeltnismaessig einfache Anwendungen mit Attributen wie etwa textorientierten Benutzerschnittstellen. Mit ausgereiften Netzwerken und Systemen begann die Implementierung von verteilten Anwendungen. In der Regel arbeiten die Systeme dabei unabhaengig voneinander und benutzen File- Transfer, um Informationen zu teilen. Hin und wieder werden Front-End-Systeme wie beispielsweise PCs verwendet, um zentralistische Anwendungen grafisch praesentieren zu koennen. Bei Peer-to-Peer-Kommunikation kommen proprietaere Schnittstellen wie beispielsweise IBMs LU6.2 zum Einsatz.

Heute sind sowohl die Technologien als auch die Standards verfuegbar, die ein echtes Cooperative Computing ermoeglichen. Diese Anwendungen sind in Module aufgeteilt, zum Beispiel als Client- und Server-Module. Jedes von ihnen kann dann auf unterschiedlichen Rechnertypen arbeiten. Die zur Verfuegung stehende Leistung unterstuetzt komplexe Aktivitaeten, Real-Time- Verarbeitung wie Imaging, verteilte Datenbanken und Transaktions- Verarbeitung.

Die heutige Systemumgebung besteht aus Information-Hubs, Abteilungssystemen und PC-LANs. Open/OLTP, eine Transaktions Verarbeitung fuer offene Systeme, unterstuetzt ein Regelwerk und eine Architektur, die diese unterschiedlichen Systeme in eine einheitliche Umgebung integriert, so dass man die Vorteile lokaler Daten, groessere Robustheit in einer kooperativen Umgebung und die Moeglichkeiten, die von den unterschiedlichen Systemen angeboten werden, nutzen kann.

Es gibt drei Voraussetzungen fuer die verteilte Transaktions- Verarbeitung. Jedes System im Netzwerk muss OLTP in einer effizienten und sicheren Form unterstuetzen, die Systeme muessen in der Lage sein, mit den anderen ueber ein allgemeines Netzwerk- Protokoll zu kommunizieren; das Netzwerk selbst muss hohe Leistung und Sicherheit fuer die Anwendungen bieten.

Letztendlich muss jedes System, einschliesslich PCs, Servern und Hubs von unterschiedlichen Herstellern, in der Lage sein, eine Lastverteilung mit anderen zu unterstuetzen. Die dazu noetigen Standards sind heute definiert und verfuegbar. Viele Hersteller arbeiten heute daran, sie in Produkte umzusetzen.

Die meisten OLTP-Anwendungen sind Mission-Critical. Deshalb gibt es viele Ziele im operationalen Bereich, die die Entwickler von OLTP-Systemen anstreben muessen. Im wesentlichen konzentrieren sie sich auf drei Schwerpunkte: die Verfuegbarkeit, die Leistung und die Kontrolle.

Dazu gehoert die Moeglichkeit zum schnellen Neustart nach Fehlern. Daten muessen greifbar sein, auch wenn eine CPU oder ein Medium nicht mehr funktionsfaehig ist. Es muss moeglich sein, Prioritaeten zu kontrollieren und zu verwalten, um kurze Antwortzeiten sicherstellen zu koennen. Kontrollierter Shut-Down, Datenintegritaet ueber das gesamte Netzwerk und der operatorlose Betrieb sind weitere wichtige Aspekte.

Mit Open/OLTP werden diese Funktionen fuer Unix-Systeme verfuegbar. Das heisst, Unix wird mit zusaetzlichen Eigenschaften ausgestattet wie einem Transaction-Manager, sicheren Datenbanken, Dual-Port- Funktionalitaet fuer System-Ausfallsicherheit und der Moeglichkeit der Datenspiegelung, so dass die Verfuegbarkeit der Daten jederzeit garantiert ist. Das Datenbank-Management-System ist mit entsprechenden Rollback- und Recovery-Funktionen ausgestattet, das bei einem Fehler die Daten in den urspruenglichen Zustand versetzt.

Wichtige Attribute von OLTP-Systemen sind die bekannten ACID- Eigenschaften:

- Atomicity: Eine Transaktion wird zur Sicherung der Datenintegritaet ganz oder gar nicht durchgefuehrt.

- Consistency: Die Daten muessen immer gueltig sein, wobei Relationen zwischen unterschiedlichen Tabellen gewahrt werden.

- Isolation: Jede Aenderung und alle Transaktionen muessen unabhaengig voneinander sein.

- Durability: Rollback und Recovery im Fehlerfall sind sicherzustellen.

Diese ACID-Eigenschaften werden von X/Open und ISO zur Beurteilung von OLTP-Attributen eines Systems verwendet und sind fuer die Spezifikationen des TPC Benchmark A erforderlich.

OLTP-Dimension in drei Klassen reflektiert

Zunaechst ist eine weitere OLTP-Dimension zu eroertern, die durch die Einteilung in die drei folgenden Klassen reflektiert:

OLTP light ist eine typische relationale Datenbank unter Unix wie beispielsweise Oracle oder Informix. Sie verfuegt ueber eine Reihe von Funktionen in den Bereichen Datenintegritaet und Recovery und wird heute in Anwendungsumgebungen mit niedrigerer Komplexitaet und mit geringerem Bedarf an Leistung verwendet.

Am anderen Ende der Skala steht das Premium-OLTP fuer die typischen zentralistischen Mainframes. Beispiele sind TIP/Marks auf 2200-Systemen von Unisys oder CICS auf IBM-Systemen.

Dazwischen positioniert ist Open/OLTP, das eine erhebliche Leistungssteigerung gegenueber den OLTP-Light-Systemen bietet, naemlich eine erweiterte Systemverwaltung und Prioritaetenkontrolle. Es basiert auf X/Open-Standards zu verteilten Rechner-Architekturen und ist unabhaengig von einzelnen Herstellern. Open/OLTP fuegt der Plattform offener Systeme Attribute der Premium-Klasse hinzu. Auf was diese Leistungssteigerung beruht, soll im folgenden erlaeutert werden.

Traditionelles und modulares OLTP

Betrachtet man zunaechst die Entwicklung der Anwendungsumgebungen von den traditionellen Mainframes hin zu den modernen Architekturen, so ist ein Uebergang von engverzahnten Komponenten, integrierten Schnittstellen und proprietaeren APIs zu modularen, auf Standards basierenden Architekturen zu verzeichnen: Clients, Netzwerke, Server, Resource Manager, und alles ueber definierte APIs verbunden.

Dies ermoeglicht den raschen Austausch von einzelnen Komponenten durch leistungsfaehigere beziehungsweise billigere Module, ohne den Rest der Anwendung zu tangieren. Das bedeutet auch, dass die Clients und Server unabhaengig vom eingesetzten Netzwerk (X.25 oder TCP/IP) arbeiten.

Heute werden in den typischen Datenbank-Anwendungen solche Strukturen und Module verwendet.

TPC-A Benmarks haben gezeigt, dass auf Systemen mit gleicher Ausstattung lediglich durch die Nutzung des Transaction Managers eine im Minimum vierfache Leistungssteigerung erreichbar ist.

Mit einer herkoemmlichen Informix-Online-Anwendung ohne Transaction Manager auf einer grossen 6000/80 werden 200 Benutzer unterstuetzt. Hier gibt es eine Eins-zu-eins-Beziehung zwischen den Client-Prozessen, das heisst, fuer jeden der 200 beteiligten User wird ein Schattenprozess des DB-Systems mitgefuehrt, so dass insgesamt 400 Prozesse im System aktiv sind (200 Client- und 200 Server-Prozesse). Nach TPC-A-Regeln muessen zehn oder Clients pro TPS (Transaction per second) angenommen werden, so dass mit dieser Konfiguration 20 TPS erreicht wurden.

Mit derselben Konfiguration unter Hinzunahme des Transaction Managers lassen sich 800 User mit nur 24 Servern unterstuetzt (shared Server). Hier werden 80 Transaktionen pro Sekunde erzielt und auch niedrigere Kosten je Transaktion. Die Shared-Server- Architektur reduziert also die Anzahl der Unix-Prozesse und den Bedarf an Hauptspeicherkapazitaet.

Durch die Faehigkeit des Transaction Managers, Prioritaeten zu kontrollieren und die Queues zu verwalten, wird der Zugriff auf die 24 Server optimiert. Damit sinken die Antwortzeiten und werden genauer prognostizierbar.

Die Basis von Open/OLTP bildet das X/Open-Modell fuer verteilte Transaktion-Verarbeitung. Es gilt grundsaetzlich nicht nur fuer die Implementierung unter Unix, sondern hat Allgemeingueltigkeit auch fuer andere Systeme, indem es verschiedene Funktionen beschreibt:

Die Anwendung (AP), die in einer 4GL, in C oder Cobol geschrieben sein kann, ist in Client- und Server-Module aufgeteilt und kommuniziert ueber den Transaction Manager (TM).

Der TM koordiniert die Transaktionen und bietet die Daten- Integritaet, Load Balancing, Netzwerk-Routing und Netzwerk- Unabhaengigkeit. Er regelt die gesamte OLTP-Umgebung und kontrolliert ueber das Two-Phase-Commit die Verfuegbarkeit der Ressourcen im Netzwerk, den Zugriff auf die Services und das Transaction-Queue-Management.

Der Resource Manager (RM) teilt die Ressourcen des Systems zu. Dies sind in erster Linie die relationalen Datenbank-Management-Systeme in einer Unix-Umgebung, koennen aber auch andere Typen von System- Ressourcen sein wie Kommunikations- oder Druck-Server.

Diese Komponenten kommunizieren ueber standardisierte Schnittstellen wie das APTM zwischen Anwendung und TM, das XA- Protokoll zwischen TM und Resource Manager in einer verteilten Transaktion sowie die SQL-Schnittstelle zwischen Anwendung und Resource Manager.

Komponenten von verschiedenen Herstellern

X/Open laesst bei seinen Definitionen die interne Verarbeitung der einzelnen Komponenten aussen vor, definiert aber, welche spezifischen Services diese unterstuetzen und welche Schnittstellen bedient werden muessen. Deshalb koennen die einzelnen Komponenten von unterschiedlichen Herstellern stammen und ueber die gemeinsamen Standard-Schnittstellen zusammenarbeiten. So wird jede Datenbank unterstuetzt, die ueber die XA-Schnittstelle verfuegt.

Jeder Netzknoten enthaelt einen TM. Jedes System im Netzwerk kann darueber hinaus Teile der Anwendung (Clients beziehungsweise Server), die in unterschiedlichen Sprachen geschrieben sind, und diverse Ressourcen enthalten. Die Transaction Manager koordinieren und uebernehmen das Routing der Anfragen von den Clients zu den Servern. Sie verwalten die Aktualisierung der verschiedenen Resource Manager im Netzwerk. Dieses Konzept kann auf jedem TLI- Netzwerk-Transport aufgesetzt werden. Das ist heute TCP/IP oder X.25.

Um Transaction Manager unterschiedlicher Systeme miteinander kommunizieren zu lassen, wird auch hier ein standardisiertes Protokoll benoetigt. Dies liefert OSI mit dem OSI-DTP-Protokoll. Spezifiziert durch X/Open,ist es die Schnittstelle zwischen den Transaction Managern wie Tuxedo, Topend, Encina und anderen. Erste Produkte werden 1993 erwartet.

Das Spektrum der Verteilung

Betrachten wir noch einmal die bereits am Anfang beschriebenen Arbeitsweisen. In den traditionellen zentralistischen Anwendungen sind alle Daten und die Anwendungslogik auf dem zentralen System lokalisiert. Dies ist der Server fuer das unternehmensweite Netz. Der einzige verteilte Teil der Anwendung ist die Anzeige eines Zeichens auf einem Terminal.

Bei Remote Database Access (RDA) oder SQL Front-end spricht man meistens von einem Client-Server-Konzept. Der Client ist in diesem Fall eine intelligente Anwendung, die einige Front-end-Dienste bereitstellt, beispielsweise ein Datenbank-Abfragewerkzeug auf dem PC fuer Syntax-checking.

Die eigentliche Durchfuehrung der Anwendung geschieht auf dem Back-end. Hier wird ledas Front-end-Tool verteilt, das die Anwendungsentwicklung erleichtert, nicht jedoch in den spaeteren Ablauf eingreift.

Bei Remote Procedure Call (RPC) wird die Verteilung von verschiedenen Teilen oder Prozessen der Anwendung moeglich. RPC erlaubt jedoch keine Transaktions-orientierten Anwendungen, da das Two-Phase-Commit nicht unterstuetzt wird.

Vor- und Nachteile der einzelnen Typen

Die verteilte Transaktions-Verarbeitung ermoeglicht, wie bereits erlaeutert, die Aufteilung der Anwendung in separate Prozesse oder Clients und Server, die dann auf verteilten Systemen ablaufen, wobei sogar Client-Anwendungen heute auf PCs unter MS-DOS genutzt werden (WS von USL).

In der Praxis werden Anwendungen in einer Kombination der beschriebenen Typen gestaltet sein, die alle ihre Staerken und Schwaechen aufweisen.

So ist RDA eine Datenbank-orientierte Methode. Hier gibt es diverse De-facto-Standards wie SQL oder DRDA von IBM. OSI arbeitet an einem formalen Standard, der zur Zeit jedoch noch nicht verfuegbar ist. Heute kooperieren die unterschiedlichen SQLs ueber Gateways und Converter, die sich negativ auf die Leistung eines Systems auswirken, jedoch eine hohe Flexibilitaet der Anwendung erlauben. Einige Datenbank-Hersteller bieten heute verteilte Datenbanken, das Two-Phase-Commit ist aber proprietaer und begrenzt auf die Datenbank des einzelnen Herstellers.

Die Tools von RPC sind nicht Endanwender-orientiert, sondern geeignet fuer Low-Level-Programmierung. Das fehlende Two-Phase- Commit sichert keinerlei Datenintegritaet. Am verbreitetsten ist heute ONC von SUN mit NFS.

Commitment zu X/Open-DTP und OSI-DTP

Verteilte Transaktions-Verarbeitung mit Open/OLTP ist konzipiert fuer Two-Phase-Commit, zentralisierte Verwaltung fuer verteilte Anwendungen und Datensicherheit. Ferner unterstuetzt es das Queue- Management. Letztendlich existieren hier schon heute entsprechende Standards und ein Commitment der wichtigsten Hersteller zu

X/Open-DTP und OSI-DTP.

Es bietet also die besten Voraussetzungen fuer das eingangs beschriebene Cooperative Computing, in dem alle Systeme auf allen Ebenen miteinander verteilte Transaktions-Verarbeitung, auf X/Open-DTP basierend, durchfuehren, wobei alle beteiligten Systeme und verfuegbaren Ressourcen integriert sind.

*Klaudia Wolf-Goebel ist Marketing Manager , Unix-Systeme bei der Unisys Deutschland GmbH.