David S. Linthicum: Is SOA Quality a Priority? - Software Development Times On The Web

David S. Linthicum: Is SOA Quality a Priority?
By David S. Linthicum

October 1, 2007 — SOA testing is in the media a bit these days as those who implement SOA have to make sure those new services, abstraction layers and orchestrations are ready for prime time. However, the common approach to SOA deployment is: development now, requirements maybe, and testing if we have the time. You can’t afford to make that mistake; there is too much on the line with this stuff.

Indeed, a recent study by Nucleus Research discovered that existing SOA implementations achieved limited success when considering ROI. Only 37 percent of enterprises have achieved a positive return on their investments from SOA deployments. While the root cause of these low ROI numbers can be attributed to many factors, the key issues relate to a lack of planning and a lack of testing.

Central to this problem is the fact that quality assurance, in general, is an often overlooked concept to most developers and designers. I mean, you’re admitting that your code and resulting services need to be tested. How can that be?

Moreover, those who run SOA projects don’t allocate a lot of time for testing, and typically when projects are behind, testing is sacrificed. But the complex nature of SOA means that testing is that much more important, considering that mistakes and bad services can ripple throughout the architecture.

There are many dimensions to SOA testing. They include services, processes, performance, and holistic or system testing.

Service-level testing is the most important, since core services are the foundation of the SOA. However, services are written very differently, depending upon the developer. Services may also be built on top of existing interfaces and APIs, and thus are even more complex and more in need of quality assurance testing, since you’re placing an interface layer on top of an interface layer. It’s a matter of validating the services for their intended use, verifying that the interfaces function correctly, and validating both WSDL and schema. Also, you need to consider diagnostics for design time and runtime, and make sure to address those older but important notions of unit, functional and regression testing.

In addition to service-level testing, we have to test the way services are abstracted into processes and composites. Since these are typically exposed as services themselves, it’s just a matter of testing another level up from the core services, as units, and regressing down through the services that they leverage (unit and system). This is very much like testing object-oriented systems, but these guys have binary interfaces and heterogeneous development and run-time platforms, thus the complexity is much higher.

Performance testing is perhaps just as critical, considering that most of the quality problems I run into when deploying SOA relate back to performance. Here is where you test against the SLAs established within the project, and learn how to spot bottlenecks, such as slow services, that can bring your SOA down to a crawl. Performance testing in the world of SOA is a matter of testing at the service, composite, process and system levels. You look at overall performance first, then decompose the architecture down to functional primitives to isolate the system’s problem components. You need to create an ongoing performance testing approach since so many performance issues develop over time as message and data traffic increases or changes.

Testing services, however, requires testing tools, unless you plan to write your own, which I don’t recommend. While there are a few players in the services/SOA testing game, Mindreef’s SOAPscope Server is one of the few that I keep seeing in use. Mindreef provides tools for automated testing and debugging of Web services and SOA projects, from validation of the service, testing to form and function, and performance testing. There are other tools as well, each taking a different approach to SOA quality, so do your research. I would recommend only using tools that have well-defined approaches to testing, or step-by-step procedures for leveraging their testing tools for your SOA.

What’s key here is to remember that you’re testing an architecture, and not an application. Thus, the complexity of the system, and the approaches and tools used for testing, goes way up. It’s important that you have a solid test plan, an arsenal of testing tools and techniques, and the time needed to test the architecture and correct any problems before they are found by the end user. Consider the systemic and business critical nature of the architecture.

Just to be very clear: Don’t skimp on testing!

David S. Linthicum is a managing partner with Zapthink. Reach him at david@zapthink.com.

EMAIL THIS ARTICLE

SEND FEEDBACK

MORE COLUMNS

SUBSCRIBE TODAY!

E-Newsletters:
  News on Mon/Thurs.
  Test & QA Report
  EclipseSource

SUBMIT

JOB BOARD

PDF & PRINT EDITION

* Requires Resource Account! LOGIN or SIGN UP

* Download Current Issue!
ISSUE 8/15/2008 PDF

* Need Back Issues?
DOWNLOAD HERE

Receive The Print Edition?
SUBSCRIBE HERE

EVENTS CALENDAR

Business of Software 2008
9/3/2008 to 9/4/2008
Boston
Red Gate Software

VSLive New York
9/7/2008 to 9/10/2008
New York City
1105 Media

Interop New York
9/15/2008 to 9/19/2008
New York
TechWeb

VMworld 2008
9/15/2008 to 9/18/2008
Las Vegas
VMware

Mobile Business Expo
9/16/2008 to 9/19/2008
New York City
TechWeb

MORE EVENTS

GET NOTIFIED!
About all of the latest Resources

SD TIMES 100

6th Annual SD Times 100

It's time once again to
recognize the organizations
or individuals that have
demonstrated leadership in
their markets.

HOME SITE MAP RSS CURRENT ISSUE BACK ISSUES SUBSCRIBER SERVICES ABOUT US CONTACT US BZ MEDIA