Noch ist der Markt für Online-Transaktionsverarbeitung (OLTP) unter Unix überschaubar: Wenige bieten Produkte an, und ein Marktführer konnte sich bisher nicht etablieren. Allein Tuxedo von den Unix

System Laboratories (USL) weist bisher eine nennenswerte installierte Basis auf. Dies könnte sich schon bald ändern. Im ersten Teil dieses

Beitrags beleuchtet Joachim Hoffmann* die Marktlage, in der zweiten Folge stellt er die verfügbaren Produkte vor.

Nachdem das Standardisierungsgremium X/Open mit einem Modell für verteilte Transaktionsverarbeitung immer wieder auf sich warten läßt, scheint die Definition von OLTP-Standards auf anderem Terrain zu erfolgen: Das freie Spiel der Marktkräfte diktiert hier die Zukunft. In diesem Jahr werden neue Produkte von IBM, HP und Stratus erwartet, die alle die Encina-Technologie von Transarc nutzen.

Dies bedeutet für den Tuxedo-Anbieter USL, daß er sich

auf immer mehr Wettbewerb einrichten muß und Gefahr läuft, seine dominante Stellung im Unix-OLTP-Markt zu verlieren. Diese Entwicklung wird zusätzlich da durch verstärkt, daß Marktgiganten wie IBM und

DEC, aber auch eine Reihe von Mainframe-Softwerkern mit eigenen Produkten in diesen Markt vorstoßen.

Bei kommerziellen Anwendungen gehen die Kunden oft Kompromisse ein, verzichten auf spezielle Leistungsmerkmale und sind zufrieden, wenn ein System 90 Prozent ihrer Anforderungen erfüllt. Das ist bei OLTP-Systemen anders. Hier müssen Verfügbarkeit, Performance und Handhabbarkeit mindestens zu 99 Prozent gewährleistet sein. Zudem gibt es im OLTP-Markt eine Reihe von Anforderungen, die sich erst beim praktischen Einsatz zeigen.

Verglichen mit den im OLTP-Sektor nach wie vor tonangebenden proprietären Architekturen, präsentiert sich Unix als ein noch recht unausgereiftes Betriebssystem. Zwar steht einem Einsatz kommerzieller Anwendungen heute nichts mehr im Wege, um im OLTP-Geschäft mithalten zu können, müssen die entsprechenden Unix-Produkte aber noch verbessert werden. Dies besonders

- beim zugrundeliegenden Betriebssystem und den Systemsoftware-Technologien sowie

- beider Software-Integration. Hier fehlt noch ein nahtlos integriertes Produktset vom TP-Monitor bis zum Betriebssystem.

Technologieanbieter wie USL und die Open Software Foundation (OSF), aber auch eine Reihe von Spezialanbietern, haben in den zurückliegenden beiden Jahren dafür gesorgt, daß Unix um Leistungsmerkmale für kommerzielle Anwendungen ergänzt wurde. Drei Bereiche sind derzeit aber noch verbesserungsbedürftig. Dies sind Performance, Fault Resiliency (dynamisches Störausgleichverhalten) und System-Management.

Unix-Systeme mit hoher Performance dürfte es bis 1993 geben. Hier heißt die Lösung Multithreading. Dieses Verfahren ermöglicht einem Programm die gleichzeitige Ausführung mehrerer Operationen innerhalb eines Prozesses. So kann das Programm andere Aufgaben verrichten, während es auf die Beendigung asynchroner Ereignisse wartet.

Die meisten Unix-Programme bewerkstelligen dies derzeit, indem sie zahlreiche Prozesse erzeugen, von denen jeder eine der gleichzeitig ausgeführten Aufgaben bearbeitet.

Problematisch an dieser Implementation ist jedoch, daß zur Synchronisation der verschiedenen Prozesse.

Interprozeß-Kommunikationsmöglichkeiten (IPC) erforderlich sind, die wertvolle Verarbeitungsressourcen beanspruchen. Werden demgegenüber mehrere gleichzeitig aktive Threads innerhalb eines Prozesses ausgeführt, ist eine Synchronisation über den gemeinsam genutzten Hauptspeicher möglich, so daß externe Systemressourcen nur minimal beansprucht werden.

Störausgleich ist kein Unix-Feature

