Emulation im Browser effektiver als HTML

Web-Zugriff auf den Host erfordert genaue Planung

21.11.1997

Nahezu 90 Prozent aller Großunternehmen und 54 Prozent aller Mittelständler haben bereits ein Intranet oder sind dabei, eines zu implementieren. Zu diesem Ergebnis kommt das Marktforschungsunternehmen IDC in einer seiner Studien. Außerdem verwenden laut Meta Group über 80 Prozent der Mainframe-Anwender das Internet oder Intranet auch für den Zugriff auf ihre S/390-Systeme oder planen, dies zu tun.

Bisher ersetzten Mainframe-Anwender ihre Terminals durch Windows-PCs, die mit einer entsprechenden Emulationssoftware ausgerüstet waren. Doch die Zeiten haben sich geändert. Heute propagieren die DV-Verantwortlichen den Host-Zugriff per Web-Browser. "Für die Unternehmen ist nicht der Kaufpreis das Problem, sondern die Tatsache, daß Emulationssoftware auf jedem Client installiert werden muß", erklärt William Griebel, Systemingenieur beim Systemhaus Wick Hill. Durch die Web-to-Host-Integration ist keine zusätzliche Software auf dem Desktop erforderlich, die zu warten wäre.

Dies war auch für die Möbel Walther AG der Grund, auf Web-Technik umzusteigen. Durch eine Firmenübernahme standen die DV-Verantwortlichen vor der Aufgabe, den Mitarbeitern gleichzeitig den Zugriff auf Unix- und auf AS/400-Rechner zu ermöglichen. Dietmar Herrmann, DV-Manager beim Möbelhersteller, hat schon einige Erfahrung mit Terminalemulationen für Unix-Systeme. Besonders die aufwendige Konfiguration am jeweiligen Arbeitsplatz störte den IT-Experten. Da nun jeder User Zugriff auf zwei vorhandene Host-Systeme benötigt, kam eine Web-Lösung mit zentraler Konfigurationsverwaltung gerade recht. Dieses Projekt ist ein Teil des im Aufbau befindlichen Intranet bei Möbel Walther. So werden die Mitarbeiter mit Informationen, wie Dokumentationen für die Qualitätssicherung oder einem Richtliniensystem, versorgt.

Bei dem Möbelhersteller testet man eine Vorabversion der Web-to-Host-Lösung "Esker Tune" des Essener Softwarehauses Esker. Über ei- nen NT-Server laden die Clients eine in Active X implementierte Terminalemulation. Herrmann schätzt dabei vor allem die Möglichkeit der zentralen Konfiguration. Auf dem Desktop muß der Browser installiert und die entsprechende Homepage eingestellt werden.

Außerdem modifizieren die Systemverwalter die Konfiguration des Browsers, denn nach den Worten von Herrmann benötigen die Anwender keine Buttons für das Suchen im Internet.

Statt einer von einem Server heruntergeladenen Terminalemulation hätte sich die Firma auch für eine Middleware-Lösung entscheiden können. Dabei wandelt ein dem Mainframe vorgeschalteter Rechner die Host-Daten in HTML-Seiten um, die dann zu den Web-Clients gelangen. Zwischen Middleware-System und Mainframe läuft eine Terminalsitzung, zum Beispiel TN3270 oder SNI 97801. Diese relativ einfache und weit verbreitete Lösung hat jedoch Nachteile.

Die Synchronität zum Host wird unterbrochen

Protokolle wie HTTP wurden für das Versenden von HTML-Dokumenten entwickelt und nicht für transaktionsintensive Anwendungen. Dadurch wird die "Liveschaltung" zum Großrechner unterbrochen. Dies hat Konsequenzen: Die normalerweise zwischen Endanwender und Großrechneranwendung existierende Synchronität wird unterbrochen, was insbesondere bei Systemmeldungen und Popup-Nachrichten ungünstig ist, meint Wick-Hill-Ingenieur Griebel. Durch eine Umwandlung der Host-Daten auf einem Server gehen ferner die für Emulationen so wichtigen Keyboard-Mappings (die Anpassung der PC- an die Großrechnertastatur) verloren, weiß Rainer Stecken, Systemingenieur bei Esker, zu berichten. Wall Data, ein weiterer Hersteller von PC-Host-Connectivity, bietet für sein "Arpeggio Live" bisher nur ein Standard-Mapping an. Da dies offenbar die Kunden nicht immer zufriedenstellte, arbeiten die Entwickler an zusätzlichen Funktionen.

