In my last post, I talked a bit about how Rational Integration Tester uses visual models to assist you in building tests and service virtualizations – otherwise known as stubs. I would like to go a bit deeper into that topic in this post.
You use a perspective in Rational Integration Tester called the Architecture School to build your models. The name implies that you will be teaching RIT about your system by creating models. That is partially true, but in some ways, RIT will be teaching you! Let’s take a closer look at the Architecture School and how it is used.
The first thing you may notice about the Architecture School is that is is divided up into multiple sections through tabs. I will focus on the Logical View and the Physical View in this post. The Logical View is typically where you will start entering your model if you will be modeling manually (more about automated modeling in a future post). The Logical View will represent the logical representation of your system. Don’t think of this as a deployment topology. It is not. You will not be specifying details like redundant servers, app server clusters, etc. Think logical here. For example, if you will be testing an HTTP web service, you may start with a single HTTP connection in the logical view. HTTP connections, databases, JMS domains and such are considered Infrastructure components in the Logical view. You will normally compartmentalize your architecture into Service components. In addition to Infrastructure components, Service components usually contain the Operations exposed by the service. Relationships between Operations and Infrastructure components are represented by Dependencies. In the following diagram, JKE Services is a Service component, JKE Legacy Services is an HTTP Connection Infrastructure component and user and account are Operations that are dependent on the JKE Legacy Services connection. Test and stub definitions are defined using only logical components. Tests and stubs are not directly built upon physical resources.
Details such as IP addresses, port numbers, authentication methods and the like are associated to Physical resources in the Physical View. An Infrastructure component from the Logical view can represent any number of Physical resources. For example, you may be building a web service that runs on a logical HTTP connection. You do your development testing on a simple desktop instance of the logical architecture where the application is hosted on a small Tomcat server. As the system matures, you deploy to a QA instance running on a WebSphere Application Server in a test lab. As you move to pre-production, your system instance will look more like your redundant WebSphere cluster. So that one JKE Legacy Services connection could be realized through three or more physical servers.
So how does Rational Integration Tester know which physical server you want to use when you create or run a test? The piece that pulls the logical view together with the physical resources is what is known as an Environment. The environment is the secret sauce that makes this separation of logical and physical actually work. The environment “binds” the logical infrastructure component to the physical resource for a particular instance of the system you will test against. Think of a domain as a map.
So to run tests against the development environment in our example, you simply select Mike’s Dev environment. To run the exact same tests against the QA lab environment, you simply switch to the QA Lab environment. The tests are not changed in any way. Rational Integration Tester takes care of the details of directing the requests to the right hostname, queue or domain.
As I mentioned in my last post, two downfalls of many well-intentioned model-driven testing approaches has been the rigid dependence of the test to the model and the need to fully elaborate the model with physical details before testing can begin. Rational Integration Tester uses the concept of multiple views associated by environments to manage the visual model to enable the visual model to be useful yet not too restrictive.