Dynamisches Störausgleichverhalten gehörte in der Vergangenheit nur selten zu den Unix-Features. Diese Eigenschaft unterscheidet sich deutlich vom Bereich Fehlertoleranz. Beim Störausgleich erfolgt die Beseitigung von Systemproblemen unbemerkt. Entsprechende Leistungsmerkmale etwa schnelle Recovery File Systems - wurden bereits in spezielle Unix-Varianten implementiert. Weitere Leistungsmerkmale für Stand-alone- und Netzwerksysteme werden derzeit eingebaut.

OLTP-Systeme stellen sehr hohe Anforderungen

Jeder Anbieter, der in den offenen OLTP-Markt einsteigen will, sollte sich die folgenden Fragen stellen:

- Sind die zugrundeliegenden Unix-Technologien heute bereits ausgereift genug, um den strengen Anforderungen von OLTP-Systemen zu entsprechen?

- Welche Form hat das XTP-Modell für verteilte Transaktionsverarbeitung der X/Open derzeit, und wie wird es sich wohl Weiterentwickeln? - Was sind die fahrenden Unix-OLTP-Architekturen, und welche Vor- und Nachteile bieten sie?

Mit dem Trend zu offenen Systemen und der Herausbildung des kommerziellen Unix-Marktes hat Unix auch als OLTP-Plattform an Bedeutung gewonnen. Allerdings sehen viele Hersteller, insbesondere Unix-Anbieter, oft nicht, daß an OLTP-Systeme und -Software ungleich höhere Anforderungen als an normale kommerzielle Anwendungen gestellt, werden.

Fehlertolerante High-end-Unix-Systeme gibt es von Sequoia, für Low-end-Rechner bieten Tandem und Stratus Produkte an. Abseits vom Markt für Fehlertoleranz haben weitere Hersteller Merkmale wie Fehlerisolation und schnelle Wiedergewinnungsmöglichkeiten implementiert, ohne daß dem Kunden hierbei Mehrkosten für Redundanzmerkmale abverlangt werden. Bei ihrer MIS-S-Reihe versucht Pyramid, Software- und Hardwareprobleme innerhalb der betroffenen Prozesse zu puffern. Hierbei werden nur diese Prozesse vom Systembetrieb abgekoppelt. Die übrigen Systemfunktionen bleiben intakt.

Zieht ein CPU-Fehler die .Multiprocessing-Umgebung des Betriebssystem-Kernels in Mitleidenschaft" schaltet sich das System zwar ab, gleichzeitig deaktiviert jedoch die Diagnosesoftware den fehlerhaften Prozessor und führt anschließend automatisch einen Reboot und eine Systeminitialisierung durch, so daß es nur zu einer minimalen Ausfallzeit kommt.

Für im Verbund betriebene Systemumgebungen soll es in Kürze von einigen Herstellern eine Unix-basierte Clustering-Technologie auf der Grundlage von Oracles Parallel Server-Software geben. IBM und Pyramid wollen das Clustering bis zum dritten Quartal 1992 unterstützen. Von Sequent wird es dieses Leistungsmerkmal zu einem späteren Zeitpunkt geben. Eine interessante Alternative wäre hier auch ein herstellerneutrales Clustering-Verfahren, das die Parallel-Server-Distributed-Lock-Manager (DLM)-API unterstützt.

Problematisch gestaltet sich in Unix-Umgebungen das System-Management. Hier sind System-Utilities wie etwa Back-up-Dienstprogramme - ohne die OLTP-Umgebungen undenkbar sind - in bestimmten Bereichen noch verbesserungsbedürftig. Die meisten heute verfügbaren Unix-Backup-Tools erkennen beispielsweise nicht, ob das System zum Zeitpunkt eines automatischen Backups heruntergefahren ist. Wird das System etwa wegen allgemeiner Wartungsarbeiten vom Administrator deaktiviert, unterbleibt in diesem Fall das automatische Backup und muß folglich manuell durchgeführt werden.

Integriertes Set von Produkten

Eines der erfreulichsten Merkmale von Unix und offenen Systemen ist, daß sich Softwarekomponenten problemlos miteinander zu fertigen Anwendungen kombinieren lassen. Die Kehrseite: Standard-APIs, die zur Gewährleistung der Interoperabilität der Softwarekomponenten produktneutral bleiben müssen, können aus eben diesem Grund keine Spezialbereiche wie Fehlerbehandlung oder Performance-Anforderungen abdecken. Noch schwerer wiegt die mangelhafte Integration von Softwarekomponenten in OLTP-Umgebungen.

