Die interne WebFacing-Anwendungsarchitektur vom Server bis zum Client

von Don Denoncourt

Teil 1 und 2

Teil 1 des Artikels ist in der Maiausgabe 2005 der NEWSolutions erschienen, Teil 2 in der Juniausgabe 2005. Hier lesen Sie den vollständigen Artikel.

Der Autor

Don Denoncourt (denoncourt@comappsspec.com) ist WebSphere Consultant der Fa. Computer Applications Specialists, Inc. und technischer Autor für NEWSolutions. Übersetzt und für den deutschsprachigen Markt überarbeitet von Joachim Riener.

Als Ergänzung zum Artikel sind bereits 15 WebFacing Programmiertipps im Internet veröffentlicht:

Link: 15 WebFacing Programmiertipps

1. Konfigurationseinstellungen
2. Performance Tuning
3. Detaillierung der Fehlernachrichten
4. Server-Alternativen
5. WebFace Link
6. Anpassung der Logon-Seite
7. Arbeiten mit dem WebFacing Job
8. Angepasste Server-seitige Verarbeitung
9. Anpassung der Funktionstasten JSP
10. Anpassung der Schaltflächen-Ereignisse
11. Angepasste JavaScript-Lokation
12. XML DDS Anpassung
13. Objektorientiertes JavaScript
14. WebFacing Logging
15. Das CAS DDSRecall Tool

Als Java-Consultant, der die 80er-Jahre mit RPG-Codierung zugebracht hat, macht es sich bezahlt, sich mit einer speziellen Technologie besonders auszukennen – dem IBM WebFacing Tool. So verbrachte ich lange Zeit damit, hinter die WebFacing-Kulissen zu schauen. Um das Innenleben zu verstehen, musste ich mir zuerst einen Überblick verschaffen, auf welche Weise IBM diverse J2EE-Technologien kombiniert hat, um 5250-Anwendungen im Web abzubilden. In diesem Artikel erläutere ich den internen Ablauf der WebFacing-Anwendungsarchitektur.

Eine WebFaced-Anwendung setzt eine Vielzahl von Technologien ein, die sich leicht in zwei Untergruppen einteilen lassen: die Client-Seite und die Server-Seite. Die Technologien auf der Client-Seite umfassen HTML, JavaScript und CSS (cascading style sheets); auf der Server-Seite finden sich JavaBeans, Java Servlets, Java Server Pages (JSP) und XML-Konfigurationsdateien. Beginnen wir mit der Server-seitigen WebFacing-Verarbeitung. Hier wird dynamisch das gesamte HTML und ein Teil des JavaScript für den Client-seitigen Teil der Anwendung generiert.

Globale Konfiguration

Alle J2EE-Anwendungen verwenden eine globale Konfigurationsdatei namens web.xml, die sich im Web Content-/WEB-INF-Verzeichnis befindet. In der Datei web.xml werden generelle Anwendungswerte festgelegt und Servlets mit URI-Pfaden (Universal Resource Identifier) assoziiert. Das WebFacing Tool modifiziert die Datei web.xml, indem es – neben anderen Informationen – eine Reihe von context-param tags einbringt, die in WDSc vorgenommene Einstellungen beinhalten. Diese Einstellungen schließen die eMail-Adresse des Administrators, die IP-Adresse und die Port-Nummer des Host sowie Optionen für Benutzerprofil und Passwort ein.

Die WebFacing Java Servlets werden in der Konfigurationsdatei web.xml mit URI-Pfaden assoziiert (Abbildung 1).

Jeglicher WebFacing-HTML-Input (die umgesetzten 5250-Bildschirme) wird mit Hilfe dieser Servlets verarbeitet. Wenn ein http-Request an WebSphere gestellt wird, geschieht dies mit einer Zeichenkette, die die Domäne enthält, damit das zur Verarbeitung des Request erforderliche Java Servlet identifiziert werden kann. Ein WebFacing Logon Servlet für eine Verkaufsanwendung würde beispielsweise über folgenden http-Request abgewickelt:

http://www.comappspec.com/SalesApp/……..

Schauen wir uns nun die Behandlung dieser URL-Adresse an.

Starten der Engine

In der Datei web.xml ist unter anderem index.html als Standard-Web-Seite festgelegt. Gibt ein Benutzer also in seinem Browser den Domänen- und Anwendungsnamen (z.B. http://www.comappspec.com/SalesApp) ein, wird automatisch die Seite index.html angezeigt. Auf dieser Seite befindet sich ein Link, der das Logon Servlet aufruft. Das Logon Servlet enthält nur wenig Code. Die Abwicklung des Benutzer-Logon geschieht über eine Helper-Klasse:

LogonRequestHandler helper =
	new LogonRequestHandler(
		request, response, servletContext);
helper.handleRequest();

Der Logon Helper prüft zuerst Benutzerprofil und Passwort sowie ein paar triviale Dinge wie den Level des vom Benutzer verwendeten Browsers. Ist der Benutzer noch nicht angemeldet, sendet die Helper-Klasse ein Eingabeformular namens logon.html; es sei denn, im Browser des Benutzers ist die Option für ein benutzerdefiniertes logon.html oder logon.jsp definiert. Da in logon.html WFLogon qualifiziert ist, wird die Steuerung an das Logon Servlet übergeben. Sobald der Benutzer ein gültiges Benutzerprofil und Passwort eingegeben hat, erstellt die Logon Helper-Klasse ein WFConnection-Objekt unter Verwendung der Benutzerwerte Host, Port, Passwort und HttpSession.

Der Logon Helper startet anschließend einen QQFINVOKER Server Job in QINTER, der wiederum den CL-Driver startet. In dem QINTER Job läuft die Green screen Anwendung ab, die RPG-DisplayFile-Ausgaben werden aber nicht an ein 5250-Terminal gesendet, sondern zwischengespeichert und an die in WebSphere laufende Java-basierte WebFacing-Anwendung übergeben. Obwohl der Job in Qinter läuft, wird er nicht der interaktiven Systembelastung zugeschlagen. Das WFConnection-Objekt unterhält eine Socket-Verbindung zu dem QQFINVOKER Job des Benutzers und das WFConnection-Objekt verbleibt im http-Session-Objekt des Benutzers. Der Logon Helper übergibt als letzten Schritt die Verarbeitung an ControllerServlet.