Service stubs are simulations
of an actual service, which can be used to functionally replace the
service in a test environment. A stub server replaces the actual application
server.
From the point of view of the client application, the
service stub looks identical to the actual service that it simulates.
To use a service stub in replacement of the actual service, you must
be able to replace the URL of the original service in the client application
with the URL of the stub server.
Important: For version
8.7 and later, you cannot use the schedule option of IBM® Rational® Performance Tester to
deploy stub servers remotely. If you have already deployed stub servers
remotely, you must install IBM Rational Service Tester for SOA Quality or Rational Performance Tester on
those computers and then deploy the stub servers locally.
Use case examples
There are several cases
where it can be useful to deploy a stub services instead of using
the actual services for your tests:
- If you are testing a local service that uses data from another
remote service, you might need to inject specific content to the service
under test from the remote service. You can simulate the remote service
with a service stub to ensure that the local service responds properly
to some specific input.
- Some commercial services charge users for each call. If you are
testing such a service, you can develop and debug your test against
a stub service, which is based on the WSDL of the actual service,
without being charged by the commercial service.
- During integration of a large application involving multiple clients
and services, some services might not yet be operational, although
their WSDL specifications are available. You can simulate the missing
services with service stubs, which will allow you to proceed with
the integration work.
Service stub architecture
You create a service
stub by providing an existing WSDL specification. The service stub
is generated with the exact same ports and bindings as the original
service so that it can be addressed with exactly the same interface.
Each operation in the service returns a default response of the type
defined by the WSDL.
You can edit the service stub in the stub
editor to change the default response or to create conditional responses
that simulate the actual responses of the original service.
When
you have finished editing the service stub, you can deploy it on a
local stub server, which runs in the workbench. The stub server simulates
an actual application server and can host multiple service stubs.
You control the stub server from the stub monitor view.
Finally,
to use the service stub instead of the original service, you change
the URL used by the client application to point to the local stub
server instead of the original application server. This URL, as well
as the WSDL of the service stub, is provided in the stub monitor view.