Mit der zunehmenden Vernetzung unterschiedlicher Verarbeitungsrechner bekommt auch die Kopplung der darauf installierten DB/DC-Software immer mehr Gewicht. Die Bedeutung von Schlagworten wie Dezentralisierung, Filialkonzept. Lastverbund und Erhöhung der Verfügbarkeit wurde in der Vergangenheit erkannt und hinreichend diskutiert.

Ein wesentlicher Gesichtspunkt bei der ganzen Verteilungsthematik fällt dabei oft unter den Tisch: Die wachsende Heterogenität der installierten Software. Es kommt immer häufiger vor, daß in ein und demselben Rechenzentrum ganz unterschiedliche DB/DC-Systeme nebeneinanderstehen, die jetzt kooperieren sollen.

Im "einfachsten" Fall finden wir zwei DB-Systeme unterschiedlichen Typs vor, die in einer gemeinsamen Dialoganwendung zusammenwirken sollen; oft geht es sogar darum, Anwendungen miteinander zu koppeln deren Environments nicht nur im DB/DC-System, sondern auch im Betriebssystem und in der Hardware jeweils gänzlich anders aussehen. Daß heute viele DV-Anwender Siemens BS2000- und gleichzeitig IBM/PCM-Anlagen installiert haben, ist sicherlich ein Indiz dafür.

Wie kann man sich nun die Kooperation zweier DB/DC-Systeme vorstellen? Beispiel: Ein Bankkunde möchte zu Hause bei seiner Bank Geld abheben. Dabei haben wir folgendes vereinfachte Modell vor Augen: Von einem Datenbanksystem werden sowohl die Konten der Kunden als auch die Auszahlungskasse verwaltet. Nach einer vorangehenden Bonitätsprüfung werden Kontostand des Kunden und Kassenstand der Bank um den gewünschten Geldbetrag

vermindert - alles zusammen innerhalb einer Transaktionsklammer.

Datenkonsistenz hat Vorrang

Denn falls die Transaktion aus irgendwelchen Gründen nicht erfolgreich zu Ende geführt werden konnte (etwa in der Situation "Kontostandänderung durchgeführt, aber zur Zeit keine Auszahlung möglich"), müssen alle von der Transaktion betroffenen Daten automatisch wieder in den alten (konsistenten) Zustand gebracht werden. Nur wenn der gewünschte Konsistenzzustand erreicht ist, werden die Veränderungen festgeschrieben und der Geldbetrag kann ausbezahlt werden, Eine Transaktion "Geldabheben" könnte also etwa so ablaufen:

- Eingabe prüfen

- Kontostand abfragen

- vom Konto abbuchen.

- Geld aus Kasse abbuchen.

Anders wird es, wenn der Kunde Geld am Urlaubsort (zum Beispiel München) bei einer dortigen Filiale seiner Bank abheben will, wobei sein Konto am Heimatort (zum Beispiel Berlin) von der Datenbank der dortigen Niederlassung verwaltet wird. Es soll also eine Transaktion "Geldabheben im Urlaub"angestoßen werden, welche ganz entsprechend der Transaktion "Geldabhebene" abläuft.

Dabei werden die Eingabeprüfung und das Abbuchen aus der Kasse lokal in München, die Datenbankzugriffe auf das am Heimatort Berlin befindliche Konto (Abfragen, Abbuchen) vom entfernten DB/DC-System abgewickelt, einschließlich der vorher beschriebenen, jetzt aber rechnerübergreifenden Transaktionssicherung. Und das ist entscheidend. Dabei können in den betroffenen Filialen durchaus unterschiedliche DB/DC-Systeme in unterschiedlicher Betriebssystem- und Hardwareumgebung eingesetzt werden. Auch in diesem Fall muß ein transaktionsgesicherter Anwendungs-Anwendungsverkehr gewährleistet sein.

Sollen zwei DB/DC-Systeme miteinander kooperieren, so stellt sich als erstes die Frage, wo die Verarbeitung der verteilten Datenbestände erfolgen soll. Prinzipiell gibt es dafür zwei Vorgehensweisen:

- Transport der Daten zum Ort der Verarbeitungsleistung unter Steuerung der beteiligten DB-Systeme.

- Transport der Verarbeitungsleistung zum Ort der Daten unter Steuerung der beteiligten DC-Systeme (TP-Monitore).

