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.
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.
Remote-Stub-Server sind für IBM Rational Service Tester for SOA Quality nicht verfügbar.
Für Leistungstests können Sie Stub-Server auf fernen Computern implementieren, auf denen Agent Controller auf Windows und Linux-Plattformen ausgeführt wird. So können Sie die Arbeitslast auf Ihrem lokalen Computer verringern oder verschiedene Netzkonfigurationen mit mehreren Stub-Servern testen.
Sie können Stub-Server auch als Teil eines Leistungszeitplans implementieren.