Over the next few weeks, I will be devoting a series of blog postings to the concept of a message “interceptor” and in particular to the Rational Integration Tester HTTP Proxy. In order to effectively use Rational Integration Tester to create and run integration tests or stubs, it is critical that you understand the role of the HTTP proxy, how to install it, how to configure your environment and how to troubleshoot issues deploying it. This series of blogs will start with the basic concepts but hopefully even seasoned Rational Integration Tester users will find value as we move along.
The Interceptor Concept
The proxy is really just one specific instance of a general concept called the Interceptor. In general, the interceptor has two basic functions:
- Listen in on conversations between a client and a service to record message traffic that can later by transformed into automated tests or stubs.
- Act as a router to cause messages to be redirected from a client to a stub rather than the live service.
The details of how an interceptor works and the roles it fulfills will vary depending on the messaging technology being used. For example, the interceptor for JDBC traffic is implemented as a JDBC library. For IBM WebSphere MQ, the interceptor is a set of user exit libraries that are hooked into the MQ Queue Manager. The collection of all these interceptors is known as the Rational Integration Tester Platform Pack. I’m sure I will have opportunities in the future to dive deeper into those interceptors as well as others, but for this series, I’ll focus in on the HTTP Proxy used for HTTP, HTTPS and TCP messaging.
What is the HTTP/TCP Proxy?
I will just refer to it as “the proxy” from here on out, but the full name is really the HTTP/TCP Proxy. As mentioned above, the proxy is the interceptor for HTTP, HTTPS and TCP messages. Web proxies are pretty much a mainstay of networking these days. Wikipedia has a pretty decent discussion on proxies (http://en.wikipedia.org/wiki/Proxy_server). This diagram represents a proxy in its simplest form.
The Rational Integration Tester proxy sits between a service which uses the HTTP, HTTPS or TCP protocols such as a SOAP web service, REST services, etc. and the client that consumes the service.
Once the proxy is in place and running, the client and the service are unaware of its presence for the most part. I say “for the most part” because there are some security considerations in an HTTPS environment that we will examine in an upcoming blog post.
The first function of the proxy is to listen in on the conversation between the client and the live service so that messages can be recorded. The proxy doesn’t do this all by itself. The proxy is really just the workhorse for the Rational Integration Tester workbench. What basically happens is that an instance of Rational Integration Tester workbench tells the proxy that it should make a copy of the request coming from the client destined for the service. The proxy sends that copy to the Rational Integration Tester workbench but it also sends the original request – unmodified – to the live service. So the service thinks the request came from the client and responds. The proxy makes a copy of the reply, sends the copy to RIT and sends the reply on to the client.
The second function of the proxy is to route request messages from the client to the live service or to a stub, depending on what messages your stub is supposed to handle. Again, this is managed by the Rational Integration Tester workbench inserting “rules” into the proxy. As a request message comes into the proxy, it evaluates it against the rules that have been registered with the proxy and acts accordingly. For example, a rule might say that requests to the operation getHotels on myHotelServer:8089 should be routed to a stub instead of the live service.
Those of you with more Rational Integration Tester experience have probably already noticed that proxy rules are not normally set directly by Rational Integration Tester. To be precise, Rational Integration Tester tells the Rational Test Control Panel which in turn sets the rule in the proxy. That distinction will become more important later, but for now, let’s leave RTCP out of the picture. We will dive into the details in a later post.
As was mentioned earlier, the HTTP/TCP Proxy is part of the IBM Rational Integration Tester Platform Pack. It is installed using the IBM Installation Manager.
Running as a service
There are two options available when installing on Windows: Install Service and Start on Boot, which are both selected by default. Install Service installs a Windows Service that will enable you to run the proxy as a background service without a visible command shell. This is recommended for most all situations.
If you deselect the Start on Boot option, the Windows service will be installed but set to a Manual startup type. In most all situations, I would recommend that you select Start on Boot. Remember that if a System Under Test client has been configured to use a proxy and that proxy is not running, the SUT client will not be able to communicate to the service. It is therefore advisable to do what you can to ensure the proxy is running at all times. By installing the service and having the service start automatically, the proxy will fire up immediately upon reboot, which is generally a good thing.
Running from the command line
It is possible to run the proxy from the command line. This can actually be advantageous when you are debugging message routing issues since the proxy will scroll logging messages in the command window where it was launched. The same logging information is captured in log files when run as a service, but scrolling back through the command window is sometimes easier than repeatedly opening log files.
If you are not running the Windows service, open a command prompt, navigate to the proxy installation directory (by default, C:\Program Files\IBM\RIT-Platform\httptcp) and run startup.bat (or startup.sh on Linux).
Keep in mind that any non-trivial Rational Integration Tester installation will involve components installed across multiple machines. It is quite possible your proxy is installed on a different machine from your SUT client, the live service or the Rational Integration Tester workbench. You must have network connections between all of these machines and ports used to communicate between them must be open. Depending on your company policies, you may need to adjust firewalls to enable such communications.
The best way to figure out what holes you need in the firewalls on the various machines is to trace the flow of messages through a block diagram like those above. Keep in mind that firewalls can control message flow both out of and into a host. So let’s look at this example. The ports necessary to allow the client to communicate with the live service are already open. We need the following additional paths to be opened to allow the proxy to relay the request and reply back and forth:
- CLIENT_HOST OUTPUT New request to destination port 3128
- RITPP_HOST INPUT New request on destination port 3128
- RITPP_HOST OUTPUT New request to myHotelServer.com destination port 8089
- RITPP_HOST INPUT response on Existing connection from source port 8089
- RITPP_HOST OUTPUT response on Existing connection from source port 3128
There may be additional ports that need to be opened to allow communication between the Rational Integration Tester workbench and the proxy as well.
In the next blog post in this series (The Rational Integration Tester HTTP Proxy: Recording HTTP), I look in detail at using the proxy to record HTTP messages. After that, we will take a look at what additional considerations there are for recording secure communications using HTTPS. I’ll also blog about using the proxy to route messages to stubs. That’s my short list for now. It’s likely that additional topics will come to mind as I work through these so don’t be surprised if that short list gets a little longer.