Home > IT Blogs > SOA Talk > Test SOA for the unexpected
>>VIEW ALL POSTS  

SOA Talk

«
»
Nov 7 2008   7:12PM GMT

Test SOA for the unexpected



Posted by: Heather Clancy
Enterprise architecture, Podcast, Security, SOA, SOA development, SOA governance, SOA infrastructure, SOA management, Software testing

Testing service-oriented architecture requires thinking outside the box to the point that your test cases hit an application with totally unexpected input, argues Thomas Fredell, CTO of IntraLinks.

“Try to test for things that you don’t expect to happen, he said in a new SearchSOA podcast. ”That’s particularly important when you’re testing security aspects of an architecture. Make sure what you’re testing is not part of the expected flow.”

Fredell also recommends that architects assume that things will go wrong with their SOA implementation and plan for glitches. 

“Architecting for fault tolerance, you assume what can go wrong will definitely go wrong,” he said. “If you’ve got a component of your architecture servicing requests, when that component fails, what does it fail over to, to insure that the clients of your service are not affected.

SOA requires thinking outside the box because it is different from monolithic or client/server applications in that you may not have control over all of the Web services interacting with your SOA application, the CTO said.

“The beauty and the risk associated with service-oriented architecture is on the one hand you can compose services and meet business needs very rapidly,” Fredell said. “On the other hand, you may only have control over one side of the equation, the side where the service is implemented. That may mean that people do things that you really don’t expect.”

Access an interview with Thomas Fredell on SOA and the Unexpected

  Bookmark and Share     Comment     RSS Feed     Email a friend

Comment on this Post

Leave a comment:

Jsmith0475  |   Mar 2, 2009  1:54 PM (GMT)

The design of experimentation (DoE) is probably one of the most significant testing issues one faces in SOA and is more complicated that most other archetypes. Take, for example, three simple services that can be choreographed in any order, each capable of interacting with each other. How many tests do you need to ensure 100% functional coverage? You’re right if you said 6 (3x2x1). This is a classic factorial problem, in this case with 3 service. Now, let’s say your system has 100 services, so how many test would you need? Again, your right if you said 100!, or 9.33×10^157, and it would take you over 3×10^150 yrs to test completely, if you ran continuously a test every second of every day.

Traditional testing in these kinds of systems are impractical given the number of total tests needed to understand/certify the functional/non-functional behavior of the system. So what do you do in these circumstances? Well, that is where a good , well thought out, SOA design of experiment (DoE) comes into play. DoEs are all about reducing the number of experiments without unnecessarily diminishing the value of the test. Such DoE are call Partial Factorial DoE. A good SOA DoE for the 100 services, for example, could reduce it down to 10! or 5040 tests, a significant reduction in effort and cost.

So, the next time you are thinking about testing your complete SOA environment, ask whether or not you have the right type of testing framework (DoE) and whether or not you really need to do all those tests in order to show that your systems is actually working correctly or not.

Dr. Jerry A. Smith
CTO, [A href="http://www.symphonysv.com"]Symphony Services[/A]