Im Gegensatz dazu bleiben diese Merkmale bei Programmen erhalten, die, wie im ersten Verfahren beschrieben, über Java oder Active X eine komplette Terminalemulation von einem Web-Server in den Browser laden. Statt über das langsame und anfällige HTTP kommuniziert der Desktop-Rechner direkt mit dem Host, beispielsweise über TN3270.

Dagegen erweist sich auch in puncto Performance ein Middleware-Server als problematisch. Er verursacht einen Flaschenhals, da alle Web-Clients die Host-Daten über diesen Rechner beziehen. Je mehr Anwender am Großrechner hängen, desto schwieriger ist die Middleware-Lösung aufrecht zu erhalten.

Zu diesem Ergebnis kam auch Georg Voell, Berater bei der Unternehmensberatung Polymedia in Bonn, als er für einen großen Kunden Web-to-Host-Softwareprodukte testete. Von den über 50 am Markt befindlichen Produkten wurden 25 begutachtet, davon kamen schließlich vier in die engere Wahl. Schnell stellte sich heraus, daß die Middleware-Lösungen nicht leistungsstark genug waren.

In dem Pilotprojekt erhielten 2000 Benutzer einen Web-Zugriff zum Host. Anfang nächsten Jahres sollen 10000 Anwender auf diese Weise mit dem Mainframe kommunizieren. Dabei verwenden die Benutzer rund 2000 Masken. Voell bilanziert seine Untersuchungsergebnisse folgendermaßen: "Bei einem Middleware-System auf Basis von Windows NT 3.51 können maximal 200 Benutzer gleichzeitig auf einen Host zugreifen. Bei 10000 Usern wären dann 50 Server erforderlich, und das ist natürlich unwirtschaftlich."

Nicht wesentlich besser fallen die Werte bei einem mit NT 4.0 ausgestatteten Rechner aus. Erst mit einer Unix-Middleware, so Voell, ließe sich aufgrund höherer Skalierbarkeit ein besseres Ergebnis erzielen. Geeigneter seien bei der konkreten Aufgabenstellung Produkte, die ein Emulationsprogramm von einem Web-Server laden und dann direkt per TN3270 auf den Großrechner zugreifen.

Wann sollte ein Unternehmen sich für eine Java- und wann für eine Middleware-Lösung entscheiden? Für das Suchen von Büchern in einer Bibliothek beispielsweise reiche nach den Worten von Voell eine einfache Middleware zum Konvertieren der Host-Daten in HTML aus. Für Anwendungen mit viel User-Interaktion schneide dagegen die Java- und Active-X-Variante besser ab. Allerdings beschränkt Active X den Aktionsradius einer Software auf die Windows-Plattform. Als schnellste Java-Lösung im Bereich der 3270-Emulationen konnte sich nach den Erfahrungen des Beraters das Produkt "Persona" von Persoft behaupten.

Einigen Firmen kommt es aber nicht nur auf den Host-Daten-Zugriff über das Web an. Häufig wollen die DV-Verantwortlichen auch die veralteten Masken erneuern. Darauf haben die Hersteller reagiert: Automatisch wandeln bestimmte Web-to-Host-Produkte die Bildschirminhalte in eine gefälligere, Windows-ähnliche Darstellung um.

Beispielsweise bieten "Cool" von Cntware und "Log-Web" von Logics Software, beides Java-Produkte, solche Funktionen. Das war für den Berater Voell auch ein Grund dafür, diese Produkte beim Pilotprojekt einzusetzen. Über einige Standardregeln legt der DV-Verwalter fest, wie die Client-Software die Host-Masken umsetzen soll. Felder, die Mainframe-seitig editierbar sind, stellt auch das Java-Applet als Edit-Feld dar. Auch Funktionstasten wandelt die Software um, sie erscheinen im Web-Browser als Buttons.

Oft muß sich der Benutzer durch viele Masken hangeln, bis er schließlich auf die gewünschte Seite gelangt. Durch eine spezielle Programmierung überspringt der Java-Client einige Screens, so daß der Benutzer einfacher zum Ziel kommt.

Alle Web-to-Host-Produkte teilen ein gemeinsames Dilemma: die unzureichende Druckerunterstützung. Hier arbeiten die Hersteller noch emsig an einer Lösung. Zwar löste Sun viele Unzulänglichkeiten mit Java 1.1, doch gibt es bisher nur wenige Produkte mit diesen Features. Diese leidige Erfahrung mußte auch der Berater Voell bei seinem Projekt machen. Sein Team umschiffte das Problem, indem die Software "Remote Print Manager" von Thyssen Informatik aufgespielt wurde. Schwierigkeiten haben die Web-Anwender außerdem mit den Funktionen "Cut", "Copy" und "Paste", mit denen sich Bildschirminhalte im Browser-Fenster in andere Programme einfügen lassen.

