XML und das Simple Object Access Protocal (Soap) sind längst ein fester Bestandteil der IT-Architektur bei der Hypo-Vereinsbank (HVB) in München. Die Beschreibungssprache und das Protokoll dienen dem Dialog zwischen verschiedenen Online- und Batch-Anwendungen und Schichten, dem Datenaustausch mit den Filialen und der Zentrale und sogar zur Kommunikation mit Geschäftspartnern der Bank. Gearbeitet wird noch an der Speicherung von XML-Dokumenten sowie an der Verarbeitung auf dem Großrechner.
Die Schlankheitskur per WAP-Kompression verdankt die HVB-Datenkommunikation Markus Wagner und seinem Team. Der Projektleiter gehört zu einer Querschnittsabteilung der Großbank, die Basisarbeiten für die DV übernimmt, etwa die Evaluierung von Entwicklungswerkzeugen sowie die Umsetzung von Architekturen und Frameworks. Im Mai 2000 bekamen Wagner und sein Team den Auftrag zu erforschen, was sich im Haus mit dem Austauschformat XML machen ließe. Die Systemspezialisten sollten prüfen, ob man mit XML die Infrastruktur für die Datenkommunikation vereinheitlichen könne. Die Untersuchung endete im September des vergangenen Jahres. Seither ist Wagner damit beschäftigt, die Erkenntnisse umzusetzen.
Typisch für HVB-Anwendungen ist eine Drei-Schichten-Architektur, welche die Datenhaltung von der Verarbeitung und der Präsentationsebene trennt. Die Daten liegen zumeist auf DB2- und IMS-Systemen, daneben kommen aber auch Oracle, der SQL-Server und R/3-Anwendungen zum Einsatz. Für die Verarbeitung sind im Wesentlichen Großrechner und NT-Server zuständig, dazu einige Unix-Maschinen, Java-Applikationen und NT-Clients. Dabei konzentrieren sich die Anwendungen häufig pro Abteilung auf einer Plattform, so dass in der Verarbeitungslogik auch Zugriffe über IT-technische Grenzen hinweg erfolgen müssen. Windows-Clients übernehmen zumeist noch die Präsentation; neue Anwendungen entstehen jedoch auf Browser-Basis.
In der rechnerübergreifenden Kommunikation kommt es vor allem auf sauber definierte Schnittstellen an; bei der Interaktion von Programmen liegt das Hauptaugenmerk darauf, welche Daten ausgetauscht werden müssen. Mit Hilfe von XML lassen sich Daten und Meta-Informationen transportieren; damit wird
Nur ein Mechanismus
die Beschreibungssprache beiden Anforderungen gerecht. Dabei müssen die Schnittstellenmethoden bei der HVB der einheitlichen Syntax "Public XML doSomething (XML input)" genügen. Nach dieser Konvention sind alle Ein- und Ausgabeparameter in XML verpackt. So lassen sich über einen einzigen Mechanismus Anwendungen entkoppeln und Fremdsysteme anbinden, schwärmt Projektleiter Wagner.
Für den Datenaustausch über Rechnergrenzen hinweg bedarf es allerdings eines Transportprotokolls. Für das Wagner-Team kam dafür lediglich HTTP in Frage. Objekt-Broker nach dem Corba-Standard standen nicht zur Debatte, und die Microsoft-Alternative DCOM ginge laut Wagner zu Lasten von Leistung und Sicherheit. So lassen Firewalls TCP/IP-Informationen nur über den Port 80 durch, alle anderen Zugänge sind standardmäßig blockiert. DCOM erfordert verschiedene offene Ports, so dass der Durchlässigkeitsbereich entsprechend erweitert werden müsste.
Wagner gefiel HTTP auch deshalb, weil das Verfahren "verbindungslos" funktioniert. Im Gegensatz zu DCOM beispielsweise schaut der HTTP-Server nicht immer mal wieder nach, ob der Client noch existiert. Der Server wartet, bis ihm etwas geschickt wird. Das reduziert den Kommunikationsaufwand.
Laut Wagner ist das auf HTTP basierende Soap damit ein sehr einfaches Verfahren, um Web-Services aufzurufen. Allerdings hat diese Einfachheit fehlenden Komfort zur Folge. Dazu zählt der HVB-Experte, dass immer nur ein Aufruf getätigt werden kann. Außerdem ist es unmöglich, mehrere Aufrufe in eine Transaktion zu packen. Die zweite Einschränkung, erläutert Wagner, bestehe darin, dass sich nur einfache Daten und beispielsweise keine zusammengesetzten Datentypen übertragen lassen. Das bedeutet für den Fall, dass eine Methode ein Objekt als Parameter erwartet oder liefert, es erst zu XML serialisiert beziehungsweise daraus erzeugt werden muss. So kann das Objekt selbst die Methode zur Verfügung stellen, die seine Eigenschaften, das heißt seinen Dateninhalt, als XML-String offen legt. Umgekehrt braucht man eine Möglichkeit dafür, ein Objekt aus einer solchen Zeichenkette aufzubauen.
Schwäche von Soap
Die HVB-Analytiker überwinden die Schwächen von Soap mit Hilfe von selbst entwickelten Collectoren, Dispatchern und Generatoren. Die plattformspezifischen Collectoren sammeln die Aufrufe für einen Zielrechner, so dass sie sich mit einem Mal übertragen lassen. Auf dem Zielrechner dividiert der Dispatcher die Aufrufe auseinander und verteilt sie an die eigentlich angesprochenen Komponenten. Dieses Vorgehen senkt die Belastung des Netzes und erhöht die Transaktionssicherheit.
Da keine besonderen Wrapper mehr geschrieben werden müssen, nimmt das Verfahren ein Stückchen Komplexität aus der Infrastruktur. Außerdem lässt sich die Wiederverwendbarkeit der Services erhöhen. Für die Anwendungsentwickler bedeutet das Sammeln und Verteilen per Tool, dass ihre Programme nicht mehr einen einzelnen Service aufrufen, sondern einen Collector. Der Aufruf des Dispatcher erfolgt über Soap mit der Syntax "Public XML Dispatch (XML Input)".
Dabei enthält der XML-Code, den die Methode bekommt, Steuerinformationen. Sie bestehen im Wesentlichen aus einzelnen Aufrufen, die ebenfalls Soap-Informationen umfassen. Die von den Collectoren erzeugte Hülle für den Dispatcher-Aufruf ist durch gekennzeichnet und erlaubt es, bereits vorhandene Soap-Implementierungen zu verwenden.
Mainframes einbinden
Den Bau von Soap-Calls übernehmen Generatoren. Manche erzeugen in der Web Service Description Language (WSDL) verfasste Beschreibungen davon, was eine Komponente kann und welche Parameter übergeben werden. Andere generieren aus den Beschreibungen Client-Code.
Die Kollektoren, Dispatcher und Generatoren sind für die Umgebungen COM, Java und Unix im Einsatz: bei der Kommunikation zwischen verschiedenen Plattformen innerhalb von Anwendungen, bei der Einbindung von älteren Systemen sowie als B-to-B-Schnittstelle für einige externe Partner. Für den Zugriff auf OS/390-Großrechner ist das Konzept fertig.
Für Wagner geradezu überraschend zeigen die Implementierungen gute Durchsatzleistungen. Allerdings steigt die Performance noch weiter, wenn man die Software auf die Anwendungssituation zuschneidet. So ließen sich die Antwortzeiten nochmals halbieren. Doch damit konnte Wagner das Problem mit der Netzlast immer noch nicht zufriedenstellend lösen. Die Verwendung von XML bläht nämlich durch die zusätzliche Übertragung von Metadaten das Kommunikationsaufkommen zwangläufig auf. Messungen innerhalb der Bank ergaben, dass die Datenmenge um den Faktor 1,3 bis zehn steigt. Zugleich verlängern sich die Nachrichten. Dadurch müssen sie statt in einem in mehreren Paketen versandt werden, was zudem das Ordnen ankommender Nachrichten in die richtige Reihenfolge erfordert.
Doch dann kam dem Systemanalytiker die Idee, die Informationen zu komprimieren - und zwar im Verfahren Wap Binary XML (WBXML). Es wurde zwar speziell für die schwachen Übertragungskanäle von WAP-Handys entwickelt, funktioniert aber auch bei normaler XML-Kommunikation. Wagner kommentiert schmunzelnd: "Unsere Leitungen zu den Filialen lassen bei 64 kBit/s auch nur soviel Daten durch wie ein Handy-Call."
Im Wesentlichen besteht die WBXML-Verdichtung darin, die Tags, Standard-Attribute und -Texte durch einen 1-Byte-Code zu ersetzen. Sind einzelne Tags und Texte dem Empfänger unbekannt, werden für die Zuordnung Stringtabellen mit übertragen. Bei nochmaliger Versendung wird nur noch der Code durchgereicht. Für die Belange der HVB erweiterte das Wagner-Team die in WBXML verfügbaren Stringtabellen um eigene.
Performance geht vor
Das Komprimieren der Daten macht die Transparenz der XML-Technik allerdings zunichte. Wagner ist das bewusst, doch er verweist darauf, dass sich mit Hilfe des Stauchens das Datenvolumen auf ein Maß reduzieren lässt, das im Bereich herkömmlicher Kommunikationsverfahren liegt. Seine Messungen ergaben, dass sich durch das Komprimieren die LAN-Performance um 33 Prozent steigern ließ.
Letztlich entscheiden die Anwendungsentwickler, ob sie die Transparenz oder die Performance vorziehen. Für Wagner steht Durchsatzleistung eindeutig im Vordergrund. Sein Team entlastet die Anwendungsentwickler zudem von der Aufgabe, XML zu erzeugen.
Die heterogene Infrastruktur der HVB sorgt für zahlreiche Schnittstellen zwischen XML und herkömmlichen Daten. Dabei muss XML zuerst aufgebaut und dann mit Hilfe von Parsern analysiert werden: Die Daten aus der Datenbank erhalten zunächst die XML-Form. Dann schaltet die Verarbeitung einen Parser ein, verändert die Daten unter Umständen und erzeugt wiederum XML. In der Präsentationsschicht einer Anwendung ist dann wieder ein Parser erforderlich.
Für Wagner und seine Crew war das zuviel des Guten. Sie überlegten sich ein Vorgehen, bei dem XML-Daten durchrutschen können. Sie implementierten XML-Objekte, die nach außen, wie in der Objektorientierung üblich, Eigenschaften und Methoden anbieten, aber auch eine XML-Schnittstelle haben. Das hat zweierlei Auswirkungen: Sind die Objekte mit XML gefüllt, trifft dieser Code erst dann auf einen Parser, wenn der erste Zugriff über Eigenschaften und Methoden erfolgt ist, also gleichsam am Ziel. Werden herkömmliche Daten nur durchgereicht, entfällt das XML-Parsen komplett. Dieser Trick entbindet die Anwendungsentwickler von der Aufgabe, XML parsen und erzeugen zu müssen.
Nun beschäftigte die HVB-Systemspezialisten noch, wie XML-Daten dem Anwender in HTML präsentiert werden könnten und wie sich das Format am besten speichern ließe. Den Cocoon-Ansatz für die Präsentation (siehe http://xml.apache.org/cocoon) befand Wagner als zu rechenintensiv. Das HVB-Verfahren generiert nun mit Java Server Pages (JSP) mehrsprachige HTML-Seiten. Sie enthalten reinen HTML-Code, sind statisch und lassen sich durch den Browser zwischenspeichern (cachen).
Die Daten hingegen sollten asynchron von der HTML-Seite nachgeladen werden. Dazu nutzt die HVB-Mannschaft noch ein vergleichsweise neues Feature des "Internet Explorer" von Microsoft. Ab Version 5.0 gibt es dort XML-Interpretation. Allerdings unterstützt das MS-Feature noch nicht alle benötigten Funktionen, etwa das Sperren von Feldern auf der HTML-Seite abhängig von den nachzufüllenden Daten. Die Systementwickler implementierten deshalb zusätzliche Display-Attribute zur Auswertung der Datenzufuhr. Auch bieten andere Browser die XML-Interpretation nicht. Deshalb bauten die HVB-Spezialisten sich diese Funktionen hier selbst.
Das Ergebnis kann sich sehen lassen. Umfangreiche Seiten haben bei der HVB etwa 33 KB Größe, aber der Datenumfang beträgt nur 1 KB. Die getrennte Handhabung von HTML-Seiten und Daten reduziert die Netzlast; denn nicht immer müssen sowohl Seiten als auch Daten zugleich geladen werden. Auch die Anwender dürfen sich freuen. Oft entfällt damit das Flackern und die Akzeptanz steigt.
Auf XML-Support warten
Vergleichsweise schwer tut sich die HVB mit der Speicherung von XML-Daten. Die operativen Informationen liegen zumeist auf DB2- und IMS-Systemen. Für IMS gibt es von Herstellerseite noch keinen XML-Support. Laut Wagner fehlt auf dem Großrechner zum Beispiel ein XML-Parser für Cobol-Code.
Allerdings plant die Großbank, die XML-Features für die IBM-Datenbank DB2 unter OS/390 zu evaluieren, sobald die entsprechende Version des Produkts zur Verfügung steht. Das Konzept ist jedenfalls fertig: Man will ausgewählte Tags den Spalten der relationalen Datenbank zuordnen. Das betrifft Informationen, die häufig und unverändert benötigt werden. Diese Speicherform ermöglicht es vor allem, bestehende Daten einzubinden, stößt aber an Grenzen, wenn Attribute beziehungsweise Tags hinzukommen sollen. Deshalb soll eine zweite Form dieses vergleichsweise unflexible Verfahren ergänzen: Die XML-Daten, die übrig bleiben, landen als Large Object im Speichersystem.
Trotz der verbleibenden Schwierigkeiten zieht Wagner eine positive Bilanz: XML in Verbindung mit Soap kann die Abhängigkeit zwischen einzelnen Anwendungen reduzieren, das Netz entlasten, die Basis für eine stabile Kommunikation bilden, heterogene Systeme verbinden, vereinfachen oder sogar ersetzen.
* Ulrike Ostler ist freie Journalistin in Schweitenkirchen-Geisenhausen.
Portrait
Die Hypo-Vereinsbank (HVB) ist die zweitgrößte private Geschäftsbank in Deutschland. Nach ihrer Fusion mit der Bank Austria arbeiten in der HVB Group 65000 Mitarbeiter, die in 2000 Niederlassungen acht Millionen Kunden betreuen. Mit einer Bilanzsumme von 700 Milliarden Euro belegt die HypoVereinsbank in den europäischen Top Ten den dritten Platz. Im Privat- und Unternehmenskundengeschäft konzentriert sie sich auf Immobilienfinanzierung und -dienstleistung, Corporate Finance, strukturierte Finanzierungen, Treasury und Equity-Leistungen sowie Asset-Management.