developerWorks: You're listening to a developerWorks podcast. I'm Scott Laningham. Our guest is Brian Bryson, technology evangelist for IBM Rational Quality Management Tools. He joins us to talk about quality management of Web services-based applications. Brian, thanks for your time today.

Bryson: You're welcome, Scott. Pleasure to be here.

developerWorks: So I guess if we're going to have a discussion about testing SOA applications, maybe we ought to start right at the top by quickly defining exactly what an SOA application is.

Brian: Yes, that's a good idea. Since SOA seems to be, it's becoming one of those ubiquitous buzz terms that, you know, IT gets thrown around a bit as a kind of a cure-all for all the ailed software, software development. And it's a bit of a nebulous term. You know even if you go to Wikipedia, they don't even have a formal definition for it yet. So I'll take a crack at it. And the sort of common definitions are, I guess, it's basically an architectural style that builds systems by assembling loosely coupled independent Web services. And those are kind of the key points: loosely coupled Web services are kind of at the core of SOA applications.

developerWorks: OK, and you're going to talk about testing here a bit. So what is SOA testing, then, after you follow on that definition then?

Bryson: Right. So for following on from that definition, the key concern for testing SOA applications becomes the actual testing of these Web services that are at the core. And you know, it's really no more — well, it's really no more simple or more complex than that.

Essentially, you take the Web service, you feed it some inputs and then you ensure that that Web service returns an expected output for that set of input.

developerWorks: It sounds a little bit like business as usual for testers, but I'm assuming there's a little something more to it. So what makes SOA testing different or unique in your mind?

Bryson: Yes, right. So for testers, that is a very business-as-usual method of operation — sort of provide input, validate output. But it does get a little more complicated when you factor in that an application might quite possibly use a Web service provided by like an external entity.

So you're not going to be developing all of your Web services; you're going to be using other people's Web services. And in those cases, you have no guarantee of the quality of that Web service. You know, if you're building stuff internally, you can trust your own development team to provide quality. But if you're relying on someone else, you know, that guarantee of availability and quality, it just isn't there.

And that's where this gets tricky. So let's say I have a Web service that takes as its input the output from another Web service. Now, if that first Web service goes down and never returns a result to my second Web service, I've got a problem. And all this comes from the whole loosely coupled part of SOA applications. It's really the core issue here. You know, the implication for a tester, then, it becomes, for Web service testing, you need to account for a lot more potentially bad or missing data that if you were building a system based on your own development, you wouldn't have to rely upon. And then it gets even worse. By definition, you're testing a system of components. You're effectively doing unit testing.

So for your typical QA types, your typical QA professionals, they're more comfortable from functional system regression testing. All these people are sitting down running through test scripts, driving a GUI. So the paradigm of Web services testing, unit testing, it can be daunting. It's not that it's exceptionally difficult, but it's a method or mode of operation of testing that they're just not familiar with.

developerWorks: OK. So it sounds like, you know, the loosely coupled nature of SOA applications is a benefit to organizations maybe in terms of reuse and flexibility. But it also sounds like it can be a burden to testers in that it requires additional testing which might be unfamiliar to them. Is that kind of what you're talking about?

Bryson: That's right. That's exactly right. But you know, the news isn't all grim. The testers do get some reprieve here because of the nature of Web services.

So Web services are a W3 consortium standard. The good news there is that means Web services have a clearly defined communication mechanism. Every Web service is called the same way. That Web service might be built in Java™ or Microsoft® .NET, but it presents the same interface, and the results are returned the same way.

So because of this standardization and this, the Web service communication contract, you might call it, because of this tool support is very strong. There's no ambiguity. The tools know how to communicate with a Web service. There's no two ways about it; there's one way to do it.

So this really simplifies the task of having to create tests and test cases to deal with this unfamiliar test approach, having that standardized method just makes it, gives testers a break, essentially.

developerWorks: OK. So go into that a little bit if you would. Talk about the tooling and how that helps, if you can.

Bryson: Sure. So IBM has a couple of tools for testing Web services. Probably the most prominent one is the IBM Rational Tester for SOA Quality. And so with this tool, you point it at a Web service, and what it will do is it will create a graphical user interface, or a GUI, that testers can use to interact with the Web service.

Now what's great about that is that solves the first problem for the testers of working in an unfamiliar paradigm. With the tool we're artificially creating a GUI environment that's familiar to testers. We're letting them test the service by driving a GUI as opposed to interacting at a unit-test level.

