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.

13.04.2001 - 

Kapselung von Schnittstellen

Host-Integration mit Bordmitteln meistern

MÜNCHEN (CW) - 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 nichts verändern wollen, suchen andere in der Neuentwicklung ihr Heil. Dabei ließen sich aber durch bisher zu wenig beachtete Kapselungsmechanismen die alte und neue Welt schonender verbinden. Von Harry Sneed*

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.

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. 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. Ein Reengineering dieser Programme ist deshalb meist unvermeidlich.

Dialoglogik verlagernBei 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ützenLetztere ruft 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 erneuernIst 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.

KapselungstechnikWas 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 ZukunftDie Kapselung der Daten-Schnittstelle wird bei asynchronen Verbindungen gewählt. Das Client-Programm kann so einen Auftrag absetzen und sich zwischendurch mit etwas anderem 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. 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 CGIDie 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 ( Call "Cgiwrite" Using by Content " ", Zeile, , X"OO"). 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. Allerdings ist dies für manche einfache abteilungsspezifische Anwendungen genau das Richtige.

IBM-ProdukteEine 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 den Weg in Richtung offene Systeme. Dieser Ansatz sollte deshalb nur eine Übergangslösung sein.

*Harry Sneed ist Software-Engineering-Spezialist und beratend für den Wiesbadener IT-Dienstleister Case Consult tätig

Abb: Cobol-XML-Internet-Anbindung

Bei der Integration von Cobol-Anwendungen über die Daten-Schnittstelle versprechen das Wrapping und die Konvertierung in XML-Dokumente die flexibelste Lösung. Die Grafik zeigt eine Implementierung, die mit Hilfe des Host-Tools "XML4 Cobol" der Firma Maas Hightech aus Stuttgart realisiert wurde. Quelle: Sneed