Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.04.1994

Die meisten Anwender bevorzugen sanfte Uebergaenge zu Client-Server- Loesungen Transaktionsmonitore bilden Bruecken zwischen den DV-Welten

Von Juergen Berg*

Viele Anwender moechten ihre Investitionen in die Mainframe-DV auch bei Client-Server-Loesungen wahren. Dazu bietet On- line- Transaktionsverarbeitung (OLTP) eine Bruecke. Die ist allerdings nicht ohne Tuecken. Die Nutzung von Beratung bis hin zum Projekt- Management ist in vielen Faellen zu empfehlen.

Mit der PC- und Unix-Welle ist nicht nur eine andere Generation von Computerbenutzern herangewachsen, sondern auch die Notwendigkeit, unterschiedliche, heterogene Welten miteinander zu verbinden. Hier spielen Datenbanken und TP-Monitore eine entscheidende Rolle. Denn sie gestatten es, die Risiken eines radikalen Plattformwechsels zu umgehen, indem sie die Koexistenz neuer und bestehender Strukturen ermoeglichen. Das wiederum bedeutet, dass die Benutzer nach entsprechenden Konzepten verlangen.

Alte und neue Systeme im Verbund

Ansaetze dafuer gibt es in der Datenbankwelt, wo sich die meisten der modernen relationalen Systeme auf unterschiedlichen Plattformen etabliert haben. Das ist kein Zufall, denn wer die alte mit der neuen Welt verbinden will, kommt zwangslaeufig zur verteilten Verarbeitung.

Wenn mehrere intelligente Workstations oder PCs auf einen zentralen Datenbestand zugreifen, das Anwendungsprogramm aber nicht auf dem zentralen Rechner, sondern auf der Workstation laeuft und dort auch Funktionspruefungen, Validierungen des Dialog vornimmt, ohne den Host zu belasten, dann handelt es sich um eine klassische Client-Server-Anwendung. In ihr sind die Programme und nicht die Daten verteilt.

In vielen grossen Rechenzentren beherrschen nach wie vor zentrale hierarchische oder Codasyl-Datenbanksysteme die Szene. In die Entwicklung der Programme wurden nicht selten Manndekaden investiert. Die Unternehmen sind oft in hohem Masse abhaengig von diesen Applikationen.

Ein echtes verteiltes Datenbanksystem wird aber aus diversen Gruenden auf einem relationalen Modell basieren. Eine Umstellung waere also ein radikaler Einschnitt, unter Umstaenden verbunden mit einem Re-Engineering der gesamten Software. Oft wird daher versucht, zunaechst einmal die Benutzeroberflaeche auf andere Plattformen zu bringen, also die Applikation zu verteilen.

Auf der anderen Seite sind aber oft durch die "Infiltration" von Unix- und PC-Systemen in den Unternehmen Informationsinseln geschaffen worden, die durchaus mit relationalen Datenbanken oder anderen Datenhaltungssystemen arbeiten.

Die Frage lautet daher meist zunaechst nicht zentral oder dezentral beziehungsweise Mainframe versus den Rest der Welt, sondern: Wie laesst sich die Zusammenarbeit, also die Interoperabilitaet zwischen unterschiedlichen Plattformen am besten bewerkstelligen? Wer Giga- oder Terabytes an Datenbestaenden hat, wer rund um die Uhr und an allen Wochentagen DV-Betrieb faehrt und wessen Applikationen beispielsweise auf IMS und DL/I basieren, der wird die hohen I/O- Kapazitaeten sowie die Zuverlaessigkeit des Mainframes zu schaetzen wissen. Allerdings wird er nicht daran vorbeikommen, die Benutzer und Entwickler, die den Komfort von grafischen Benutzeroberflaechen und auf relationalen DB-Systemen basierenden "Decision Systems" gewohnt sind, in die Data-Center-Strategie einzubinden.

Dabei kann es durchaus sinnvoll sein, neue, komfortablere Technologien zu nutzen und neue Applikationen auf anderen Plattformen zu entwickeln, beispielsweise, um den Mainframe zu entlasten.