Im ersten Fall sprechen wir von VDB (Verteilte Datenbanken), im zweiten Fall von VTV (Verteilte Transaktionsverarbeitung). Im Fall verteilter Datenbanken arbeiten die Anwendungsprogramme lokal in dem Verarbeitungsrechner, an den sich der Endbenutzer angeschlossen hat ("lokale Verarbeitung"). Die eigentlichen Kommunikationspartner im Netz sind aber die jeweiligen DB-Systeme. Diese koordinieren die Zugriffe auf die verteilten Datenbanken, wobei die Anwendungsprogramme bei der Bearbeitung eines Transaktionsauftrags auf die im gesamten Rechnernetz verteilten Daten so zugreifen können, als ob diese lokal gespeichert wären.

Der Ort der Daten ist also nicht nur für den Endbenutzer, sondern auch für das Anwendungsprogramm vollkommen irrelevant. Die Verteilungskomponente des lokalen DB-Systems analysiert den Datenbankaufruf und leitet ihn eigenständig an das richtige DB-System - entweder an das lokale, oder durch das DFÜ-Netz an das entsprechende im entfernten Rechner. Im Netz transportiert werden jeweils Datenbankaufträge (DML-Anweisungen) und die dazugehörigen Ergebnisse, die dann wieder ausschließlich lokal verarbeitet werden.

Die heute im Einsatz befindlichen Siemens-Datenbanksysteme UDS und Sesa realisieren mit den Zusatzprodukten UDS-D beziehungsweise Sesam-DCM als Verteilungsinstanzen diese Kooperationsform. Da der Ort der verteilten Datenbanksysteme für die Anwendungsprogramme völlig unsichtbar bleibt, können alle heutigen Programme (auch Batchprogramme), die auf mehrere Datenbanken zugreifen, unverändert übernommen werden, auch wenn diese jetzt auf mehrere Rechner verteilt sind. Solange keine Standards für die Kooperation unterschiedlicher DB-Systeme festgelegt sind, ist diese Verteilungsform nur in homogenen DBMS-Netzen möglich. Für die Kopplung heterogener DB/DC-Systeme kommt heute nur die verteilte Transaktionsverarbeitung in Frage.

Hier arbeiten die entfernten Anwendungsprogramme mittels ihrer TP-Monitore global miteinander zusammen ("verteilte Verarbeitung"), während die Datenbankzugriffe selbst jeweils lokal erfolgen. Hier werden also nur Verarbeitungsaufträge und -ergebnisse über die Leitung geschickt, unabhängig davon, wieviele Datenbankzugriffe zur Abarbeitung des Auftrags benötigt werden.

Zugriff erfolgt transparent

Aus der Sicht des Terminalbenutzers läuft eine verteilte Transaktion genauso ab wie eine lokale Transaktion. Die Anwendungsteilprogramme jedoch müssen die Verteilung berücksichtigen. Eine Terminaleingabe wird von der Nachrichtensteuerung des TP-Monitors zunächst immer an ein Programm der lokalen Anwendung geleitet. Wenn dieses Programm feststellt, daß zur Bearbeitung Leistungen einer entfernten Anwendung gebraucht werden, schickt es (durch einen Funktionsaufruf an die Verteilkomponente des Monitors) eine Nachricht dorthin und startet damit dort einen neuen Vorgang. Im Dialog miteinander bearbeiten dann der lokale und der entfernte Vorgang die Terminalnachricht.

Ein Transaktionssystem, welches die VTV ermöglicht, muß dabei vor allem folgenden Anforderungen Rechnung tragen:

- für eine Transaktion Sessions zu verschiedenen Kooperationspartnern erlauben,

- für viele Transaktionen unabhängige parallele Sessions zu anderen Kooperationspartnern ermöglichen

- die Betriebsmittel transaktionsspezifisch verwalten und dabei system- beziehungsweise rechnerübergreifende Deadlocks erkennen,

- Zugriffsrechte und Nutzungsrechte so vergeben, daß sich jeder Rechner vor dem Mißbrauch seiner Betriebsmittel durch Auftraggeber in anderen Rechnern schützen kann,

- eine Entkopplung der Adressierung von netzweit verfügbaren Objekten (Autonomie der lokalen Namensgebung),

- für die im Netz verteilten Objekte Administrationsfunktionen zur Verfügung stellen.

