Service-orientierte Architekturen sind mittlerweile erwachsen geworden. Doch es gilt in SOA-Projekten zu klären, wie sich Anwendungsservices in eine IT-Plattform einfügen lassen. Die Plattform der Wahl ist dabei immer öfter eine virtualisierte Umgebung. Es stellt sich also die Frage, wie man SOA-Systeme in einer virtualisierten Welt abbilden kann und wo die Verbindungspunkte liegen.
Fazit
Der Aufbau einer Service-orientierten Infrastruktur (SOI), die auf Virtualisierungstechnik basiert, ist ein erster Schritt zur erfolgreichen Implementierung einer SOA auf Applikationsniveau. Eine solche SOI bietet Schlüsselmechanismen (verteilte Ressourcen-Steuerungen, Clustering, Ressourcen-Pools, rasche Bereitstellung von Services etc.) für erste Messungen und Antworten auf das Verhalten eines virtuellen Systems.
SOA-Projekte können jetzt eine Anwendung oder einen Service-Container nutzen, der vollständig in eine virtuelle Plattform integriert ist. Mit einem entsprechenden Management-Tool lassen sich Auslastung, Lastverteilung und die optimale Serviceplatzierung in der virtualisierten Umgebung realisieren.
Was man sich vor Projektbeginn fragen sollte
Die folgenden Punkte sollten auf Architekturniveau diskutiert werden, um zu verstehen, wie sich SOA und Virtualisierung ergänzen können:
1. Sollen SOA-Bestandteile wie Web-Services in einer virtuellen Maschine gemeinsam oder separat angeordnet sein? Für Services, die oft miteinander kommunizieren, bietet sich die gemeinsame Anordnung an. Eine Unterteilung in unterschiedliche Container oder virtuelle Maschinen ist dann sinnvoll, wenn zwei Services oft auf die gleiche Ressource zurückgreifen.
2. Werden ein oder mehrere Services von einer virtuellen Maschine bereitgestellt?
3. Wie werden Web-Services und Load Balancing über ein Set von identischen Services repliziert?
4. Wie funktionieren Qualitäts- und Response-Government der Web- und SOA-Services?
5. Welche Infrastrukturkomponenten sind für eine SOA erforderlich (Service-Registry, Management-Policies etc.)?
6. Lassen sich diese Komponenten auch virtualisieren?
7. Wie viel Automatisierung ist für die Beschaffung neuer Services und Infrastruktur nötig?
8. Lassen sich die Anforderungen der neuen Services messen? Lassen sich Veränderungen der Infrastruktur vorhersehen?
9. Gibt es Gründe, warum neue Services nicht virtualisiert werden können?
10. Sind die virtualisierten Services dynamisch auf Basis von SLAs zu provisionieren?
11. Können die SOA-Management-Tools die APIs der virtuellen Infrastruktur auch Service-orientiert nutzen, um diese Ressourcen zu kontrollieren?
12. Lassen sich Ressourcen-Pools für unterschiedliche Services-Layer aufbauen, die ihre Wichtigkeit für die Applikationen widerspiegeln?
Gute Voraussetzungen
Gerade die in der SOA realisierte Trennung von Servicekonsumenten und -Providern bietet ideale Voraussetzungen, um die Vorteile der Virtualisierung auszuschöpfen. Dabei können Provider und Consumer von der Virtualisierung profitieren. Auf Consumer-Seite müssen zum Beispiel nicht alle Java-Applikationen von einem Betriebssystem unterstützt werden, sondern können stattdessen auch in einer Java Virtual Machine (JVM) laufen, die ihrerseits mit einem ESX-Hypervisor verbunden ist.
Das gleiche System kann für die Plattform aufgesetzt werden, auf der die SOA-Services liegen. Eine direkte Kommunikation mit der zugrunde liegenden ESX-Server-Software ermöglicht den Informationsaustausch über die verfügbaren Ressourcen. Eine vollständige Betriebssystem-Schicht ist damit nicht mehr notwendig. Die Entfernung des klassischen Betriebssystems vermindert zusätzlich auch die Footprints der virtuellen Maschinen. So sind mehrere Maschinen auf einem einzigen physikalischen Server möglich.
Verbindung mit Altsoftware
Ferner lassen sich auch nur Teile einer SOA-Services-Infrastruktur virtualisieren. Eine solche partielle Virtualisierung ist besonders für Unternehmen sinnvoll, die erst am Anfang von Virtualisierungs- oder SOA-Projekten stehen. Eine Java-Applikation kann beispielsweise mit einem Mainframe über ältere Protokolle kommunizieren und gleichzeitig den Konsumenten SOA-Interfaces anbieten. Dabei können Java und Web-Services auf einer VMware-Infrastruktur laufen, während die Legacy-Systeme auf der ursprünglichen physikalischen Plattform verbleiben. Dieses Prinzip wird bereits heute bei Java-Applikationen, die mit Altanwendungen kommunizieren, angewendet und kann ebenso auf die SOA-Welt übertragen werden.
Bisher hat sich die Plattformdiskussion weitgehend auf den Einsatz von Anwendungen und auf Geschäftsprozesse im SOA-Umfeld beschränkt. Man kann Auswirkungen von SOA und Virtualisierung aber viel allgemeiner sehen. Beide Strategien beeinflussen zum Beispiel auch sehr stark die Entwickler und Experten aus der Qualitätssicherung und von Testabteilungen. Ein Blick auf den SOA-Entwicklungs- und Deployment-Lebenszyklus soll dies verdeutlichen.
Die Architektur bleibt
Obwohl die Basiseinheit einer SOA aus einfachen Business- oder Web-Services besteht, kann die zugrunde liegende technische Infrastruktur komplex und vielschichtig sein. SOA-Services, die Geschäftsapplikationen unterstützen, werden oft als Soap-Schichten um bestehende Funktionen herum implementiert. Diese Funktionen werden weiterhin auf .NET- oder Java-Architekturen gehostet, manchmal sogar auf Legacy-Systemen. Damit umfasst auch die Erstellung von SOA-Services die Entwicklung und den Test von .NET- und Java-Anwendungen. Virtualisierungstechniken unterstützen diese Plattformen bereits seit Jahren. Sie bieten Provisioning für die Konfiguration verschiedener Maschinen und die Möglichkeit, Snapshots von virtuellen Maschinen aufzunehmen.
SOA-Entwickler können Service-Provider, -Consumer und andere Produkte auf unterschiedlichen virtuellen Maschinen hosten. Dies bietet erhebliche Produktivitätsgewinne für die Entwickler, die damit komplexe SOA-Systeme einrichten können, ohne sich um die physikalischen Maschinen oder die Auswirkungen auf andere Entwickler sorgen zu müssen.
Bibliothek für Konfigurationen
Viele Entwicklungsabteilungen greifen für den Einsatz solcher Multi-VM-Systeme auf einen Hardware-Pool zurück. Die Zuordnung dieser vielschichtigen Konfiguration von virtuellen Maschinen zu physikalischen Servern ist nun aber nicht mehr Sache der Entwickler. Mit spezifischen, auf Entwickler zugeschnittenen Virtualisierungstechniken können diese eine Bibliothek von Konfigurationen für Multi-VM-Systeme aufstellen. Dies vermeidet eine Vielzahl an redundanten Konfigurationen, die zum Beispiel nicht mehr genutzt werden, wenn die Tests abgeschlossen sind. Dieses Vorgehen verschafft außerdem dem Qualitäts-Manager die Möglichkeit, Informationen über komplexe SOA-Systeme zurück an die Entwickler zu geben und ihnen eine URL als Verweis auf das gesamte SOA-Setup einer virtuellen Maschine zu übermitteln.
Dynamisierung fordert Leistung
Von Vorteil ist die Virtualisierung und damit die bessere Ressourcennutzung auch deshalb, weil es im SOA-Ökosystem mehr dynamische Anteile als bei traditionellen Anwendungen gibt. Einige Services können beispielsweise in andere Abteilungen des Unternehmens oder sogar zu externen Service-Providern ausgelagert sein. Deshalb ist eine Koordination der unterschiedlichen Beteiligten an der Web-Services-Konversation erforderlich. Auch das Soap-Protokoll zwischen den Servicekonsumenten und -Providern erfordert ein höheres Verarbeitungsniveau als frühere Client-Server-Systeme. Als Folge verbraucht die Infrastruktur mehr Computerleistung.
Bezüglich der Verwaltung SOA-gestützter Systeme geht es jetzt darum, dass man zusätzlich zum Status physikalischer Maschinen, Netze und Speicher auch auf die virtuelle Ausgewogenheit achten muss. Das bedeutet: Mehr Objekte sind zu verwalten und erst recht mehr feingranulare SOA-Services in physikalischen und virtuellen Infrastrukturen. Daraus ergibt sich ein hoher Bedarf zur Automatisierung von Management-Lösungen.
Automatisiertes Provisioning
Ferner gilt es, die Performance von SOA-Services im Auge zu behalten. Weil sie von vielen Anwendungen und Prozessen genutzt werden, ist es schwierig vorherzusagen, ob SOA-Services häufig oder selten verwendet werden. Ebenso schwer ist es zu erfassen, was mit den SOA-Services passiert, wenn sie in neuen Anwendungsfällen zum Einsatz kommen oder wenn interne Implementierungen verändert werden. Werden sie dann überlastet? Können sie alle neuen Anfragen abarbeiten? Einer der ersten Gründe für den SOA-Einsatz, nämlich die Modularität der Services und die Wiederverwendbarkeit, beeinflusst also die Service-Performance. Deswegen ist eine Automatisierung des Service-Provisioning erforderlich.
Automatisiertes Provisioning oder System-Management muss zunächst Funktionen zur Messung der gesamten Systemlast der Maschinen und Services haben. Es muss auch den erforderlichen Perfomance-Level jedes Service steuern können. Diese Policy-abhängigen Funktionen sind normalerweise in einem Management-Tool enthalten. Neue Toolkits erfassen den Status der Virtualisierung genau und können die Ressourcen der virtuellen Infrastruktur anpassen, um Service-Level-Agreements einzuhalten.
Außerdem ist das Hinzufügen neuer Software und Hardware eine Schlüsselfunktion einer virtualisierten SOA-Welt. Das Management-Tool unterweist die virtuelle Infrastruktur, eine neue virtuelle Maschine aufzusetzen, auf die anschließend Anwendungs-Traffic geleitet wird. Wenn Bedarf nach mehr Processing-Leistung entsteht, legt das Management-Tool die zusätzliche virtuelle Maschine still, so dass die Hardwareressourcen unter den verbleibenden virtuellen Maschinen aufgeteilt werden können. Diese Funktion ist eine Kernschnittstelle zwischen SOA und Virtualisierung, die von den Architekten über SLAs definiert sein muss.
Man kann sogar noch einen Schritt weiter gehen. Der ESX-Server selbst lässt sich dynamisch auf die bestehende Hardware setzen, wo vorher kein System existierte. Stufenweise ist es dann möglich, virtuelle Container zur Unterstützung neuer Services aufzubauen. Gleichzeitig erlauben neue JVM-Funktionen eine weitere Verschlankung: Die Installation eines Betriebssystems auf eine virtuelle Maschine wird unnötig. Das vereinfacht das Provisioning, da weniger Komponenten zu installieren und zu konfigurieren sind. (ue)