Firewall, Rechner und Integrationstechnik in einem
XML-Appliances für die Serviceorientierung
XML dient in der heterogenen Systemwelt einer serviceorientierten Architektur (SOA) als Bindeglied zwischen verschiedenen Programmiermodellen und Plattformen. Die Nachteile der erforderlichen hohen Bandbreite für die Übertragung und der zusätzlichen Sicherheitsmechanismen für die Auszeichnungssprache lassen sich mit dedizierter Hardware für die XML-Verarbeitung wieder ausgleichen.
Kompliziert und langwierig! Dies sind die Merkmale, mit denen IT-Verantwortliche
Integrationsprojekte lange Zeit in Verbindung gebracht haben. War die Integration der Anwendungen
dann endlich erfolgreich abgeschlossen, kamen vom Management oder den Fachabteilungen bereits die
ersten Änderungswünsche, weil sich das Geschäft inzwischen "weitergedreht" hatte. Unter der
mühseligen Zusammenführung litten auch die Folgeprojekte, weil die Pflege der eingesetzten
Middleware sich immer aufwändiger gestaltete.
Eine serviceorientierte Architektur kann Abhilfe schaffen, da sie dem monolithischen
Integrationsansatz einen modularen, diensteorientierten entgegensetzt. In einer serviceorientierten
Architektur verfügt die IT-Organisation über einen Baukasten, mit dem sich Dienste schnell und
unkompliziert miteinander kombinieren und neue Services hinzufügen lassen. Natürlich nutzt eine
SOA-Umgebung ebenfalls eine Middleware: In dem serviceorientierten Paradigma ist dies ein
Enterprise Service Bus (ESB), der die einzelnen Applikationen und Dienste flexibel miteinander
verbindet.
Das US-Beratungsunternehmen Gartner geht davon aus, dass bis in drei Jahren 80 Prozent der
Unternehmen ihre geschäftskritischen IT-Systeme in eine SOA integriert haben werden. Die Planer
einer SOA setzen nicht bei den einzelnen Systemkomponenten an, sondern denken in
Geschäftsprozessen, denen sich bestimmte Dienste und diesen wiederum bestimmte Applikationen,
Schnittstellen und Hardware zuordnen lassen. Der ESB sorgt dann dafür, dass die beteiligten Systeme
einander ihre Services gegenseitig zur Verfügung stellen können – und zwar außerhalb des Codes der
Anwendungen. Der Bus übernimmt das Handling der Kommunikation zwischen den Services, die
Vermittlung zwischen verschiedenen Transportprotokollen und Datenformaten und die Identifizierung
sowie Verteilung von Geschäfts-Events.
Es gibt verschiedene Gründe, warum der Auszeichnungssprache XML in einer serviceorientierten
Architektur eine besondere Bedeutung zukommt. So liegen beispielsweise bereits 40 Prozent der
Daten, die jeden Tag weltweit erzeugt werden, im XML-Format vor. Außerdem setzen viele Behörden
seit dem vergangenen Jahr auf XML als Standard für die Speicherung sensibler Daten.
Die Stärke der Sprache ist ihre Trennung zwischen der Darstellung und den Daten selbst; außerdem
ist sie ist hersteller-, system- und plattformunabhängig. Aus dieser Lingua franca gingen im
vergangenen Jahrzehnt viele industriespezifische Dialekte und Präzisierungen hervor, beispielsweise
XSD-Schema-Definitionen oder XMLNS-Name-Spaces, um sich eindeutig ausdrücken zu können. Selbst
komplexe, hoch strukturierte und wiederholbare Informationseinheiten lassen sich in Form von
XML-Nachrichten übertragen. Damit erfüllt die Auszeichnungssprache alle Voraussetzungen für den
Einsatz in einer SOA: XML-Daten unabhängig vom Programmiermodell und der Plattform auszutauschen.
Mithilfe von Webservices, die ebenfalls XML nutzen, lassen sich Funktionsaufrufe über
Applikations-, System- und Unternehmensgrenzen hinweg tätigen. Wird eine neue Auszeichnungssprache
auf der Grundlage von XML definiert, ist sie sofort Bestandteil eines Gesamtgebäudes, sodass
Entwickler sich um Fragen der Kompatibilität und die Möglichkeiten eines Datenaustauschs keine
besonderen Gedanken mehr machen müssen. Letztlich führen diese Vorteile zu einer Zeit- und
Kostenersparnis, von der Anwenderunternehmen und Anbieter gleichermaßen profitieren.
Allerdings stellt der Einsatz von XML in einer SOA die Entwickler auch vor neue
Herausforderungen. Einerseits erweisen sich etablierte Sicherheitsmechanismen für XML-Daten als
unzureichend, weil die Sprache keine nativen Security-Mechanismen mitbringt. Hier ist also
zusätzlicher Aufwand erforderlich, um die vorgegebenen Sicherheitsstandards im Unternehmen
aufrechtzuerhalten. Andererseits führt der universelle Ansatz von XML dazu, dass die Sprache sehr "
textlastig" ist und infolgedessen bei der Übertragung eine hohe Bandbreite und bei der Verarbeitung
eine hohe Rechenleistung erfordert.
Zunächst wird eine entsprechende Nachricht nämlich von einem so genannten XML-Parser gedeutet,
dann wird das Format auf Einhaltung des Schemas geprüft, eventuell umformatiert und für die interne
Verarbeitung vereinfacht. So lassen sich beispielsweise nicht relevante Attribute und Name-Spaces
entfernen. Schließlich werden digital signierte oder verschlüsselte Inhalte verifiziert und
entschlüsselt, außerdem lassen sich die Zugriffsrechte für bestimmte Webservices-Aufrufe an dieser
Stelle überprüfen. All diese Informationen müssen in der XML-Nachricht hinterlegt sein, eine
Tatsache, die den vergleichsweise geringen Anteil der Nutzdaten an der gesamten XML-Nachricht
erklärt. Diese Situation führt dazu, dass ein Applikationsserver einen wesentlichen Teil seiner
Leistung für die Verarbeitung von XML-Daten aufbringen muss, statt seine Ressourcen den Anwendungen
zur Verfügung stellen zu können. Die klassische Lösung dieses Problems wäre die horizontale
Skalierung. Doch dieser Ansatz ist zeitintensiv und verursacht zusätzliche Kosten.
Schließlich gilt es beim Einsatz von XML in einer SOA noch einen dritten Punkt zu bedenken: Eine
SOA besteht nicht nur aus Webservices und damit XML-Daten. Vielmehr müssen auch bereits vorhandene
Systeme, Nachrichtenformate und Protokolle integriert werden – und zwar einfach und schnell. Hier
geht es einerseits um eine Konvertierung von Datenformaten und Protokollen, aber auch um die
Integration unternehmenskritischer Systeme. Die Entwickler dieser Anwendungen konnten unter
Umständen gar nicht davon ausgehen, dass eines Tages dank Webservices und SOA ein direkter Zugriff
darauf aus unsicheren Umgebungen möglich wird.
Für viele dieser Probleme gibt es softwaregestützte Lösungen. Seit einiger Zeit gewinnen jedoch
hardwarebasierende Ansätze zunehmend an Bedeutung: so genannte SOA-Appliances. Beispielsweise
bietet IBM mit Websphere Datapower ein solches Gerät an. Diese Art von Spezialrechnern ergänzen
ähnlich wie Firewalls oder Router die IT-Infrastruktur und entlasten Netzwerke und Server.
SOA-Appliances lassen sich auch als ein Stück Hardware gewordene Middleware bezeichnen. Sie bieten
ESB-Funktionalität und übernehmen einen Teil der XML-Verarbeitung, die bislang durch Software
erledigt wurde. Jede Appliance wird im Formfaktor 1U geliefert, ist also Rack-fähig, und lässt sich
über einen integrierten Ethernet-Adapter ins Netz einbinden.
Nimmt eine Applikation über das Internet eine Transaktion entgegen, leitet sie diese an die
Backend-Systeme weiter. Bei der Übertragung wird die Nachricht in mehrere TCP/IP-Pakete aufgeteilt,
die ein Router über verschiedene Netzverbindungen an ihr Ziel weiterleitet, sofern eine
zwischengeschaltete Firewall dies erlaubt hat. Eine SOA-Appliance ist für Router und Firewalls ein
Ziel, das den Inhalt der Gesamtnachricht bearbeitet, nicht nur den Inhalt einzelner Pakete. Das
Ergebnis aus der Bearbeitung der Nachricht bestimmt wiederum, an welches Zielsystem die Nachricht
anschließend weitergereicht wird. Die SOA-Appliance leistet also ein fachliches Routing der
Nachricht, die dabei auch einer XML-spezifischen Sicherheitsüberprüfung unterzogen wird.
So gibt es beispielsweise SOA-Appliances, denen ausschließlich eine Funktion als Beschleuniger
zukommt: Sie entlasten die Applikationsserver von der XML-Verarbeitung, indem sie etwa eine
Syntaxanalyse vornehmen, XML-Daten komprimieren, das XML-Schema überprüfen oder die Nachricht
mithilfe der Anfragesprache Xpath ansprechen und weiterleiten. Solche Aufgaben erledigen Appliances
viel schneller und effizienter als eine Softwarelösung.
Andere Appliances beschleunigen nicht nur die XML-Verarbeitung, sondern übernehmen auch
zusätzliche Sicherheitsaufgaben. Denn spätestens dann, wenn ein Unternehmen seine
geschäftskritischen Systeme und die Infrastruktur anderer Abteilungen oder die von Partnern
integriert, kommen auf eine SOA-Umgebung neue Anforderungen zu: Service-Level-Monitoring sowie
Sicherheits- und Zugriffskontrollen. Mit SOA-Appliances erreicht eine IT-Organisation die
erforderliche Datensicherheit und kann Security-Richtlinien für XML-basierende Webservices
durchsetzen. Hierzu gehören selbstverständlich XML-Verschlüsselung, Filterung und digitale
Signaturen, aber auch Webservices-Security und XML-Zugriffskontrollen. Diese Appliances
unterstützen auch in sicherheitsrelevanten Umgebungen gängige Protokolle wie LDAP, Radius, Kerberos
oder SAML. Darüber hinaus bringen sie alle Funktionen mit, die für die Integration in
Public-Key-Infrastrukturen erforderlich sind.
Im Hinblick auf eine Integration von geschäftskritischen Altsystemen in eine SOA kommt den
Appliances ebenfalls eine große Bedeutung zu, denn mit bestimmten Modellen dieser dedizierten
Rechner lässt sich die Integration von Anwendungen und Systemen flexibler gestalten. Damit
Unternehmen beispielsweise ihre Mainframes in die SOA- und Webservices-Welt einbinden können,
müssen sie zunächst Zugriffskontrollen zum Schutz der abgeschotteten Applikationen einrichten. Dies
kann einiges an Entwicklungsaufwand erfordern. SOA-Appliances können hier die IT-Organisation von
solchen Aufgaben entlasten, da sie die einfache Integration von Großrechnern in eine SOA
ermöglichen. Sie dienen dabei als Übersetzer zwischen binären, Klartext- und
XML-Nachrichtenformaten und wandeln auch Protokolle um. Sie übernehmen also die Aufgaben
traditioneller EAI-Techniken (Enterprise Application Integration). Externe Nutzer wie
Geschäftspartnern oder Kunden lassen sich dadurch beispielsweise ohne in Cobol verfasste Remote
Procedure Calls an Backend-Anwendungen anbinden.
Erste IBM-Kunden können nach Angaben des Herstellers mit solchen Appliances bereits Erfolge
vorweisen. So nutzt ein großer Finanzdienstleister vier "Websphere Datapower SOA-Appliances", um
seinen Geschäftspartnern neue Services anbieten zu können. Das Projekt hätte ansonsten zwei Dutzend
Server erfordert. Durch das einfachere Deployment erwartet der Finanzdienstleister eine
Amortisierung bereits nach einem halben Jahr. Ein anderer Finanzdienstleister wiederum bedient sich
einer Appliance zur Integration seines Großrechners. Das Deployment der resultierenden Lösung
konnte zehnmal schneller erfolgen als mit einer bislang eingesetzten, selbstentwickelten Software,
deren Wartung und Weiterentwicklung sich als zunehmend schwierig erwies. Darüber hinaus konnte das
Unternehmen durch den Appliance-Ansatz die Kosten senken und die Prozesse zum Schutz vor
Betrugsversuchen schneller aufsetzen. Der Finanzdienstleister erwartet, dass die nun gewählte
Lösung sich bei künftigen neuen Services als weniger fehleranfällig erweisen wird als die zuvor
genutzte.
Fazit
Um die Vorzüge von SOA-Appliances ausschöpfen zu können, müssen sie sich in entsprechende
Managementlösungen und XML-Entwicklungsumgebungen einbinden lassen. Gerade in puncto Integration
bei unternehmensweiten SOA-Projekten ist es auch wichtig, dass die Appliances die Anforderungen
unterschiedlicher Nutzergruppen befriedigen können. Denn Applikationsspezialisten haben eine andere
Sichtweise als Sicherheitsarchitekten, die Mitarbeiter der IT-Operations wiederum eine andere als
die Kollegen des Netzbetriebs. Erreichen lässt sich dies durch verschiedene Management-Interfaces
und Funktionen.
Lesen Sie mehr zum Thema
