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.

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.

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.

SOA-Entwicklung

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 verschiedenster 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.

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.