Der Grund hierfür liegt darin, daß Merkmale wie hoher Datendurchsatz, Behandlung von Ausnahmefällen und hochentwickelte Management-Möglichkeiten, die bei anderen Anwendungen womöglich als Luxus gelten, in OLTP-Umgebungen absolut notwendig sind.

Beachtliche Kosten für den Hersteller

Ein integriertes Produktset für OLTP-Unix bedeutet beachtliche Kosten für den Hersteller, da er über seine Entwicklermannschaft eine flexible, offene Umgebung, die auf dem neuesten technologischen Stand ist" bereitstellen muß. Hinzu kommt, daß diese Umgebung neuen Standards entsprechen muß.

Da die Anwender immer häufiger standardkonforme und leistungsfähige Softwareschnittstellen verwenden, muß ein OLTP-Produktset heute auch unbedingt ein direktes Interface zu diesen Produkten bereitstellen beziehungsweise zu anderen Third-Party-Komponenten interoperabel sein, die diese unterstützen. Vielen Anwender nennen ein OLTP-Paket, das nur von einem Hersteller erhältlich ist, abschätzig proprietär.

Nach Einschätzung von IDC beurteilen die Anwender den Grad der Offenheit eines Anbieterprodukts künftig in erster Linie danach, ob es Standards und andere Produkte integrieren kann.

In der OLTP-Landschaft sind die Regeln von X/Open für Transaktionsverarbeitung, und das relationale Modell für Datenbanksysteme solche Standards.

De-facto-Standard in der Mainframe-Welt ist IBMs Transaktionsmonitor CICS. In anderen Bereichen hofft die Industrie auf das Transaktionsmodell (Transaction Processing, TP) von X/Open.

Dabei handelt es sich nicht um eine Technologie. Vielmehr besteht es aus einer Reihe von Schnittstellen-Definitionen, mit deren Hilfe sich unterschiedliche Komponenten zu einer nahtlos integrierten TP-Umgebung kombinieren lassen.

Wollte die X/Open-Organisation ursprünglich eine Standardschnittstelle für die Entwicklung eines TP-Systems bereitstellen, so definiert das heute vorliegende Modell ein Verfahren für Distributed Transaction Processing (DTP). Fertiggestellt wurde es im ersten Quartal 1992 mit folgenden Schnittstellen für die Anwendungsentwicklung (APIs): XA, XA +, Transaction Manager Interface (TXI) und Kommunikationserweiterungen für TXI.

XA-Schnittstelle ist genau definiert

Die XA-Schnittstelle wurde zuerst fertiggestellt und 1990 öffentlich zugänglich gemacht. Diese Spezifikation definiert die Schnittstelle zwischen dem Transaction Manager (TM) und beliebigen, von ihm genutzten lokalen Systemressourcen. Derzeit sind Daten-Manager (RDBMS oder andere) solche lokalen Ressourcen. Künftig soll XA aber auch Schnittstellen zu weiteren Systemressourcen, etwa Namens- oder Management-Diensten, unterstützen.

Da die XA-Daten-Manager-Schnittstelle genau definiert ist, wird sie heute von den meisten Unix-TP-Monitoren verwendet. Die populären Daten-Manager, etwa relationale Datenbanksysteme, bieten die XA-Unterstützung aber erst seit kurzem. So hat Informix jetzt für das Datenbankprodukt Online, Release 5.0, die umfassende XA-Unterstützung, freigegeben. Auch Oracle will sie in ihrem Release 7.0 anbieten. Release 7.0 befindet sich derzeit im Beta-Test und soll im 3. Quartal dieses Jahres allgemein verfügbar sein.

X/Open definiert die Details für APIs

Für die drei anderen APIs liegen bislang noch keine endgültigen Beschreibungen vor. Nach der Fertigstellung des DTP-Modells, definiert X/Open derzeit die Details für die verschiedenen APIs. Die TXI-Schnittstelle definiert die Interaktion einer Applikation mit Transaktionsmonitoren sowie die von der Anwendung kontrollierten Ressourcen. Das Gros der in TXI spezifizierten semantischen Regeln ermöglicht einer Applikation Definition, Beginn, Beendigung und Ausführung von Transaktionen.

