MÜNCHEN (COMPUTERWOCHE) - Geht es um die Integration bestehender Host-Systeme in eine neue Internet-Architektur, stoßen die Extreme aufeinander. Während manche Anwender am liebsten gar nichts verändern wollen, suchen andere in der Neuentwicklung ihr Heil. Laut Harry Sneed* ließen sich aber durch bisher zu wenig beachtete Kapselungsmechanismen die alte und neue Welt schonender verbinden.
In den letzten zehn Jahren hat sich die Benutzeroberfläche von festen Masken auf einem 3270-Terminal über Windows-basierte GUIs bis hin zu Multimedia-Web-Seiten mit Bildern und Animationen gemausert. In den nächsten Jahren ist mit weiteren Fortschritten in Richtung WAP und Spracheingabe zu rechnen. Das Ende der Frontend-Entwicklung ist also nicht abzusehen. Beim Backend hingegen sieht es anders aus. Hier basiert die überwiegende Mehrzahl der Anwendungssysteme nach wie vor auf einer relationalen Datenbank, und es wird immer noch weitgehend mit SQL-Anweisungen auf die Daten zugegriffen. Ob in Native SQL, ODBC oder JDBC - die Zugriffstechnik ist überall gleich, sprich die Datenseite bleibt relativ stabil. Dies muss auch so sein, da die Daten das größte Gut eines Unternehmens sind und für alle Anwendungen jeder Zeit verfügbar bleiben müssen. Sie dürfen sich nicht verändern, zumindest was ihre Struktur und Semantik anbetrifft.
Zwischen den Benutzeroberflächen vorn und den Datenbanken hinten, befindet sich eine mehr oder weniger dünne Schicht von Verarbeitungsregeln (Geschäftslogik). Bei manchen Anwendungen besteht diese Logik aus einigen wenigen Plausibilitätsprüfungen, bei anderen aus mehrfach verschachtelten Schleifen. Zum Teil wird nur auf eine, zum Teil auf mehrere Datenbanken zugegriffen. Die Komplexität dieser Verarbeitungsschicht ist also sehr unterschiedlicher Natur. Wesentlich ist, dass sich diese Ebene technologisch nur geringfügig ändert. Zwar sind aus den strukturierten Modellen der 80er Jahre die objektorientierten Klassen der 90er Jahre geworden und aus diesen wiederum werden jetzt Komponenten. Der Inhalt dieser Verpackungseinheiten bleibt jedoch gleich: Datendeklarationen, Befehlssequenzen, Auswahlstrukturen und Schleifen. Ob in Cobol, C++ oder Java - die Grundlogik ist gleich, auch wenn die Syntax anders ist.
Wenn der Anwender seine Systeme nun nicht alle fünf Jahre komplett neu erstellen will, um mit dem Fortschritt der Präsentationstechnik Schritt zu halten, muss er die Oberflächentechnik von der langsameren Datenbank- und Verarbeitungstechnik entkoppeln. In den wenigsten alten Host-Anwendungen sind aber die drei Schichten voneinander getrennt, sondern vor allem in CICS, IMS und IDMS eng miteinander verzahnt. Makros für die Maskenverarbeitung, Datenzugriffsoperationen und Verarbeitungsanweisungen wurden leider in der Reihenfolge ihrer sachlogischen Ausführung und nicht nach softwaretechnischen Kriterien geordnet. Die Folge sind Anwendungs-Monolithen, die nur in ihrer Urumgebung funktionieren können. Ein Reengineering dieser Programme ist deshalb meist unvermeidlich.
Dialoglogik verlagern
Bei Cobol-Anwendungen muss im ersten Schritt die Dialoglogik in ein übergeordnetes Steuerungsmodul verlagert werden. Das bedeutet das Herausschneiden der TP-Makros und ihre Zusammenfassung in einer eigenen Cobol-Sektion. Im ursprünglichen Code werden sie durch Labels ersetzt, von den Steuerungsmodulen aus werden die Verarbeitungsschritte mittels "Perform"-Anweisung aufgerufen. Anschließend werden die Datenbankzugriffe in ein separates Zugriffsmodul am Ende des Programmes versetzt. Auch hier geht es darum, die DL/I-, SQL- oder DML-Makroanweisungen herauszuschneiden und als separate Paragraphen in die Zugriffssektion einzufügen. In dem ursprünglichen Code werden sie durch Performs ersetzt. Jetzt ist der verarbeitende Code frei von TP- und Datenbankoperationen. Erstere sind nach oben, letztere nach unten versetzt, so dass es jetzt zwei neue "Cobol-Sections" gibt: eine Dialogsteuerungs- und eine Datenbankzugriffssektion. Dazwischen bleiben mehrere Verarbeitungsblöcke.
Dialogsteuerung schützen
Letztere rufen die Dialogsteuerung auf, während sie selbst die Datenbankzugriffe initiieren. Dabei müssen die "Go-to"-Anweisungen entfernt werden, damit sie nicht der Dialogsteuerung in die Quere kommen. Es darf nicht vorkommen, dass von einer TP-Operation aus an einen bestimmten Verarbeitungsblock per Go to verzweigt wird, sondern der Aufruf von Verarbeitungsblöcken darf nur per Perform erfolgen. Ebenso ist zu verhindern, dass über Dialogintervalle hinaus verzweigt wird, da dies die zentrale Steuerungslogik unterwandert.
Präsentationsschicht erneuern
Ist ein Austausch der Präsentationsschicht geplant, so lässt diese sich dank der beschriebenen Maßnahmen relativ leicht isolieren und die bisherige Dialogsteuerung durch eine einfache Parametersteuerung ersetzen. Letztere entscheidet dann, welche Verarbeitungsblöcke in welcher Reihenfolge auszuführen sind. Ist eine Wiederverwendung der bisherigen Verarbeitungsschicht geplant, dann müssen die Parameter über Kapselungstechnik bereitgestellt werden. Möchte der Anwender nur die Zugriffsschicht wiederverwenden, vor allem wenn Datenbankzugriffe mehrerer alter Programme in einem Zugriffsmodul zusammengefasst werden sollen, dann regelt die Parametersteuerung die einzelnen Operationen direkt über die Verarbeitung.
Kapselungstechnik
Was dann übrig bleibt, ist die Parameterübergabe, und die ist, wie erwähnt, eine Frage der Kapselungstechnik. Diese lässt sich bei der Funktions-, der Daten- oder der Gateway-Schnittstelle einsetzen. Die Funktions-Schnittstelle wird dabei bei synchronen Verbindungen verwendet, das heißt, wenn das Client-Programm auf eine Antwort des Servers wartet, um weiterzuarbeiten. Der Aufrufer kennt den Namen des Moduls, welches er auf dem Server aufrufen will, und weiß außerdem genau, wie seine Parameter auszusehen haben. Ein typischer Vertreter dieser Art entfernter Prozeduraufrufe ist die Remote Method Invocation in Java beziehungsweise die dynamische Verbindung in Corba. Die Middleware überträgt den Funktionsaufruf vom Client an den Server und übergibt dem Server-Modul die entsprechenden Parameter. Da die Datentypen zwischen Java und Cobol unverträglich sind, muss eine Umsetzung stattfinden. Dies wäre die Aufgabe des Object Request Brokers - allerdings ist dies nur für eine beschränkte Anzahl Parameter gedacht. Der Vorteil der funktionalen Schnittstelle ist, dass sich einzelne Cobol-Sections mit eigener Entry-Anweisung vom Client direkt aufrufen lassen. Das größte Hindernis vor dieser Art funktionaler, synchroner Verbindung war bisher die Performance der Middleware, da nur Message-Routing-Produkte tatsächlich größere Datenströme in einer annehmbaren Zeit bewältigen können.
XML ist die Zukunft
Die Kapselung der Daten-Schnittstelle wird bei asynchronen Verbindungen gewählt. Das Client-Programm kann so einen Auftrag absetzen und sich zwischendurch mit etwas anderen beschäftigen. Größere Datenstrukturen können dadurch über die Leitung an den Server übertragen werden. Dort werden die Datennachrichten als Cobol-Linkage-Strukturen aufbereitet, das entsprechende Cobol-Programm aufgerufen und aus dem Ausgabeparameter des Programms eine Rückgabenachricht für den Auftraggeber erzeugt und gesendet (siehe Grafik "Cobol-XML-Internet-Anbindung"). Der Vorteil der Daten-Schnittstelle ist, dass der Client nichts mehr über das Server-Programm wissen muss. Die beiden Parteien - Auftraggeber und Auftragnehmer - sind völlig voneinander entkoppelt. Nachteilig ist, dass jede Nachricht interpretiert werden muss und dadurch kostbare Laufzeit verloren geht. Außerdem ist für die Umsetzung ein Wrapper nötig. Bei Corba werden die Cobol-Parameter von dem jeweiligen Object Request Broker (ORB) bedient.
Trotzdem zeichnet sich ab, dass die Daten-Schnittstelle der bevorzugte Verbindungsmechanismus für die Host-Integration wird. Dies liegt vor allem im wachsenden Einsatz der universalen Datenaustauschsprache XML und dem Versprechen begründet, die einzelnen Komponenten voneinander entkoppeln zu können. Die Bausteine müssen nur noch von den anderen wissen, welche Dateneingaben sie brauchen und welche Ergebnisse sie liefern. Wichtig ist auch, dass nicht das Client-Programm, sondern Online-TP-Member entscheidet, wann und wo die beauftragte Komponente ausgeführt wird. Dadurch ist ein besserer Lastenausgleich möglich.
Anbindung über CGI
Die CGI oder Common-Gateway-Schnittstelle ist die dritte Möglichkeit, das Cobol-Programm direkt mit dem Internet kommunizieren zu lassen. Mit ihr werden HTML-Seiten von dem Programm empfangen und gesendet. Dazu werden die Call-Anweisungen "Cgiread" und "Cgiwrite" verwendet. Erste holt die Daten aus dem HTML-Format und stellt sie als Parameter im Call by Value zur Verfügung (Call "Cgiread" Using P1, P2, P3 ... Pn. ) Cgiwrite überträgt die Parameter dann als Zeilen in das HTML-Ausgabeformat. Fujitsu beispielsweise bietet in seinem Cobol-Compiler CGI-Support an, wodurch der Cobol-Programmierer mit Web-Seiten so umgehen kann, wie er es bisher mit "Accept"- und "Display"-Meldungen tat. Er muss nur die Dialogsteuerungssektion im alten Programm umschreiben.
Der Vorteil der CGI-Schnittstelle ist die Tatsache, dass weder Client noch Wrapper nötig sind. Vielmehr ist das Cobol-Programm zugleich Client und Server. Das ist aber gleichzeitig der Nachteil, denn damit sind wir wieder bei der flachen, einschichtigen Architektur angelangt, wo Benutzeroberfläche, Verarbeitungslogik und Datenzugriffslogik in einem monolithischen Programm versammelt sind. Allerdings ist dies für manche einfache abteilungsspezifische Anwendungen genau das Richtige.
IBM-Produkte
Eine andere Möglichkeit zur Anbindung der Host-Programme bieten die Standard-Gateway-Produkte der IBM. Für IMS/DC-Programme bietet der Hersteller das "IMS Webstudio" an, das MFS-Masken durch HTML-Seiten emuliert. Für CICS-Programme ist das "CICS Internet Gateway" erhältlich, mit dem BMS-Masken emuliert werden. In beiden Fällen werden die Programme nicht verändert, aber nur insofern als auch die PF-Tasten emuliert werden. Alles andere erledigt der TP-Monitor. Zudem sind entsprechende Tools jetzt in IBMs Applikations-Server "Websphere" integriert.
Solche Lösungen sind schnell und billig, aber es tut sich eine weitere proprietäre Falle auf. Die Programme bleiben CICS- und IMS-Anwendungen und verbauen damit den Weg in Richtung offene Systeme. Dieser Ansatz sollte deshalb nur eine Übergangslösung sein.
FAZIT DES AUTORS:
"Leider werden in Deutschland die seit langem geläufigen Alternativen zur Anbindung alter Host-Programme ans Internet bisher kaum genutzt. Vielmehr bleiben Anwender in der Praxis entweder in ihrer vertrauten Umgebung stecken, oder sie ergreifen die Flucht nach vorne und wollen alles komplett neu entwickeln - von der Benutzeroberfläche bis zur Datenhaltung. Den hier vorgeschlagenen Mittelweg, der Altes mit Neuem verbindet, sehen sie nicht. Dies liegt vor allem an den mangelnden Kenntnissen der Anwender über die Verbindungsmechanismen. Zum anderen lassen sie sich durch die Propaganda über .NET, Sun One, Websphere und EAI verunsichern und verwirren."
*Harry Sneed ist Software-Engineering-Spezialist und beratend für den Wiesbadener IT-Dienstleister Case Consult tätig.