|
|
|
Auswahl und Betrieb einer Infrastruktur für serviceorientierte Architekturen |
manage it, September 2006
Fundament für Dienste
Eine serviceorientierte Architektur – kurz SOA – ist das Konzept für IT-Systemlandschaften der Zukunft. Doch neben der Entwicklung entsprechender Dienste gibt es für Unternehmen noch zwei weitere Hürden auf dem Weg zur flexiblen IT zu überwinden: die Auswahl und den Betrieb einer geeigneten SOA-Infrastruktur. Dabei sollte die Integration bestehender Anwendungen im Vordergrund stehen.
Eine serviceorientierte Architektur versucht, eine IT-Landschaft als eine Sammlung von Diensten zu betrachten, die untereinander agieren. Durch die Verknüpfung von Diensten können Unternehmen dort ihre betrieblichen Prozesse abbilden. Ändert sich ein Geschäftsprozess, ist dies durch eine Anpassung des Workflows zwischen den Diensten schnell in der IT-Infrastruktur umgesetzt. Auf diese Weise erhalten Unternehmen einen hohen Grad an Flexibilität, da sich neue Anforderungen an das tägliche Geschäft schnell in der IT realisieren lassen. Gleichzeitig sind einzelne Dienste und ganze Workflows wieder verwendbar und können zu neuen Workflows kombiniert werden. Das Managementkonzept einer SOA strebt also eine an den gewünschten Geschäftsprozessen ausgerichtete IT-Infrastruktur an, die flexibel auf veränderte Anforderungen im Geschäftsumfeld reagieren kann. Dieses Managementkonzept setzt dabei ein Systemarchitekturkonzept voraus, das fachliche Dienste und Funktionalitäten in Form von Services anbietet.
So schön und einfach die Theorie ist, so komplex sieht es in der Praxis aus. Denn viele gewachsene Unternehmensanwendungen sind genau das Gegenteil von flexibel und standardbasiert, nämlich starr und proprietär. Die Änderung eines »hart kodierten« Workflows innerhalb einer Applikation ist nur mit unverhältnismäßig hohem Aufwand möglich und Anwendungen verschiedener Hersteller miteinander zu verbinden oft ein Ding der Unmöglichkeit.
Basistechnologie Middleware.
Dem Thema der Anwendungsintegration haben sich bereits in den 90er Jahren objektorientierte Middleware-Architekturen wie beispielsweise eine CORBA (Common Object Request Broker Architecture) angenommen. Diese definiert plattformübergreifende Protokolle und Dienste und wird von der Object Management Group (OMG) entwickelt. Doch galt CORBA in der Vergangenheit oft als zu langsam und nicht kompatibel genug, wenn es um verschiedene Implementierungen und Standards ging. Allerdings ist eine CORBA ebenso wie Enterprise Java Beans (EJB) nichts anderes als eine dienstbasierte Technologie, auf deren Basis eine SOA aufgebaut werden kann.
Heute kommen in den meisten Fällen jedoch Web Services auf der Basis von SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und UDDI (Universal Description, Discovery and Integration) zum Einsatz, um eine SOA aufzubauen.
Dies erklärt auch Jürgen Kirschbaum, Produktarchitekt beim IZB Informatik-Zentrum in München: »Eine SOA ist heute eine sinnvolle Kombination aus vorhandenen und bewährten Techniken. Diese werden um eine neue Komponente namens Web Services erweitert, die standardisierte Schnittstellen besitzt. Dazu gibt es Integrationskomponenten, die unterschiedliche Backend-Systeme anbinden. Middleware war für Unternehmen schon immer ein Thema und jetzt gibt es mit einer SOA auf Basis von Web Services dafür einen offenen Standard«.
Infrastruktur.
Um Web Services zu einer SOA kombinieren und anbieten zu können, benötigen diese eine Infrastruktur, auf der die Dienste ablaufen und die sie steuert. Aktuell gibt es vier große Hersteller, die so genannte SOA-Stacks im Programm haben: IBM, Microsoft, Oracle und SAP. Aber auch spezialisierte Unternehmen wie beispielsweise BEA, die ebenfalls SOA-Stacks anbieten, gehen von demselben Architekturmodell aus, das aus fünf Schichten besteht.
Auf unterster Ebene eines SOA-Stacks liegen dabei Hardwareressourcen wie Datenspeicher (Storage), das Netzwerk und Rechenleistung, die auch virtualisiert über eine Grid-Infrastruktur bereitgestellt werden können. Darüber liegen auf der Anwendungsschicht alle Datenquellen und vorhandenen Applikationen im Unternehmen. Hierzu gehören eingesetzte Standardsoftware wie ERP- und CRM-Systeme ebenso wie Legacy-Software und speziell für das Unternehmen entwickelte Anwendungen.
Diese Systeme und Datenquellen verbindet eine Integrationsschicht. Sie besteht aus einer Kommunikationsinfrastruktur – auch Enterprise Service Bus (ESB) genannt – die darunter liegende Anwendungen ansprechen kann und darüber liegende Services miteinander verbindet. Im diesem Service-Layer finden sich dann alle Dienste, die im Rahmen einer SOA zum Einsatz kommen.
Um Geschäftsprozesse über Interaktionen verschiedener Dienste abbilden zu können, kommt schließlich der so genannte Orchestration-Layer – die oberste Schicht des SOA-Stacks – zum Einsatz. Hier werden Workflows definiert, die letztendlich den Ablauf einer Anwendung darstellen und von Client-Applikationen oder anderen Diensten aufgerufen werden.
Unterschiede.
Während sich das Architekturmodell der Anbieter von SOA-Stacks gleicht, unterscheidet sich deren Implementierung in der Praxis jedoch zum Teil erheblich. Das weiß auch Jürgen Kirschbaum, der sich als SOA-Spezialist des IZB Informatik-Zentrum in München seit langer Zeit mit den Basistechnologien einer SOA beschäftigt und verschiedene Produkte in dem Bereich evaluiert: »Der größte Unterschied zwischen den SOA-Stacks liegt in der Integration verschiedener Backend-Systeme, die jeder Hersteller unterschiedlich bedient. Denn nicht jeder Hersteller bietet hier alles an. Während beispielsweise die Unterstützung von SAP als Backend-System ein Muss ist, sieht es bei anderen Anwendungen teilweise düster aus. In diesem Fall muss der Anwender dann selbst Hand anlegen und spezielle Adapter entwickeln (lassen)«.
Bei der Auswahl eines SOA-Stack muss also vor allem die Frage nach den zu integrierenden Backend-Systemen im Vordergrund stehen. Da diese für jeden Anwender individuell sind, kann es hier keine eindeutige Empfehlung geben. Wenn in der Praxis nur eine SAP-Installation als Dienst zur Verfügung gestellt werden soll, dann ist sicher SAPs SOA-Stack das Produkt der Wahl. Wenn aber weitere Legacy-Systeme angebunden werden sollen, dann können andere Architekturen sinnvoller sein. So zeichnet sich aktuell der SOA-Stack von IBM durch eine besonders hohe Flexibilität aus. Dies bestätigt auch Kirschbaum: »Meiner Meinung nach hat die IBM hier momentan die Nase vorn, da deren SOA-Produkte von der Architektur und der Anbindung von Backend-Services her am flexibelsten sind. Zudem unterstützen die Produkte so wichtige Funktionen wie Billing-Services, die eine Abrechnung der Nutzung von Diensten überhaupt erst ermöglichen. Ein weiteres großes Plus ist der verwendete Enterprise Service Bus »Websphere MQ und Websphere Application Server«. Denn diese Produkte sind sehr verbreitet auch beim IZB Informatik-Zentrum ist in diesem Bereich viel Know-how vorhanden.«
Kosten sparen.
Was der Aufbau einer SOA-Infrastruktur kostet, lässt sich nicht einfach beziffern. Denn so heterogen wie die Systemlandschaft eines Unternehmens so unterschiedlich sind die Anforderungen an eine SOA-Infrastruktur. Wenn sinnvoller Weise zunächst mit einem kleinen SOA-Projekt erste Erfahrungen gesammelt werden sollen, sind die Investitionen in die benötigte Hard- und Software noch überschaubar. Virtualisierte Server und Storage können hier zudem helfen, die Infrastrukturkosten zu senken. Wichtig ist bei der Auswahl der SOA-Infrastruktur, dass sie später einfach und leicht skaliert. Die größte Investition werden Unternehmen jedoch wahrscheinlich in das Know-how tätigen müssen. Denn praktische Erfahrungen mit dem Aufbau und Betrieb einer SOA haben heute nur wenige. Hier können spezialisierte Infrastruktur-Anbieter helfen, die über jahrelange Erfahrung beim Einsatz der Basistechnologien einer SOA verfügen.
Dabei gibt es verschiedene Szenarien, wie ein Unternehmen seine SOA-Infrastruktur outsourcen kann. So kann der Dienstleister beispielsweise im Projektgeschäft nach der besten Lösung für den Kunden suchen und der Kunde gibt alles außer seinen Geschäftsprozessen an den Dienstleister ab. Die Geschäftslogik bleibt beim Kunden und alles, was mit der IT-technischen Realisierung zusammenhängt, ist Aufgabe des IT-Service-Providers. Dies bietet dem Kunden größtmögliche Flexibilität bei der Auswahl und dem Aufbau seiner SOA-Infrastruktur. Gleichzeitig profitiert er von der performanten, verfügbaren und sicheren Infrastruktur eines spezialisierten Rechenzentrums.
Weiteres Rationalisierungspotenzial bietet sich, wenn der Kunde eine vorhandene SOA-Infrastruktur mitnutzen kann. Denn diese muss vom Rechenzentrum nur einmal betrieben werden und ermöglicht dann verschiedenen Kunden den Zugriff auf unterschiedliche Backend-Systeme. Ob sich dies in der Praxis umsetzen lässt, hängt immer von der spezifischen Systemlandschaft eines Unternehmens ab, die »SOA-fiziert« werden soll. Als Outsourcing-Dienstleister verfügt das IZB Informatik-Zentrum über langjährige Erfahrung und das notwenige Know-how, um SOA-Infrastrukturen zu betreiben. »Gleichzeitig haben wir eine komplett virtualisierte Hardware-Infrastruktur, um eine SOA gemeinsam mit dem Kunden in kurzer Zeit aufsetzen zu können,« führt Dr. Walter Kirchmann, Geschäftsführer des IZB Informatik-Zentrum, aus. »Und auf Grund unserer Kundenstruktur als Unternehmen der Sparkassen-Finanzgruppe legen wir sehr großen Wert auf Sicherheit – selbst wenn Performance und Sicherheit oft im Widerspruch zueinander stehen«.
Friedrich G. Peters
Der Autor ist freier Journalist in München
"SOA ist heute eine sinnvolle Kombination aus vorhandenen und bewährten Techniken."
Modell eines SOA-Stacks
Quelle: Trivadis AG
|
|
 |
 |
 |
|
|
Um Web Services zu einer SOA kombinieren und anbieten zu können, benötigen diese eine Infrastruktur, auf der die Dienste ablaufen und die sie steuert. Die wichtigsten Anbieter wie IBM, Microsoft, Oracle, SAP oder BEA gehen von demselben, aus fünf Schichten bestehenden Architekturmodell aus.
|
|
|
|
