Fast alles, was als Technologie oder Anwendungsprogramm mehr als einige Monate alt ist, wird heute mit dem Label "Legacy" belegt und damit als "alt, überholt und nicht mehr zeitgemäß" abgetan. Diese Konnotation trifft auch die Produktklasse der Transaktions-Monitore, die auf den Mainframes vor mehr als 20 Jahren eingeführt wurde. Ohne Transaktions-Monitore jedoch wären Online-Banküberweisungen, Versicherungsabschlüsse, Flugbuchungen und kommerziell erfolgreiche IT insgesamt nicht denkbar. Sun hat die Java-gemäße Umsetzung dieser Funktionalität in einem übergreifenden Architektur-Konzept spezifiziert. Erste Produkte, die den Anforderungen genügen, werden in Kürze Marktreife erreichen.
Web-basierende Lösungen gelten heute als attraktive Möglichkeit, universelle Client-Server-Architekturen kostengünstig zu realisieren. Die Geschäftslogik wandert von den Fat Clients (Zwei-Schichten-Modell) in die zentralen Server. Thin Clients nutzen parametrisierte Aufrufe via HTTP/HTML oder direkte Verbindungen zum Server für die Kommunikation mit dem Web-Server (siehe Kasten zum 2,5-Schichten-Modell). Um die Anwendungslogik auf den Web-Server zu bringen, gibt es eine Vielzahl von Techniken, von denen einige allerdings inzwischen auch schon das Prädikat Legacy tragen. Zu diesen gehört das Aufrufen von Folgeprozessen im Web-Server über das Common Gateway Interface (CGI-API). Andere Mechanismen sind Web-Server-spezifisch und daher proprietär. So zum Beispiel Netscapes NSAPI oder Microsofts Information Server API (ISAPI) und Active Server Pages (ASPs), die User-bezogene Threads im Web-Server verwalten. Der Web-Server wächst mit der Anforderung, Anwendungslogik zentral im Web-Server einzubringen und auszuführen, über die Rolle des reinen Kommunikations-Vorrechners hinaus und wird zum Applikations-Server.
Um den Anforderungen an einen Applikations-Server in geschäftskritischen Anwendungen zu genügen, benötigt der Web-Server neben der Anwendungslogik zuverlässige Middleware. Diese sorgt dann für ausreichende Skalierbarkeit der Gesamtanwendung, bietet Transaktionskonsistenz, integriert Anwendungen und stellt Datenbank- und Kommunikationsverbindungen effizient via Connection Pooling her. Auch die Unterstützung von Protokollen für die Interoperabilität mit existierenden Anwendungen für Transaktions-Monitor- oder Corba-basierte Applikations-Server ist nur mit entsprechender Middleware möglich.
Skalierbarkeit im High-end-Bereich bedeutet die Unterstützung von mehreren hundert bis mehreren tausend parallelen Benutzern, ohne daß die Antwortzeiten explosionsartig in die Höhe schnellen. Für Services, die im Internet angeboten werden, gibt es keine vorher bekannte Obergrenze der zeitgleich agierenden Endbenutzer. Daß auch etablierte Unternehmen schon in ernste Probleme geraten sind, weil ein Skalierbarkeitsproblem schlagartig die Nutzung neuer Anwendungen unmöglich gemacht hat, ist kein Geheimnis. In jüngster Zeit häufen sich falsch gewählte Architekturen, falsche Designs und mangelhafte Funktionalitäten der Middleware-Infrastruktur. Einfache Abhilfen im Nachhinein gibt es dabei oftmals nicht, da in vielen Fällen das Design der Anwendung, der Applikations-Server-Typ oder das Design des Datenschemas die Ursache sind und nicht etwa leicht korrigierbare Programmierfehler. Auch die Replizierung der Anwendungen auf zusätzlich angeschaffter Hardware ist dann nicht immer eine Lösung. Bei Online-Anwendungen mit hohem Transaktionsaufkommen lassen sich die Datenbestände oftmals nicht oder nur unter extrem hohen Kosten replizieren. Wenn Anwendungen und Daten zur Problemverminderung verteilt oder repliziert werden müssen, erzeugt dies oft weitere Performance-Belastungen. Die Verteilung von Datenbanken erfordert dann möglicherweise plötzlich Remote Joins über verteilte Tabellen hinweg, oder das Performance-Verhalten der Datenbank ändert sich völlig, weil die Caches nicht mehr optimal nutzbar sind.
Leistungsstarke Applikations-Server, die schon seit Jahren als TP-Monitore eingesetzt werden, wie CICS von IBM, "Open UTM" von Siemens oder "Tuxedo" von BEA Systems, reagieren durch Load Balancing, Scheduling und Pooling-Mechanismen auch bei Spitzenlasten lediglich mit einem moderaten Anstieg der Antwortzeiten.
Die darauf basierenden Anwendungen müssen allerdings auch vom Datenschema und Anwendungsdesign her auf die Bewältigung von Spitzenlasten konzipiert sein. In der Regel betrifft dies aber immer nur gewisse Hot-Spot-Datensegmente und wenige Services, die von erfahrenen Architekten vorab identifizierbar sind.
Wesentliche Aspekte von Hochverfügbarkeit sind auch der dynamische Austausch von Softwaremodulen im laufenden Betrieb und das Einbringen neuer Services, ohne daß die Anwendung beendet werden muß.
Die Konsistenz verteilter Verarbeitungsabläufe gewinnt in der komplex vernetzten IT-Welt immer größere Bedeutung für die Sicherheit der Unternehmensdaten und das zuverlässige Funktionieren der verzahnten Prozeß- und Workflow-Ketten. Datenbanksysteme bieten lokale Transaktionen oder höchstens globale Transaktionen für homogen verteilte Datenbestände, nicht jedoch das Transaktions-Management für verteilte Anwendungen, insbesondere dann nicht, wenn auch noch Datenbanksysteme von anderen Herstellern oder Main- frames mit synchronisiert werden sollen. Hierfür werden dedizierte Transaktions-Manager benötigt, die von Highend-Applikations-Servern bereitgestellt werden. Dabei sind Selbstkontrolle der Systeme und automatisches Recovery nach Ausfallsituationen, bei Störungen und Programmfehlern für zukünftige Großanwendungen ein absolutes Muß.
Keine Anwendung entsteht heute mehr auf der grünen Wiese. Bei der Neuentwicklung von Anwendungen wird es immer auch darum gehen, die neuen Services mit den Diensten und Verarbeitungsleistungen existierender Anwendungen zu koppeln. Wenn dies effizient und sicher geschehen soll, so muß der Applikations-Server eine entsprechende Unterstützung für die heute eingesetzten Interoperabilitätsprotokolle bieten. Diese Kommunikation kann dann sowohl über synchrone Verfahren als auch über asynchrone Verfahren laufen.
Als Standards für diese Interoperabilität haben bei den Mainframe-Anwendungen die beiden IBM SNA-Protokolle LU6.1 und LU6.2 sowie das X/Open Protokoll OSI-TP große Verbreitung gefunden. Moderne Applikations-Server unterstützen das Corba IIOP Protokoll der OMG, das sich auch für die Kommunikation mit Enterprise Javabeans als Standard etabliert.
Leistungsstarke Applikations-Server müssen zahlreiche Kernfunktionen als Infrastruktur für die darauf realisierten Hochlast-Anwendungen bereitstellen. Im Prinzip sind dies genau diejenigen Funktionalitäten, die klassische Transaktions-Monitore erbringen müssen, ob auf dem Mainframe, auf Unix- oder NT-Servern. Allerdings war und ist beim Einsatz der klassischen Transaktions-Monitore seitens der Programmierer eine genaue Kenntnis des jeweiligen Middleware-Produkts erforderlich, da trotz X/Open Standards jedes dieser Produkte seine spezifischen APIs und semantischen Besonderheiten hat. Mit dem von Sun spezifizierten Komponentenmodell Enterprise Javabeans (EJB) für Server-Komponenten wird nun ein neuer Ansatz begründet, der Java-basierende und objektorientierte Komponententechnologie für eine möglichst große Effizienz der Anwendungsprogrammierer anbietet. Zum ersten Mal wird dabei eine bisher nur über proprietäre APIs zugängliche Funktionalität für Anwendungen eröffnet. Der Programmierer muß dabei nicht einmal wissen, auf welchem Applikations-Server die Anwendung ablaufen soll. Erreicht wird dies durch einen eleganten Trick: Zwischen Anwendung und dem Ablaufrahmen für die TP-Monitor-Funktionalität wird ein Adapter geschoben, der bei EJB "Container" heißt. Das API und die Funktionalität dieses Containers sind durch die EJB-Spezifikation streng festgelegt, so daß sich der Programmierer der Portabilität seiner Software-Komponenten sicher sein kann, wenn er sich selbst an das API hält.
Die Hersteller der am Markt etablierten TP-Monitore arbeiten seit der Freigabe der ersten Version der EJB-Spezifikation im März vergangenen Jahres mit Nachdruck daran, entsprechende Applikations-Server mit standardkonformen Containern für die vorhandene und dringend in modernem Kleid benötigte Funktionalität bereitzustellen. Siemens hat auf Basis von Open UTM eine erste Version eines EJB-fähigen Applikations-Servers für September 1999 auf Windows NT angekündigt. Von IBM und BEA sind bereits derartige Produkte auf dem Markt; allerdings basieren diese noch nicht auf TP-Monitoren.
2,5-Schichten-Modell
Beim 2,5-Schichten-Modell läuft der Logik-Anteil der Fat Clients (Zwei-Schichten-Modell) getrennt von der Benutzeroberfläche ab und wird zentral vom Web-Server verwaltet. Der Web-Server stellt dabei aber keine Infrastrukturdienste bereit, die über die Kommunikation mit dem Browser sowie die Verwaltung und den Aufruf der Business-Logik hinausgehen. Der Präsentationsteil wird über HTML und neuerdings immer öfter über XML-Technologie auf dem Frontend ausgeführt.
Die Spezifikation dazu einsetzbarer Servlets und Java Server Pages (JSP) ist die Java-basierende Antwort von Sun auf die ISAPI-Schnittstelle und die Active Server Pages von Microsoft. Mit den Servlets hat Sun ein API zum Aufruf von in Java geschriebenen Programmen innerhalb eines Web-Servers festgelegt. JSPs beschreiben und erzeugen dynamisch mit Daten- und Ausführungssequenzen füllbare HTML-Seiten. Damit setzt Sun einen Industriestandard für Java-basierendes, dynamisches HTML mit Web-Server-API, der in jeder Hinsicht plattformunabhängig ist. In den Java Server Pages können direkt Datenbankaufrufe enthalten sein. Die Ergebnisse lassen sich innerhalb der JSPs auswerten und als Ergebnis in Form einer dynamisch erzeugten HTML-Seite auf die vom Benutzer parametrisierte Aufruf-Seite senden. Die in den JSPs enthaltene Logik kann auch in Java-Funktionsbausteinen vorliegen, die als Javabeans, also als parametrisierbare, fertige Komponenten realisiert sind, wie sie auch bei in Java geschriebenen Fat-Clients eingesetzt werden.
Echte Mehrschicht-Architekturen (n-tier mit n>=3 )
Bei echten Mehrschicht-Architekturen stellt zusätzliche Middleware die Infrastruktur für zentral angebotene Software als (Web-)Applikations-Server bereit. Die Infrastruktur stellt die Skalierbarkeit und Hochverfügbarkeit sicher und sorgt für die Konsistenz verteilter Datenbestände, unterstützt neue und alte Industriestandards zur Kommunikation und Interoperabilität zwischen heterogenen Anwendungen, authentisiert Benutzer und verschlüsselt Daten. Die Business-Logik wird dabei in Form von Enterprise Javabeans gekapselt. Diese EJBs werden oft mit Javabeans, wie sie in Fat Clients und Java Server Pages zum Einsatz kommen, verwechselt oder gleichgesetzt. Das einzig Gemeinsame an diesen beiden Komponententypen ist die Programmiersprache Java.
Angeklickt
Das Internet als Anwendungsplattform verlagert die Programmlogik vom fetten Client auf den Server. Die Ausführung der Geschäftsobjekte auf der mittleren Anwendungsschicht erfordert dort hohe Skalierbarkeit, Ausfallsicherheit und eine intelligente Kommunikation mit Datenbanken und externen Anwendungen. TP-Monitore und Applikations-Server haben sich in dieser Hinsicht bewährt, schränken aber mit ihren proprietären APIs Anwender ein. Mit der Unterstützung von Suns Enterprise Javabeans öffnen sich aber fast alle namhaften Hersteller solcher Produkte für objektbasierte Transaktionsdienste auf Basis einheitlicher Programmierschnittstellen.
*Karl-Wilhelm Schick ist Produkt-Manager für Middleware im Siemens-Geschäftsgebiet Computer Systems.