Die XA + -Schnittstelle ermöglicht der XA-Schnittstelle zusätzlich die Interaktion mit den Communications Resource Managers (CMR). Diese residieren unterhalb des Transaktions-Managers und sorgen in Netzwerken für Standardkommunikationen zwischen beliebigen TP-Monitor-Technologien. Die TXI-Erweiterungen erlauben einem Anwendungsprogramm den Beginn der Kommunikation mit Applikationen und Ressourcen, die auf anderen Systemen im Netzwerk gespeichert sind. Diese Erweiterungen, die gemeinhin als Peer-to-Peer-Kommunikationsdienste betrachtet werden, ermöglichen Anwendungen die gemeinsame Datennutzung im nicht-transaktionsorientierten Betrieb.

Ansätze für verteilen Transaktionsverarbeitung

Das DTP-Modell wurde unter anderem deshalb mit Verspätung fertiggestellt, weil die Beteiligten zwei unterschiedliche Verfahren favorisierten. Die USL reichte als Technologievorschlag für DTP ihr transparentes Client-Server-Modell auf Tuxedo-Basis ein, während NCR und IBM den als XA + bezeichneten Ansatz unterstützen. Die X/Open fand einen Kompromiß, bei dem die Entscheidung zwar für das XA+ -Modell fiel, der Konformität von Tuxedo mit dem DTP-Modell aber keine Hindernisse entgegenstehen.

Technisch unterscheiden sich die beiden Ansätze hauptsächlich darin, wie die Integration der Kommunikationsdienste mit dem TP-Modell jeweils realisiert wird. Bei dem von Tuxedo verwendeten Verfahren werden die Kommunikationsdienste in der Monitor-Software integriert. Damit lassen sich Transaktionen transparent über das gesamte Netzwerk verteilen. Der TP-Monitor verwendet dabei Standard-Namensdienste zur Lokalisierung und Verwaltung beliebiger Ressourcen-Manager im Netzwerk, so daß die Unabhängigkeit vom jeweiligen Standort gewährleistet ist.

Ein Vorteil dieses Verfahrens liegt darin, daß sämtliche lokalen wie auch die über das Netz verteilten Ressourcen für eine Applikation identisch sind.- Auf lokale und Remote-Datenbanken wird mit denselben Aufrufen zugegriffen.

Ein weiterer Pluspunkt ist die nahtlose Integration der Kommunikationsdienste. Hierdurch sind effizientere Mechanismen zur Fehlerbehebung möglich. Auch lassen sich Ressourcen einfacher lokalisieren. Gleichzeitig verbessert sich die Performance beim Datentransfer im Netzwerk.

Der Hauptnachteil von Tuxedo besteht darin, daß neue Kommunikationstechniken verwendet beziehungsweise externe Kommunikations-Manager unterstützt werden. Da diese Mechanismen fest in die TP-Technologie implementiert sind, müssen sich OEMs darauf verlassen, daß ihr Lieferant sie fristgerecht implementiert. Vorhandene CRMs lassen sich in einer TP-Monitor-Umgebung nicht verwenden, was womöglich die Interoperabilität mit im Netzwerk eingesetzten Datenbankanwendungen erschwert.

Beim XA + -Verfahren residieren die Kommunikationsdienste in einem separaten Modul mit einer exakt definierten Schnittstelle. Die Anwendungen müssen die Datenverbindung initiieren und benötigen Kenntnisse über die jeweiligen Elemente, mit denen sie in Verbindung treten (eine andere Anwendung, ein Remote-Ressourcen-Manager etc.). Die kommunikationsspezifischen Ressourcen-Manager verbergen die umgebungsabhängigen Netzwerk-Merkmale, zum Beispiel Netzwerktyp oder Protokoll, vor der Applikation.

VA + -Verfahren hat Vor- und Nachteile

Die Vorteile dieses Ansatzes liegen in der Flexibilität. Mit dem XA + -Verfahren lassen sich zahlreiche unterschiedliche Kommunikationsdienste und Möglichkeiten problemlos in einer Umgebung integrieren. Auch deren Unterstützung durch die Applikation ist kein Problem. Des weiteren können bei der XA + -Methode unterschiedliche Architekturen und Konzepte wie Peer-to-Peer, Client-Server oder Remote Procedure Call (RPC) genutzt werden.

Nachteilig an diesem Verfahren ist, daß es zur Einschränkung der Performance und Fehlerbehebung kommt, wenn weitere Schichten und Schnittstellen definiert werden. Standardisierte Schnittstellen verhindern nämlich, daß der Transaktions-Manager die in den Kommunikationsdiensten angelegten Möglichkeiten, die höhere Transferraten oder bessere Erkennungsverfahren in Fehlersituationen gewährleisten, voll ausreizen kann. (wird fortgesetzt)