Vom Nutzen der Middleware

E-Commerce erzwingt eine Drei-Schichten-Architektur

10.09.1999
Applikations-Server alleine bringen noch keine Unternehmens-DV in den E-Commerce. Sie bilden aber das Zentrum für den Aufbau einer skalierbaren Middleware-Infrastruktur. Michael Matzer* beschreibt die Drehscheibe für Datenzugriffe auf Großrechner, für die Regelung von Geschäftsprozessen und die Versorgung der Web-Frontends mit Anwendungen.

Online-Banking funktioniert so: Zuerst bekommt der Teilnehmer vom Server seiner Bank eine kleine Anwendung über die Leitung geschickt, mit der er seine Banktransaktionen erledigen kann: Kontostand abrufen, Überweisungen und dergleichen. Aufmerksame Benutzer bemerken in der Statuszeile des Browsers die Meldung "Java wird gestartet". Die heruntergeladene Anwendung ist in Java geschrieben und muß von der lokalen Java Virtual Machine interpretiert und ausgeführt werden. Java ermöglicht auch die Sicherheitsmechanismen, die bei einer Bankanwendung keinesfalls fehlen dürfen.

Ähnlich funktioniert Online-Shopping. Wieder hat es der Anwender nur mit seiner gewohnten Browser-Umgebung zu tun und mit der in HTML oder Java geschriebenen Anwendung des Anbieters - bis hin zur Geldtransaktion per Kreditkarte.

Das einfach zu bedienende Frontend verbirgt die häufig komplexen Systeme, die hinter der Online-Anwendung beim Anbieter existieren, das Backend. Zu ihm zählen Datenbanken, Transaktions-Server, kaufmännische Software oder Archiv-Server.

Beim amerikanischen Online-Finanzdienstleister E*Trade werden Belastungsspitzen von bis zu 15000 Online-Aktienhandelsvorgängen innerhalb von 15 Minuten erreicht. 1998 haben 225000 Kunden rund 4,1 Millionen Transaktionen angestoßen.

Der Schlüssel für die Robustheit und Skalierbarkeit eines solchen Systems liegt in dem, was zwischen Frontend (den Usern) und Backend (der Datenhaltung) bereitsteht und für Ausfallsicherheit, regelgerechtes Transaktionsverhalten sowie zusätzliche Sicherheit sorgt: die Middleware.

Middleware ermöglicht Lösungen, die mit zweischichtigen Client-Server-Architekturen nicht realisierbar wären. Mit einer Drei-Ebenen-Architektur läßt sich Intelligenz in eine Anwendungsinfrastruktur einbauen, die zum Beispiel dafür sorgt, daß eine plötzlich auftretende Belastung auf mehrere dafür ausgelegte Server verteilt wird. Sie ermöglicht neben der Absicherung von Transaktionen auch die Bereitstellung der dafür nötigen Sicherheitsmechanismen.

Außerdem ist die Middleware-Infrastruktur die Voraussetzung, um sich in der Unternehmensentwicklung ein lösungsorientiertes Denken leisten zu können. Der Entwickler kann sich auf die Erstellung einer Lösung konzentrieren, während die Middleware-Komponenten sich darum kümmern, daß die entsprechenden Ressourcen zu ihrer Umsetzung bereitstehen: Speicher- und Übertragungskapazität, Netzwerkverbindungen, Transaktionsschutz, Sicherheitsprüfung und System-Management-Funktionen.

Middleware ist für die Integration heterogener Umgebungen unerläßlich geworden, weil sie entsprechende Schnittstellen für die Programmierung und für die Interaktion der Anwendungskomponenten bereithält. Das gilt insbesondere für Altsysteme auf Großrechnern, die sich damit in moderne Web-Umgebungen einbinden lassen. Auch die Verteilung von Software-Upgrades ist einfacher; sie wird zentral von einem Server gesteuert und auf die entsprechenden Clients verteilt. Das hält die laufenden Unterhaltskosten für die Software niedrig.

Applikations-Server, wie sie etwa Bea Systems, Sun, Inprise, Oracle oder IBM anbieten, enthalten als zentrale Komponente der Middleware-Infrastruktur Anwendungskomponenten mit sogenannten Geschäftsregeln, die den Umgang mit den Daten im Bearbeitungprozeß steuern. Diese Anwendungen können beispielsweise Enterprise Javabeans (EJBs) oder Corba-Komponenten sein. Der Einsatz von COM-Komponenten in Applikations-Servern für große Anwendungen gilt dagegen als unwahrscheinlich. In raschem Tempo verschmilzt die Industrie die Middleware-Komponenten zu immer leistungsfähigeren und umfangreicheren Lösungspaketen. So hat beispielsweise Bea Systems seinen Transaktionsmonitor "Tuxedo" erst um Corba bereichert, dann zum Object Transaction Monitor "M3" ausgebaut und schließlich mit dem Web-Applikations-Server von "Weblogic" zu einem Paket geschnürt. Mitbewerber wie die IBM verfolgen ähnliche Konzepte, um die Anwender mit einer möglichst umfassenden Lösung aus einer Hand an sich zu binden. Für die Kunden geht es dabei um unternehmensweite Anwendungsintegration.

