I was recently supporting an opportunity that involved multiple test teams supporting multiple products that all needed to virtualize common dependent services. It’s not that difficult to visualize how to create, publish and use virtual services in a small, well-contained project, but when you start looking at this from an enterprise perspective, it can turn into a large hairball quickly.
A fictional example
The Auto Loan application in the Personal Banking division of JKE Bank had a need for computing loan payments. It’s a pretty simple operation – you provide the loan amount, term of the loan and interest rate. In return, you get a value for the monthly payment amount. So the Personal Banking Auto Loan team encapsulated that capability in a web service, published it to the JKE world and built the Auto Loan application to leverage it.
Pretty soon, the Personal Banking division software architects decided it didn’t make sense to duplicate this functionality across all the applications in their portfolio, so they decreed that all Personal Banking apps that need to calculate payments must use the common Payment Calculator service. The two applications delivered by the Personal Banking team leveraged a common, consistent payment calculator.
At an executive golf outing, the VP of Personal Banking was bragging to the other VPs how efficient and cost effective his software team was as demonstrated by the common payments calculator service. Not to be outdone, the VP of Corporate Banking wanted in on this action and demanded that his peer share the payment calculator with his group. Just after another round of beers and just before a brawl broke out on the 12th hole, they agreed to allow the VP of Core Services to take ownership of the Payment Calculator service and deliver it as a common service across JKE. By the end of the round, The VPs of Billing, On-Line Banking and Mobile Banking were also all committed to leveraging this new, awesome common service.
Back in the office the following week, everyone realized the Payment Calculator was designed for auto loans with a maximum of five years so enhancements needed to be added to support longer loan terms. The Auto Loan team had to redo a bunch of integration testing to verify the changes didn’t break the Auto Loan application – which they did – and had to coordinate getting the regressions fixed – which they did. The Corporate Banking team required the addition of provisions for semi-annual payments instead of monthly payments. The Billing team wanted the service to return the total amount of interest that would be paid across the term of the loan. The On-Line team wanted the ability to deduct down payment values. The Mobile team wanted all values to be converted to local currencies. Each of the respective test teams realized they each had Dev, Test, Performance and UAT environments for each application. They just shook their heads asking “How are we ever going to test our applications while all these changes are going into the service we depend on?”
Hopefully you now see the problem. Today’s software systems are interconnected webs of loosely coupled applications; yet stable versions are required to complete integration testing. We have established how stubs or virtualized services can help, but how do you coordinate all this across so many teams and applications?
Rational Integration Tester and Rational Test Control Panel Concepts
Let’s take a quick look at several Rational Integration Tester concepts that help us manage this challenge.
I can’t think of any other word in IT that is more overloaded and overused that “Project”, but nonetheless, it is a fundamental concept of Rational Integration Tester. The project is a physical disk location that contains files. From the Rational Integration Tester Workbench user’s perspective, the project is the container that holds all of your development artifacts including tests, stubs, datasets and other things. Let’s leave it at that – the Rational Integration Tester project is the disk location where you store the development artifacts related to the tests and stubs you are creating with the Workbench.
There is no Project concept in Rational Test Control Panel. You typically have a small number (maybe one) of Rational Test Control Panel instances, even in a large deployment where you may have many RIT projects. So the relationship between RIT project and RTCP instance is a many-to-one relationship.
Every software project – err – “undertaking” must go through multiple stages in its journey to production delivery such as Dev, Test, Performance, UAT and Prod. There is hardware and software devoted to testing in each of these stages which is generally called an Environment. So although we are talking about one system, the implementation may vary considerably between, say, a Dev environment on very simple systems like Tomcat to HA WAS deployment in UAT or Prod. Rational Integration Tester captures the physical details in its own Environment artifact in the Rational Integration Tester project. The reason for this is that we need to know the implementation details of each environment to know how to apply tests and/or stubs to those environments.
The RIT environment maps directly to the environment in RTCP. Stubs, for example, can be created once in RIT and then applied to any or all environments. You can think of it this way: When a stub is deployed into RTCP, it carries along with it the environment details such as hostnames, IP addresses and port numbers. Stubs that have been deployed into RTCP are specific to the environment(s) into which it is deployed.
The domain is a bit more of an obscure concept. A domain is an Rational Test Control Panel artifact that represents a logical grouping of related systems that are part of a real business project. It may be served by one or more IBM Rational Integration Tester projects, depending on how large or small the domain is, and how many Rational Integration Tester users are working on it. A domain can contain one or more environments.
The domain is much more loosely coupled to Rational Integration Tester. There is no domain artifact in RIT – you simply choose the domain into which you want to publish your stubs when you publish to RTCP.
Fictional example meets Rational Integration Tester
So let’s look at how our fictional JKE organization might apply RIT and RTCP to support their efforts to virtualize their common Payment Calculator. Keep in mind this is not the only way to implement a solution but one way.
Each of these application teams wants to create a stub that will represent the “to be” status of the Payment Calculator service that implements the new functionality they require. The Personal Banking Home Loans application team needs to virtualize the service supporting longer term loans. The Corporate Banking teams need to virtualize a service calculating semi-annual payments. The Billing team wants to virtualize the Total Interest Paid response value and so on.
So each team creates their own Rational Integration Tester project and implements their own stubs within their separate project. They each define their individual Environments within their projects.
Each of the application teams is mapped to a Domain in Rational Test Control Panel. This enables logical separation between the teams. The structure in the Environments page of RTCP will look something like this:
There is one area we could debate heavily on this proposal and that is the decision to have each team maintain their own separate stub in their own separate RIT projects. You may believe it would be better to have a single stub within a single project. I can definitely see why that would appear to be desirable. Rational Integration Tester does provide SCM integrations for version control. However, my perception is that these teams are all working on very different tasks in parallel. SCM is good for keeping track of sequential versions of artifacts like stubs but it isn’t so good at keeping track of parallel development efforts. RIT’s SCM integration definitely has no capabilities for merging changes together later. So my reasoning for keeping separate projects is based on my perception that these fictional teams want to keep their distance from each other and will for the foreseeable future. Again, this point could be debated and there are many other factors to consider.
So we have a scenario to build upon. In my next blog, I will look at how you can control permissions and access to domains and environments for both people and services such as Agents and Proxies.