Wie funktioniert Service Virtualisierung?

Zur Veranschaulichung, wie Service Virtualisierung im konkreten Anwendungsfall zum Einsatz kommen kann, zunächst ein Beispielszenario:

3 Schritte zum virtuellen Abbild:

1. Zunächst wird ein System aufgebaut, indem die ersten verfügbaren Komponenten verwendet werden. Alle anderen benötigten Komponenten werden virtualisiert. 
2. Dann können nacheinander neue Komponenten in das System eingeführt werden, die virtuellen Komponenten werden ersetzt. In dieser Phase können inkrementelle Integrationstests durchgeführt werden. 
3. Schließlich wird das Stadium erreicht, indem alle Komponenten zur Verfügung stehen. So können dann vollständige End-To-End Tests durchgeführt werden, da während des gesamten Entwicklungsprozesses schrittweise auf die Phase hingearbeitet wurde. 

Vorgehen: zwei Arten

Die Virtualisierung kann nach den folgenden zwei Vorgehensweisen erfolgen:

• Aufzeichnung des Netzwerk-Traffics => Antwortverhalten
• Ohne Aufzeichnung anhand des Imports von Service-Informationen (Schnittstellenbeschreibungen [WSDL & REST]), wenn eine Aufzeichnung nicht möglich ist.

Es schließt sich die Anpassung und Erweiterung des virtuellen Stubs – beispielsweise als eine Antwort auf Anfragen mit festgelegten Fehlermeldungen an.

Mit der Service Virtualisierung lassen sich Nachbildungen von echten Services erstellen.

Dabei wird das Antwortverhalten der zu virtualisierenden Services simuliert. Das Verhalten ist frei konfigurierbar und lässt sich zu jeder Zeit anpassen, sei es beispielsweise durch neue Antworten, ebenso bewusst fehlerhafte Rückmeldungen, Programmlogiken oder einfache Rückgabewerte (true, false). Dessen Komplexität muss nicht denen der echten Services entsprechen. 

Nicht-Verfügbarkeiten von Services werden durch aufgezeichnete oder synthetisch generierte Antwortdatensätze simuliert. 

Hauptanwendungsfälle

Für den Einsatz der Service Virtualisierung existieren mehrere Hauptanwendungsfälle:

1. Services: Diese stehen nicht dauerhaft zur Verfügung oder werden nicht administriert.
2. (Test-)Umgebung(en) werden umgebaut. Dadurch stehen Services nicht zur Verfügung oder Testdaten müssen überarbeitet werden. 
3. Trainingsinstanzen

Im Detail:

Zu beachten ist, dass virtualisierte Services nicht zu 100% das Verhalten einer realen Applikation nachbilden können! Somit ist es kein Webservice-Ersatz! Es soll das Verhalten soweit nachgestellt werden, dass die technische Schnittstelle dem realen System entspricht und getestet werden kann, und erste aussagekräftige Integrationstests durchführen zu können.  

Strategisch ist die Service Virtualisierung auch wertvoll, da es bis auf den Abnahmetest (entspricht nicht den Anforderungen) in allen Teststufen und Phasen eingesetzt werden kann. Das Risiko zur Einführung von Komponenten kann reduziert werden, da die Schnittstellen vorab getestet werden. Für Trainingsinstanzen kann die Virtualisierung ebenfalls genutzt werden. Dabei wird nicht auf die Infrastruktur zugegriffen. Somit entsteht kein Einfluss auf die Produktionssysteme. 

Da die erstellten (virtuellen) Stubs individuell konfigurierbar sind, kann die Service Virtualisierung auch zur Prüfung von Lastszenarien eingesetzt werden, indem man für jeden einzelnen Stub die Antwortzeiten einstellt. Jedoch ist zu beachten, dass das Verhalten des Live Systems nur vage bestimmt werden kann. Daher wird die Service Virtualisierung in diesem Fall nur als Notlösung eingesetzt, wenn benötigte Dienste nicht genutzt werden können (zum Beispiel, wenn die Umgebung der Schufa aus dem Testsystem heraus nicht erreichbar ist). 

Fazit:
Service Virtualisierung verringert den Aufwand der Erzeugung verfügbarer Testdatensets auch insofern, als dass fachliche/prozessuale Änderungen im Projekt direkt durch eine neue Testdatenaufzeichnung abgebildet werden können (statt sämtlicher Änderungen in den bestehenden Mock einpflegen zu müssen).