In solchen Infrastrukturpaketen kann der Entwickler großer Anwendungskomplexe nicht nur Java- und C++-Objekte ablegen, sondern hier lassen sich auf heterogene Plattformen verteilte Transaktionen absichern. Soll zum Beispiel die Kreditwürdigkeit eines Online-Shoppers geprüft werden, muß hier eine Anfrage an die Schufa (Bonitätsprüfstelle) formuliert, abgeschickt, die Antwort verarbeitet und an verschiedene Systeme weitergeleitet werden: an das Frontend, um die Transaktion zu genehmigen und den User davon zu unterrichten, an das Backend, um die Datenbank entsprechend zu aktualisieren, sowie an die Lagerhaltung, um die Lieferung und Rechnungsstellung zu veranlassen.

In den Komponenten wie etwa EJBs kann das Unternehmen Geschäftsregeln implementieren. Diese verbinden unter anderem Datenhaltungssysteme, wodurch die Integration einer heterogen gewachsenen Umgebung realisierbar wird. Die Komponentenarchitektur der Geschäftsregeln erlaubt die schnelle und flexible Reaktion auf wechselnde Marktanforderungen, da sie sich austauschen lassen, ohne daß man die gesamte Ablaufumgebung ändern muß.

Will beispielsweise ein TK-Unternehmen zum Muttertag einen besonders günstigen Telefontarif anbieten, so kann es die notwendige Logik in ein Business Object einbauen, dieses von zentraler Stelle aus weltweit auf Anwendungs-Server verteilen lassen und zum entscheidenden Termin aktivieren. So hat die Lufthansa Cargo ihr Frachtauskunfts- und -reklamationssystem "Cargo Entire Sales Reporting" (Cesar) auf Corba- und Java-Einsatz umgestellt. Dauerte es zuvor Stunden, bis ein Mitarbeiter Auskunft bekam, so kann nun jeder Berechtigte weltweit über Browser Einblick in die für ihn relevanten Daten nehmen und eine Reklamation bearbeiten.

Ein anders Beispiel ist der Kosmetikkonzern Yves Rocher. Dort wurde Ende 1997 ein Call-Center für die telefonische Bestellerfassung in Betrieb genommen, dessen IT-Technik auf einer dreistufigen Architektur beruht. Da die Daten weiterhin auf dem Main- frame bereitgehalten werden sollten, wurde als Middleware der Bea-Transaktionsmonitor Tuxedo mit seinen Host-Connec- tivity-Funktionen eingesetzt. Mit der Client-Server-Entwicklungsumgebung "Powerbuilder" geschriebene Business Objects greifen dabei zunächst auf eine Oracle-Datenbank zu. In dieser he- terogenen Umgebung werden Mainframes, Unix- und NT-Rechner eingesetzt - ein Paradebeispiel für die Integration bereits vorhandener Techniken.

Zwei Middleware-Lager

Es gibt zwei konkurrierende Lager: Microsoft mit dem Component Object Model (COM) und einige Firmen um IBM, Sun, und Oracle, die auf die herstellerübergreifende Common Object Request Broker Architecture (Corba) setzen, die von dem Industriekonsortium Open Management Group (OMG) ausgeformt und standardisiert wird. Corba arbeitet mit Java und Web-Technologien zusammen. Sie bietet Skalierungs- und System-Management-Mechanismen sowie Transak- tionssupport. Die Standards sind offen und zugänglich sowie auf alle Plattformen implementierbar.

Letzteres trifft auf COM nicht unbedingt zu. Obwohl die Technik von der Software AG auch auf andere Plattformen portiert wurde, ist COM praktisch nur auf den Windows-Systemen einsetzbar. Weder ist der Sourcecode von Windows noch der von COM offen zugänglich, obwohl natürlich bestimmte Schnittstellen beschrieben sind. Die Arbeit der Entwickler wird auch dadurch nicht einfacher, daß Microsoft einen eigenen Dialekt von Java verwendet.

Der Anwender kann Online-Anwendungen mit beiden Middleware-Techniken realisieren. Die Voraussetzungen sind jedoch verschieden. Microsoft bietet zusammen mit dem Betriebssystem Windows NT 4 Enterprise Server einen Cluster-Mechanismus und einen Anwendungs-Server, den "Microsoft Transaction Server" (MTS), an. Doch nach Angaben einer Reihe von Unternehmensberatern und Pilotanwendern ist die Zahl der damit unterstützbaren gleichzeitigen Anwender begrenzt. Für sehr hohe Benutzerzahlen empfehlen sie daher Unix-Systeme mit entsprechenden Anwendungs-Servern und Thin Clients. Große Web-Anwendungen wie zum Beispiel Amazon.com wären sonst heute nicht möglich.

Abb: Die typische Architektur einer Web-basierten Anwendung für E-Commerce oder E-Business. Quelle: Mercury