Virtualizing TCP

You can simulate a TCP connection with a virtual service, also known as a stub.

About this task

The following instructions apply to general-purpose TCP transports. Although some TCP-based transports have their own logical and physical transport types, the general steps are the same.

Procedure

In the Architecture School perspective, create a logical TCP connection resource (Creating logical TCP connections) and a physical TCP server resource Creating physical TCP servers. See Options for creating test resources.
Create virtual services (message-based stubs) to represent these resources. See Creating and modifying message-based stubs. To create stubs by using the Recording Studio, see Recording TCP traffic.
You can run stubs directly in Rational Integration Tester, or publish them to Rational Test Control Panel and run them there. See Publishing and running stubs.
Use one of the following methods to configure the system under test so that it sends messages to the stub. If you recorded TCP messages in the process of creating the stub, notice that these choices are similar. Differences between recording and virtualizing include the fact that packet capture does not allow virtualization, and no direct connection option is available for recording.
Figure 1 shows a network with no virtualization.
Figure 1. No proxy, no virtualization
- The simplest method is to configure the Rational Integration Tester HTTP/TCP proxy as a reverse TCP proxy (see Figure 2 and Figure 3). Change the host name and port of the endpoint that is used by the system under test, such that the system sends traffic to the host and the port that is specified in the bind attribute of the forwarding rule for the proxy. When the stub is running, the messages are dynamically routed to the stub. When the stub is not running, the messages are sent to the live system, if available. See Configuring a HTTP(S) reverse proxy or TCP port forwarding.
  Figure 2 shows the system under test addressing a message to the host system where the proxy server is running. In the absence of a running stub, the proxy server then re-addresses the message to the live system, as specified in the bind attribute of the forwarding rule for the proxy.
  Figure 2. Proxy server changes the destination host to the live server
  
  Note: Many TCP applications make a single permanent connection to the live system and send multiple messages across it. Ensure that your stub is started before the application connects to the TCP proxy. Failure to do so will result in the application making a connection to the live system and the stub will not be used.
  
  Figure 3 again shows the system under test sending a message to the proxy host. This time a stub is running, so the proxy server reroutes the message to the stub, based on the rule that the stub created on the proxy. You can see those rules on the Agents page in Rational Test Control Panel. For more information, see Viewing running agents.
  Figure 3. Proxy server changes the destination host to the stub
- Another alternative is to configure the system under test to connect directly to the stub (see Figure 4). This process requires assigning a fixed port number to the transport that the stub uses. To do so, go the Physical view of the Rational Integration Tester Architecture School perspective, right-click the TCP server resource, and click Open physical resource. On the Server page, Socket Overrides section, enter a number for the Port field that does not conflict with anything on the host where the stub will run. That host is one of the following servers:
  - The server where Rational Integration Tester is running
  - If running through Rational Test Control Panel, the server where the Rational Integration Tester Agent is running
  For more information about socket overrides, see Creating physical TCP servers.
  Next, configure the system under test to use as its endpoint the host and port number of the server where the stub will run, rather than using the host and port for the live system. Be aware of the following limitations:
  - This method does not route messages dynamically. When the stub is not running, connections fail.
  - All traffic for the specified endpoint is routed to the stub. This method does not filter the traffic based on operations.
  - With other methods, you can have multiple Agents and the stub can run on any Agent that is registered with Rational Test Control Panel for the correct environment. With this method, if you use Rational Test Control Panel, you must configure the system under test to use the exact machine on which the Agent runs the stub.
  Figure 4 shows a direct connection from the system under test to the system that hosts the stub. No messages go to the live system; they are all addressed and sent directly to the stub. To filter the messages, use the proxy server described earlier.
  Figure 4. Direct connection to stub
  
  Figure 5 shows that the connection fails if the stub is not running, because the client connects directly to the port where it expects the stub to be running. To avoid this problem, use the proxy server described earlier.
  Figure 5. Direct connection to stub that is not running

Results

The dependency for the system under test is now virtualized. Traffic that matches the operations that are specified in the stub (or all traffic, in the case of direct connection to the stub) now receives virtualized responses instead of connecting to the live system.

Feedback