Auch heute noch werden Benutzern unternehmenskritischer Anwendungen in großen Organisationen der grün-schwarze Bildschirm mit 80 mal 24 Zeichen, geheimnisvolle Abkürzungen als Bezeichner von Eingabefeldern und komplexe Kombinationen von Funktionstasten als User Interface angeboten.
Modernisierung bedeutet in diesem Zusammenhang häufig nur den Einsatz von Emulationen oder "GUI-fizierungswerkzeugen", die diese Oberfläche mehr oder weniger gut auf dem PC umsetzen. Die intuitive Bedienbarkeit moderner Dialogprogramme erreichen solchermaßen aufbereitete Altanwendungen zumeist nicht.
Die Benutzer verlangen aber heute von allen Anwendungen den Bedienungskomfort und die Benutzerführung, die sie von ihren PC-Programmen gewohnt sind. Die Veränderung und Flexibilisierung von Geschäftsprozessen erfordert zudem, dass Benutzer Systeme auch dann bedienen können, wenn sie nur gelegentlich damit zu tun haben. Diese Anforderungen sind nur mit einer grafischen Benutzeroberfläche zu erfüllen.
Andererseits haben Client-Server-Systeme, die den gewünschten Bedienkomfort bieten, Mainframe-Systeme nie ganz ablösen können. In der Frage von Administration und Ausfallsicherheit sind Applikationen, die in einem zentralen Rechenzentrum von geschulten Fachkräften verwaltet werden, nach wie vor unschlagbar.
Der Gegensatz zwischen zentraler Administration und anwendungsfreundlicher grafischer Benutzeroberfläche lässt sich durch Intranet-basierte Anwendungen überbrücken. Dabei bleibt die Anwendung mit Datenbankzugriff auf zentralen Unternehmensrechnern, während auf dem PC ein Web-Browser den Zugang zu dieser Anwendung eröffnet. Probleme, die im Internet aus der grossen Browser-Vielfalt resultieren, lassen sich im Intranet durch entsprechende Standardisierung vermeiden.
Für Intranet-Anwendungen bleiben unter den genannten Prämissen zwei grundsätzliche Architekturalternativen. Bei der ersten Möglichkeit kann ein Applikations-Server dynamisch Web-Seiten erzeugen und über diese den Anwender mit den benötigten Daten versorgen. Die Möglichkeiten von HTML für das Erstellen von grafischen Benutzeroberflächen sind aber beschränkt. Das Hypertext Transfer Protocol (HTTP) ist zudem langsam, und die Übertragung von HTML-Seiten sorgt für weiteren Overhead. Schließlich ist HTTP kein verbindungsorientiertes Protokoll und eignet sich daher kaum für betriebliche Informationssysteme. Entwickler versuchen dieses Defizit durch Mechanismen wie URL-Rewriting oder die Verwendung von Cookies zu kompensieren. Dadurch wird die Anwendung unnötig komplex.
Als Architekturalternative bietet sich daher die durchgängige Nutzung von Java an. In diesem Fall läuft ein Applet in der virtuellen Maschine des Browsers ab. Kommt auch auf der Server-Seite Java zum Einsatz, empfiehlt sich die Remote Method Invocation (RMI) als verbindungsorientiertes Protokoll zwischen den beiden Systemteilen. Diese Lösung ist außerdem schnell, sicher und bietet dem Benutzer die volle, von ihm verlangte Funktionalität grafischer Bedienoberflächen.
Die Entwicklung von Anwendungen auf Basis dieser mehrstufigen Architektur lässt sich durch Frameworks vereinfachen. Beispiele dafür sind "Sumatra" von sd&m oder aber auch solche, die häufig zum Lieferumfang von Web-Applikations-Servern gehören. Die Zugriffsschicht setzt dabei das der Datenbank zugrunde liegende relationale Modell in die von der Objektorientierung beherrschte übrige Anwendung um.
Erleichtert wird diese Aufgabe durch das einheitliche API Java Database Connectivity (JDBC). Im Anwendungskern können Entwickler dann mit Objekten und ihren Methoden umgehen. In dieser Schicht werden Geschäftsregeln vom technischen Problem der Speicherung in der Datenbank, aber auch von der Präsentation an der Benutzeroberfläche, isoliert und die fachlichen Vorgaben umgesetzt.
Mit der beschriebenen Methodik lassen sich neue Anwendungen oder zumindest erneuerte Anwendungsteile erstellen. Es bleibt die Frage nach der Anbindung jener Teile des Systems, für die - aus welchen Gründen auch immer - eine Neuerstellung nicht in Frage kommt. In diesem Fall hilft die Erweiterung um Corba-Schnittstellen unter Nutzung entsprechender Produkte.
Sind die Anwendungsfunktionen auf dem Server via RMI oder Corba erreichbar, kann der Java-Client ohne Dazwischentreten des Web-Servers direkt mit ihnen kommunizieren. Er beschränkt sich aber im Gegensatz zu herkömmlichen Client-Server-Anwendungen auf die Benutzerschnittstelle. Frameworks können die Arbeit auch bei der Programmierung der grafischen Oberflächen erleichtern.
Sumatra fasst die Dialogsteuerung und -präsentation in einem Applet zusammen, daher muss der Browser nicht ständig neue Applets nachladen. Vielmehr werden ein Dialog und sein Verhalten durch Metadaten festgelegt. Das allgemeine Dialog-Applet interpretiert diese Informationen zur Laufzeit, und erst auf dieser Basis wird der konkrete Dialog auf der Client-Seite aufgebaut.
Das Dialog-Applet wird hierdurch zu einer abstrakten "Dialogmaschine", bei der eine Abstraktion im Sinne der Objektorientierung vorliegt. In der praktischen Anwendung bedeutet dies, dass bei einer Vielzahl von Dialogen nur die tatsächlich unterschiedlichen Eigenschaften wie Name und Typ von Eingabefeldern, nicht aber das gesamte Verhalten für jeden Dialog programmiert werden muss. Neben einer starken Rationalisierung der Dialogerstellung hat dieses Verfahren den Vorteil, dass das Applet kompakt bleibt und nicht linear mit der Anzahl der Dialoge wächst.
Zusammenfassend lässt sich sagen, daß die Aufgaben bei der Entwicklung von betrieblichen Informationssystemen durch den Einsatz von Java effizient gelöst werden können.
*Oliver Nandico ist Bereichsleiter bei der sd&m AG in München.