Doch auch in puncto Ladezeiten machen die Java-Lösungen keine gute Figur. Teilweise benötigt der Browser ein bis zwei Minuten, bis die Emu- lation auf dem Bildschirm ist. Außerdem beansprucht der PC mehr Rechenleistung zum Ausführen der Emulationssoftware als bei Produkten, die auf eine Middleware setzen.

Manche DV-Chefs erhoffen sich durch Web-to-Host-Lösungen, bei den Lizenzgebühren zu sparen, da sie keine spezielle Emulationssoftware für jeden PC kaufen müssen, wie es bei reinen Windows-Lösungen der Fall ist. Doch auch bei den Web-Produkten haben die Hersteller das Geldverdienen nicht vergessen. Entweder bezahlt der Kunde die Anzahl der gleichzeitigen Sitzungen, oder er muß pro Endbenutzer eine Gebühr entrichten.

Bei einer dritten Variante rechnet der Lieferant die Lizenzgebühren pro Middleware-Server ab. Immerhin bleibt aber die erhebliche Ersparnis durch die zentrale Konfiguration des Host-Zugriffs.

Sicherheit

Damit auch der Web-Zugriff auf den Mainframe ohne böse Überraschungen möglich ist, müssen die DV-Verantwortlichen ihre Intranets entsprechend nachrüsten. Kommuniziert der Client via HTTP, also über eine dazwischengeschaltete Middleware, mit dem Host, dann bietet sich zur Authentifizierung das Verfahren RSA an. Zum Verschlüsseln der Daten, die der Web-Client mit der Middleware austauscht, stehen Secure HTTP (SHTTP) oder Secure Socket Layer (SSL) zur Verfügung.

Zur Absicherung von Terminalemulationen, die als Java- oder Active-X-Programm laufen, wurden Kerberos, DCE Security Service und SSL entwickelt.

Eine weitere Gefahrenquelle bei dieser Variante stellen modifizierte Applets dar. Diese mutwillig von Hackern veränderten Programme können unbemerkt Schaden anrichten oder Host-Daten auf einem PC ausspionieren. Sogenannte "Signed Applets" schaffen hier Abhilfe. Ähnliches gilt auch für Active X Controls.

Unabhängig von diesen Sicherheitsmechanismen sind Firewalls unabdingbar, denn niemand sollte den Mainframe direkt mit dem Internet oder Intranet koppeln.

Spielarten bei der Web-to-Host-Integration

Damit Anwender vom Web-Browser aus Applikationen auf einem Mainframe bedienen können, muß eine Umwandlung der Host-Daten in HTML stattfinden. Es gibt drei verschiedene Varianten, wie dies geschehen kann:

Middleware-Server zwischen Desktop und Mainframe: Auf einem dem Host vorgeschalteten Unix- oder NT-Server läuft eine Middleware-Software und ein Web-Server. Letzterer stellt den Browsern die aufbereiteten Host-Daten als Web-Seiten zur Verfügung. Zusätzlich sieht das Produkt "Arpeggio Live" vor, daß die Clients spezielle Module, Java- oder Active-X-Module zum Drucken oder für den Dateitransfer, herunterladen.

Beispiele für diese Kategorie sind:

"Salvo" von Simware,

"Starview" von Relay Software und

"Arpeggio Live" von Wall Data.

Terminalemulation in Java oder Active X: Von einem Web-Server lädt der Browser eine in Java oder Active X implementierte Terminalemulation. Zur Anzeige der Host-Daten wandelt der Client die Daten lokal in HTML um.

Zu dieser Sparte gehören folgende Hersteller:

"Persona" von Persoft,

"Reflection Enterview" von WRQ,

"Log-Web" von Logics Software,

"Winsurf Mainframe Access" von Icom,

"Onweb Host" von FTP Software und

"Cool" von Cntware.

HTML-Umwandlung auf dem Host: Hierzu wird auf dem Großrechner eine spezielle Software installiert. Diese Lösungen kommen ohne zwischengeschaltete Middleware-Rechner aus, die zwischen Host und den Web-Clients vermitteln. Der Funktionsumfang dieser Produkte beschränkt sich aber nicht nur auf die reine Konvertierung in HTML. Zwar sind diese Lösungen sehr zuverlässig, weil sie auf dem Mainframe laufen, andererseits ist Rechenzeit auf dem Host teuer. Produkte dieser Art liefern nachfolgende Firmen:

"Web Connect Pro" von Open Connect Systems,

"Brixton Web Integrator" von Cntware und

"Enterprise Web" von Beyond Software.