The Problem
Consider this scenario in the Acme corporation:
The EmployeePages webservice (WS) is developed by an extern company. The ShowCollaboration WS, the salary WS & Employee Database WS are developed by intern teams.
There are potentially 2 problems in this scenario:
1. Integration problem facing by multiple development teams
After 3 months, the extern team comes to deliver the EmployeePages WS, soon they face an integration hell. It seems that during these 3 months the Employee Database WS & the ShowCollaboration WS have been changed by the Acme teams.
2. Side effects to other webservices due to new requirements
Suppose there is a new request to modify the schema of one of the services or to add a new function or webservice. The Acme chief architect is suppose to maintain the overview to the whole webservices and their schemas, he will warn/advice the developers about the dependencies/potential side effects to other webservices. However this scenario with 4 webservices is just a simplification, in real life we have more than 100 interconnected webservices. Thus it will be difficult for the chief architect to maintain overview of the whole things.
Consider this scenario in the Acme corporation:
The EmployeePages webservice (WS) is developed by an extern company. The ShowCollaboration WS, the salary WS & Employee Database WS are developed by intern teams.
There are potentially 2 problems in this scenario:
1. Integration problem facing by multiple development teams
After 3 months, the extern team comes to deliver the EmployeePages WS, soon they face an integration hell. It seems that during these 3 months the Employee Database WS & the ShowCollaboration WS have been changed by the Acme teams.
2. Side effects to other webservices due to new requirements
Suppose there is a new request to modify the schema of one of the services or to add a new function or webservice. The Acme chief architect is suppose to maintain the overview to the whole webservices and their schemas, he will warn/advice the developers about the dependencies/potential side effects to other webservices. However this scenario with 4 webservices is just a simplification, in real life we have more than 100 interconnected webservices. Thus it will be difficult for the chief architect to maintain overview of the whole things.
The Solution
The solution for this problem is by incorporating (regression) tests against other webservices in the Acme corporation. If everything is fine (the new change doesn't break other webservices) the change will be promoted (accepted to the baseline revision in the version control).
In this scenario we have 2 version control repositories: svnbase (the main repository) & svntest (the temporary repository for testing).
The steps are as following:
- Commit the changes to svntest
- Build the new changes (using continuous integration tools such as CruiseControl or Hudson)
- Perform regression tests with all other webservices
- If the new changes break other webservices, you need to communicate with the other team to sort out the problem. We need to revert/rollback the new change in svntest.
If the new changes doesn't break anything, the change will be promoted (committed to the svnbase).
These steps can be implemented using Ant, Maven, or even shell scripts. By integrating these steps to the standard commit-process, we force small-steps continous integration which will avoid integration hell later on. Also the regression test will warn the developers & the chief architect about the dependencies/side effect which otherwise may not be clearly foreseen.
The test
This is an example of a simple webservice test using SoapUI: (please click the image for a better resolution)
In this test we applies several assertions. SoapUI will assert if the response is a valid SOAP message, then validate it using WSDL and match the Schema structure. I added also an extra test to test the business logic/data integrity for example to check that the name field in the response contains a certain string (e.g. "PXE").
It's advisable to add the bin directory of SOAPUI to your path. This directory contains testrunner.bat (or testrunner.sh for Unix) which runs the SoapUI testsuite and loadtestrunner.bat (or loadtestrunner. sh for Unix) which runs the SoapUI loadtest. Then we can run the SoapUI test from the command line/shell script:
testrunner -r soapui-project.xml
the option -r will generate reports to the console. The soapui-project.xml is the name of your SoapUI test project. You may also run the test using Ant instead of the command line/shell script.
In this Ant script we generate a html junit report which summarize the SoapUI test results.
Performance test
You might not also include a performance test in the regression test. The reason behind this is if the performance of your webservice is severely degraded due to the new changes, it will also worsen the performance of other webservices which depend on it. If the performance of the system becomes unacceptable, you might need to examine the business logic and/or to optimize the hardware/database. This is an example of a loadtest in SoapUI (please click the image for a better resolution):
SoapUI will run 100 threads over 60 seconds (which I hope is well above the burn-in period.) I set an assertion which warns me if the response time exceeds 5 sec.
Comparison with unit test in Oracle SOA Suite
Another alternative for example by using unit test in Oracle SOA Suite. My hesitation with this method:
• technology-specific (only works with Oracle SOA)
• currently the content test is only possible with xml/string match, thus can't deal with xml-fragment, missing xpath query flexibility as in SoapUI.
Summary
This article describes a solution for integration problems which facing SOA development. The solution for this problem is by incorporating (regression) tests against other webservices. If everything is fine (the new change doesn't not break other webservices) the change will be promoted (accepted to the baseline revision in the version control).
By integrating these steps to the standard commit-process, we force small-steps continuous integration which will avoid integration hell later on. Also the regression test will warn the developers & the chief architect about the dependencies/side effect which otherwise may not be clearly foreseen.
The managements will be happy too since this solution will move the development process from chaotic integration (CMM1) to a well defined standard integration process (CMM3).
Please drop your comments (e.g. other ideas/tools to solve this problem, other SOA integration problems, etc.) Thanks!