Durch die Aufteilung der kooperierenden Systeme auf mehrere Rechner müssen zusätzliche neue Fehlersituationen behandelt werden (zum Beispiel Nachrichtenverlust im Netz, kurz- oder langdauernde Ausfälle eines oder mehrerer Partnersysteme bei gleichzeitiger Betriebsbereitschaft der anderen Systeme). Resynchronisation von laufenden Systemen nach Fehlern und im Wiederanlauf nach Systemausfall ist das prinzipiell zu lösende Problem.

Resynchronisation ist Zentralproblem

Das geschilderte Kooperationsprinzip ist mit der heute im Einsatz befindlichen Version 3.0 des "Universellen Transaktionsmonitors" UTM von Siemens durch die Zusatzkomponente UTM-D realisiert. Nachdem bei der verteilten Transaktionsverarbeitung ein Unterauftrag an eine entfernte Anwendung dort in Form von Transaktionen abgewickelt wird, liegen "geschachtelte" Transaktionen mit der Notwendigkeit von Synchronisationsmaßnahmen vor. Dabei sind folgende Fälle von Interesse:

- Mit dem Dialogschritt, an dessen Ende ein Unterauftrag an die entfernte Anwendung übertragen wird, soll auch die lokale Transaktion beendet werden. Dann wird verlangt, daß der Auftragnehmervorgang beim Rücksenden der Ergebnisnachricht ebenfalls seine Transaktion beendet, und UTM verzögert das lokale Transaktionsende bis zum Ende der entfernten Transaktion.

- Nicht der lokale Vorgang beim Übersenden einer Auftragsnachricht, sondern der entfernte Auftragnehmervorgang beim Abschicken einer Ergebnisnachricht möchte seine Transaktion abschließen. Dann wird das entfernte Transaktionsende durch UTM bis zum nächsten lokalen Transaktionsende verzögert.

Die kooperierenden Anwendungsvorgänge müssen also bestimmten Programmierregeln genügen: Wenn einer der Dialogpartner seine Transaktion beenden möchte, muß ihm der andere Gelegenheit dazu geben, indem er ebenfalls seine Transaktion abschließt. UTM synchronisiert die entfernten Transaktionsenden dann implizit, das heißt ohne daß dafür in den Programmen eigene Aufrufe notwendig sind, wie dies auch bei der Synchronisation mit DB-Transaktionen geschieht. Deshalb erfährt die Programmierschnittstelle nur geringfügige und aufwärtskompatible Erweiterungen (Adressierung der entfernten Anwendung und des entsprechenden Transaktionscodes).

Entscheidend für die Fähigkeit von UTM zur heterogenen Kommunikation ist folgendes: für die Basis-Kommunikationsfunktionen werden zwar die Protokolle der Ebenen 1 bis 4 des Datenkommunikationssystems Transdate herangezogen, die im BS2000-Verarbeitungsrechner durch das Produkt Basic Communications

Acces Method (BCAM) abgewickelt werden; als Session-Protokoll wird jedoch das SNA-Protokoll vom Typ LUG6 der IBM, das heißt das Protokoll zur Kooperation von logical units vom Typ 6, verwendet.

Zusammen mit dem Protokoll-Konverter Transit-CD zwischen den Protokollen der Ebenen 1 bis 4 der Kommunikationssysteme Transdata und SNA ergeben sich damit für den UTM-Nutzer die Möglichkeiten verteilter Transaktionsverarbeitung in homogenen und heterogenen Rechnernetzen mit unterschiedlichen DB-Systemen und TP-Monitoren.

Aus Sicht von Transdata stellt sich das SNA-Netz (die angeschlossenen SNA-Domänen) wie eine Erweiterung des Transdata-Netzes um weitere Transdata-Prozessoren dar und umgekehrt. Ein von einer UTM-Datensichtstation gestarteter Dialogvorgang läßt sich somit - unsichtbar für den Terminalbenutzer - beispielsweise zu einem Dialog UTM-CICS fortsetzen. Auch der umgekehrte Fall ist möglich: Beispielsweise kann eine IDNS/DC-Anwendung ins transaktionsgesicherter Programm-Programm-Kommunikation

Unteraufträge von einer UTM-Anwendung abwickeln lassen. Im Hinblick auf die IDNS-Kopplung wurde für die VTV in UTM das LUG-I-Protokoll implementiert.

*Dr. Hans von Koch, Unternehmensbereich Kommunikations- und Datentechnik, Siemens AG, München.