Typische OLTP-Anwendungen koennen naemlich bis zu 80 Prozent aus dem Benutzerdialog, das heisst dem Validieren von Dateneingaben, der Steuerung von Formularen und Masken etc. bestehen. Der Rest sind Zugriffe auf den Datenbestand. In diesen Faellen bietet sich eine Umstrukturierung der Applikation auf Client (also die intelligente Benutzerschnittstelle) und Server (ein leistungsfaehiges DB-System) auf unterschiedlicher Hardware geradezu an.

Der Anbieterwerbung mit Skepsis begegnen

Prinzipiell kann man zwischen drei moeglichen Wegen waehlen:

- dem Portieren von Applikationen, also dem Verlagern auf eine andere Plattform, ohne den Charakter der Anwendung zu veraendern (keine neuen Funktionen),

- dem Re-Architect von Applikationen, das heisst eine Portierung mit funktionalen Erweiterungen wie zum Beispiel des erwaehnten Verlagerns der Benutzerschnittstelle (also Client-Server- Komponenten einfuegen) sowie

- dem Re-Engineering, das heisst der vollstaendigen Ueberarbeitung der Applikation.

Fuer Schritt 1 werden eine Reihe von Werkzeugen und Umstellungshilfen angeboten, die die Arbeit erheblich erleichtern koennen. Niemand sollte sich jedoch der Illusion hingeben, dass alles weitgehend automatisch ablaeuft, auch wenn die Hochglanzbroschueren noch so schoen sind.

Fuer viele spezielle Probleme gilt: "Yes, you can do it - by yourself." Hier ist es noetig, ein sorgfaeltiges Konzept auszuarbeiten, das nicht nur Datenbankaspekte, sondern auch Netzwerke, Data-Center, Informations-Architekturen und Projekt- Management beruecksichtigt.

Ein Datenbanksystem allein kann jedoch nicht in jedem Fall alle Benutzeranforderungen abdekken. Daher spielen auch im Unix-Umfeld Transaktionsmonitore eine immer wichtigere Rolle.

Aufgrund der staendigen Erweiterungen in bezug auf Verfuegbarkeit und der in Produktionssystemen geforderten Funktionalitaet ist Unix im kommerziellen Bereich immer haeufiger anzutreffen. Auch gibt es schon seit einiger Zeit Unix-Systeme, welche den Anforderungen eines professionellen Data-Centers genuegen. Nach Angaben des Marktforschungsinstituts IDC haben etwa 50 Prozent der Benutzer, die daran denken, ihre Applikationen auf eine andere Plattform zu bringen, Unix in die engere Wahl genommen.

Viele kommerzielle Unix-Anwendungen nutzen heute relationale Datenbanken und erreichen akzeptable Multi-User-Performance auch ohne einen TP-Monitor. Dennoch wird die Nachfrage nach effizienten "Unix Transaction Monitors" staerker werden. Beispielsweise lassen sich dadurch auch die entsprechenden Unix-File-Systeme fuer die OLTP-Anwendung nutzen.

Schon jetzt ist eine steigende Tendenz zu erkennen. "Light TP" ist dabei ein von manchen Herstellern benutztes Stichwort. Es soll verdeutlichen, dass sich kleinere bis mittlere Applikationen, die nicht unbedingt als mission critical gelten, auch auf flexibleren Plattformen wie Workstation- und Server-LANs implementieren lassen.

Generell kann man zwischen zwei Gruppen von Unix-TP-Monitoren unterscheiden: solchen, die ein kompatibles CICS Command Level Interface haben, und solchen mit einer typischen Unix-Programmier- Schnittstelle. Zur ersten Gruppe gehoeren VIS/TP, Unikix und CICS/6000 (X/CICS); zur zweiten zaehlen Tuxedo, Topend und Encina.

Beim Erstellen von Applikationen auf anderen Systemen wird man meist an der gewohnten Benutzer- oder Entwickleroberflaeche festhalten wollen. Denn es waere zu kosten- und zeitaufwendig, das Ganze voellig neu zu schreiben und die Programmierer umzuschulen.

