Service-Stubs – Übersicht

Service-Stubs sind Simulationen eines tatsächlichen Service, mit denen der Service in der Testumgebung funktional ersetzt werden kann. Ein Stub-Server ersetzt den tatsächlichen Anwendungsserver.

Für die Clientanwendung stellt sich der Service-Stub wie der tatsächliche simulierte Service dar. Um statt des tatsächlichen Service einen Service-Stub verwenden zu können, müssen Sie die URL des Ursprungsservice in der Clientanwendung durch die URL des Stub-Servers ersetzen.

Wichtig: Für Version 8.7 und höher kann die Zeitplanoption von IBM® Rational Performance Tester nicht zum Implementieren von Stub-Servern über Fernzugriff verwendet werden. Wenn Sie bereits Stub-Server über Fernzugriff implementiert haben, müssen Sie IBM Rational Service Tester for SOA Quality oder Rational Performance Tester auf den betreffenden Computern installieren und die Stub-Server dann lokal bereitstellen.

Fallbeispiele verwenden

Es gibt verschiedene Fälle, in denen die Implementierung von Stub-Services anstelle der tatsächlichen Services für Ihre Tests sinnvoll ist:
  • Wenn Sie einen lokalen Service testen, der Daten aus einem anderen Remote-Service verwendet, müssen Sie möglicherweise bestimmte Inhalte aus dem Remote-Service in den zu testenden Service aufnehmen. Sie können den Remote-Service mit einem Service-Stub simulieren, um sicherzustellen, dass der lokale Service auf bestimmte Eingaben richtig antwortet.
  • Einige kommerzielle Services verlangen von Benutzern für jeden Aufruf Gebühren. Wenn Sie einen solchen Service testen, können Sie Ihren Test auf Basis eines Stub-Service entwickeln und testen, der auf der WSDL des tatsächlichen Service basiert, ohne dass Sie vom kommerziellen Service dafür belastet werden.
  • Bei der Integration einer umfangreichen Anwendung mit mehreren Clients und Services funktionieren einige Services möglicherweise nicht, obwohl die WSDL-Spezifikationen verfügbar sind. Sie können in einem solchen Fall die fehlenden Services durch Service-Stubs simulieren, sodass Sie den Integrationsprozess fortsetzen können.

Service-Stub-Architektur

Sie können einen Service-Stub erstellen, indem Sie eine bestehende WSDL-Spezifikation angeben. Der Service-Stub wird dann mit exakt denselben Ports und Verbindungen wie der Ursprungsservice generiert, sodass er mit derselben Schnittstelle adressiert werden kann. Jede Operation im Service gibt eine Standardantwort des in der WSDL definierten Typs zurück.

Sie können den Service-Stub im Stubeditor bearbeiten, um die Standardantworten zu ändern oder bedingte Antworten zu erstellen, mit denen die tatsächlichen Antworten des Ursprungsservice simuliert werden können.

Wenn Sie die Bearbeitung des Service-Stubs abgeschlossen haben, können Sie den Stub auf einem lokalen Stub-Server in der Umgebung implementieren. Der Stub-Server simuliert einen tatsächlichen Anwendungsserver und kann mehrere Service-Stubs betreiben. Die Steuerung des Stub-Servers erfolgt über die Sicht "Stub-Überwachungsprogramm".

Um statt des Ursprungsservice einen Service-Stub verwenden zu können, müssen Sie die von der Clientanwendung verwendete URL ändern, damit diese auf den lokalen Stub-Server statt auf den Ursprungsanwendungsserver verweist. Diese URL und die WSDL des Service-Stubs werden in der Sicht "Stub-Überwachungsprogramm" bereitgestellt.


Feedback