So using that interface, the tester provides the input data and then sends that off to the Web service, and then the Web service returns a result, and then the testers use what we call verification points to verify that the results from the Web services are correct. You solve that first problem of the unfamiliar paradigm by making Web services testable in a manner that's more common or typical for the QA tester.

Now, once the test is complete, we provide an interface for the testers to supply additional data to the Web service. And this really gets at our second problem of the focus on data, of having to test more cases the situation where one Web service goes down — how does the second Web service react? By giving the tester this interface to provide more data, instead of having to create multiple tests to validate the Web service, the tester creates one test that cycles through multiple sets of data to validate all sorts of data input combination. And so the icing on the cake here is that all this is done without having to write any code or having really to understand any of the intricacies of a Web services architecture.

developerWorks: So you're talking about functional stuff there. Now I'm wondering about performance testing because obviously, this stuff is delivered over the Web. So there have got to be some performance considerations, right?

Bryson: Right. A good point, actually. And performance is absolutely key for SOA applications. Like in a situation like I was describing before, where we have Web services depending on one another, you have the situation where the first Web service goes down and causes problems for the second one.

But a similar situation can arise with a slow response time. And a slow response time from a Web service can be as bad as not getting a response from a Web service.

developerWorks: Right.

Bryson: There are definite performance and scalability concerns here. Now, one of the nice things about our solution is that the same test that the tester creates for functional testing can be used for performance testing. So we've got a second tool called the IBM Rational Performance Tester Extension for SOA Quality, and it's the performance testing cousin to the first tool, the Rational Tester For SOA Quality. They're built on the same architecture, and they use the same test and data. So we're even following that Web services concept of reuse. We're even getting reuse with our tool.

developerWorks: Yes.

Bryson: Now, the difference is on the performance side, instead of taking that functional test and running a single instance of it, on the performance side, what the tool will now do is let you run X simultaneous instances of the tool. So I could say, you know, run 1,000 simultaneous instances of this test and tell me how long it takes the server to respond.

developerWorks: So it sounds like with these couple of tools here, you've got a pretty good handle on SOA application testing. Would you say so?

Bryson: Yes and no. We certainly have, you know, in the tools I've described, we certainly have our functional side covered and our performance side covered. So, yes, we do have a good grasp on the SOA application testing. But as Web services, you know, a test that passes today may very well fail tomorrow. We're not just relying on software here. We've got hardware as well, right? If a given server goes down, a test that works today may not work tomorrow. So one of the additional complexities of Web services is ensuring quality host deployment.

So it's probably worthy of discussion for another day, but it's a key aspect for consideration here. And we have an offering called the ITCAM for SOA Quality that ensures that post-deployment monitoring. And that really plays an important role in the success of SOA deployment.

developerWorks: Sounds like you're lobbying for another podcast here.

Bryson: You know, I like to talk. [LAUGHTER] So if you give me the soapbox, I'll hop right up on it.

developerWorks: We'll do that. We'll do that. Now as a wrap-up here, resources for people that want to dig more into this. We obviously with the SOA and Web services zone on developerWorks. Great zone with a lot of good content and tutorials and articles. Is there something else you want to specifically point people to here before we wrap up?

Bryson: Right. So the zone would be the No. 1 place to go. And maybe one thing that I'd specifically highlight is the trial version to this software that we have available online. So you can go out and download from that zone or straight from IBM.com, you can get to it either way — 30-day trial evaluations of Rational Tester for SOA Quality if you want to do the functional testing, or a 30-day trial evaluation of the Performance Tester Extension for SOA Quality if you want to do both functional and performance testing.

So both of those are out there, 30-day trials, fully functional, download and go. And try it on your own SOA applications to test your own Web services.

developerWorks: Well, Brian, thanks so much for taking some time out of your day to talk with us about all this.

Bryson: Oh, my pleasure, my pleasure, Scott.

developerWorks: Brian Bryson is again technology evangelist for IBM Rational Quality Management Tools. Check the show notes for this podcast for helpful links related to quality management for Web services-based applications. You can find the show notes at IBM.com/developerworks/podcast. This has been a developerWorks podcast. I'm Scott Laningham. Thanks for listening.

Resources

Learn

• developerWorks SOA and Web services zone
  
  
• Podcast blog
  
  

Get products and technologies

• Rational Tester for SOA Quality trial
  
  
• Rational Peformance Tester Extension for SOA Quality trial
  
  

About the author

Scott Laningham, host of developerWorks podcasts, was previously editor of developerWorks newsletters. Prior to IBM, he was an award-winning reporter and director for news programming featured on Public Radio International, a freelance writer for the American Communications Foundation and CBS Radio, and a songwriter/musician.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Resources
• About the author
• Comments