Auch hier bieten diverse Hersteller Produkte, die einen derartigen Umstieg erleichtern. Aber auch dabei gilt: Ohne ein umfassendes Konzept sowie professionelle Projektdurchfuehrung geht nichts zusammen.

In diesen Faellen muss ein Team, das bei der Einfuehrung einer Client-Server-Loesung etwa die CICS-Mainframe-Welt mit offenen OLTP-Anwendungen verbinden soll, aus Spezialisten bestehen, die nicht nur beide Welten kennen, sondern auch Beratung und Design fuer die neue Architektur kunden- und marktorientiert durchfuehren koennen. Dabei besteht die Kunst darin, das richtige System zu waehlen, um zukunftsorientiert investieren zu koennen.

Zurueck zum Bereich Datenbanken. Dort gibt es Projekte, die besondere Aufmerksamkeit verdienen: die SQL Access Group und die Distributed Relational Database Architecture von IBM.

IBMs DRDA laesst sich als Architektur innerhalb von SAA ansehen, die zunaechst den Zugriff auf verteilte relationale Daten der IBM-Welt beschreibt. Aber es wird auch Support fuer andere Systeme angeboten. Das SQL-Access-Konsortium befasst sich mit der Definition eines Anwendungsprogrammierungs-Interfaces (API) fuer SQL und einer Spezifikation von Formaten und Protokollen (FAP). Der wesentliche Unterschied zu DRDA ist dabei, dass SQL-Access auf existierenden Standards aufbaut, die X/Open veroeffentlicht.

Das bedingt fuer die Auswahl eines DB-Systems vier Anforderungen: Die Datenbanksysteme muessen erstens hinsichtlich Standards, Interfaces, Performance etc. dem neuesten Stand der Technik entsprechen. Zweitens muessen die strategischen Ausrichtungen beispielsweise bezueglich DRDA oder SQL-Access stimmen. Entwicklungswerkzeuge, Benutzeroberflaechen und Bedienbarkeit haben drittens "state of the art" zu sein. Und viertens sind die richtigen Plattformen zu unterstuetzen.

Auf der funktionalen Ebene erfuellen den ersten Punkt heute fast alle namhaften DB-Hersteller. Direkte technische Vergleiche wie etwa Benchmarks bringen meist keinen unmittelbaren Vorteil, da die Realitaet beim Anwender meist nicht den Benchmark-Konfigurationen entspricht.

Benchmarks haben nur Unterhaltungswert

Die Erfahrung zeigt, dass im Einzelfall nur massgeschneiderte Benchmarks - mit den Programmen des Anwenders, auf der Hardware des Anwenders - nuetzlich sind. Wer eine Single-Processor-Umgebung ohne TP-Monitor faehrt, hat nichts von einem Benchmark-Ergebnis, das auf verschiedenen CPUs unter Ausnutzung der erlaubten Schliche und Tricks zustande gekommen ist.

Hersteller, die die im Punkt zwei genannten Architekturen unterstuetzen, sind laengerfristig wahrscheinlich auf der sicheren Seite, da sie dem Verlangen der Anwender nach Interoperabilitaet entsprechen. Die meisten Unterschiede sind wohl in den Punkten drei und vier zu finden.

Schliesslich wird es fuer die Hersteller von Bedeutung sein, welche Plattformen (Betriebssysteme) sie in der Zukunft unterstuetzen. Unix ist dabei nur eine Variante, Windows NT eine andere. Wer diesen Zug nicht verpassen will, muss rechtzeitig Portierungen auf NT ankuendigen.

Aber auch die Auswahl der richtigen Software ist noch kein Garant fuer die erfolgreiche Durchfuehrung eines Client-Server-Projekts. Sowohl die klassischen Mainframer als auch die "Gipfelstuermer", die den "Rest der Welt" repraesentieren, haben dazugelernt. Auf die Erfahrung der einen sollte und kann nicht verzichtet werden, ebensowenig auf die Innovationsfaehigkeit und Dynamik der anderen. Wer beide Welten verbinden kann, hat fuer die Zukunft gute Chancen.