SOAP 1.2 Marks Start of Web Services Testing Era

ZapThink, a Waltham, Mass.-based research firm, predicts the release of SOAP 1.2 will fuel the search for -- and development of -- tools and technologies that help developers (and sysadmins) make sure that the web services they build today will work optimally. If you're preparing for SOAP 1.2, take a tour of the web services management options that await you.

Tags: Web Services, Testing Tools, SOAP, SOAP Message, Management, SOA, Developers,


ZapThink, a Waltham, Mass.-based research firm, predicts the release of SOAP 1.2 will fuel the search for -- and development of -- tools and technologies that help developers (and sysadmins) ensure that the services they build are doing what they're supposed to be doing.

In the study Testing Web Services, ZapThink analyst Jason Bloomberg predicts, "The next generation of web services promises to fundamentally change the distributed computing landscape and present new testing scenarios and problems that companies using web services don't currently understand."

A Road Map for Web Services Management
The pending release of SOAP 1.2, along with a variety of cross-platform approaches to security, XML schema compatibility (transformation) and workflow (event management), will collectively spur increased investment and research for testing and management tools for on-demand web services. This is the study's basic premise.

"How you'll make sure that your services are running the way they're supposed to, and can scale across multiple platforms -- that' s where the next hot area will be," Bloomberg predicted. This sets the stage for the first wave of management tools for loosely coupled (or on-demand) web services -- also known as Service-Oriented Architecture (SOA), he added.

However, to provide developers and sysadmins this kind of monitoring/management control, he said that the gap of the missing layer between the legacy (mainframe or client/server) asset and the pending SOAP 1.2 work must be filled in. This new layer might echo the type of vendor collaborations we're already seeing.

For instance, the J2EE and .NET communities are actively exploring how best to affirm interoperability on WS-I's Basic Profile for base-level web services technologies (SOAP, WSDL, etc.) -- but other efforts are in play to move interoperability up the stack to include security, business rules and workflow.

The ZapThink Timeline -- Now through 2005
Bloomberg has his own take on a timeline for web services management tools and standards. An abbreviated version goes like this:

I. Phase One -- Internally Focused Testing Tools (Now)
In the first phase of web services adoption, Bloomberg pinpoints three capabilities as the most important, which are becoming more commonly available:
  1. Testing SOAP messages -- Moving beyond using SOAP as the interface to the web service to testing the format of the messages themselves.
  2. Testing WSDL files and using them for test plan generation -- WSDL files contain metadata about web services' interfaces. Testing tools can use these WSDL files to generate test plans automatically.
  3. Web service consumer and producer emulation -- When a testing tool generates test messages that it sends to a web service, it is emulating the consumer for that service. In addition to the web service producer, the consumer of the service also sends and receives SOAP messages. A web services testing tool should therefore emulate the web service producer as well as the consumer.

II. Phase Two -- Testing SOAs (Late 2003/Early 2004 through 2005)
In this phase we're about to enter, Bloomberg predicts the aspects most important to the management and delivery of service-on-demand (dynamic web services) integration will include:
  • Security;
  • Transaction and state management;
  • Directory/registry services (along with associated authentication); and
  • Dynamic discovery of needed assets to complete a service request.


During this second phase, testing tools need to help developers/sysadmins with:
  • Testing the publish, find and bind capabilities of an SOA -- These are fundamental SOA characteristics, and web services testing tools should test each side of this triangle.

  • Testing the asynchronous capabilities of web services -- Dynamic web services will move beyond the capabilities of RPC or simple synchronous requests. As SOAP matures to support asynchronous messages, real-time notification and management alert messages, testing tools should test each kind of SOAP message.

  • Testing the SOAP intermediary capability -- A particular SOAP message will typically have a designated recipient, but in an SOA environment may also have one or more intermediaries along the message route that take actions based on the SOAP message header's instructions. Testing tools must verify the proper functionality of these intermediaries.

  • Quality of Service monitoring -- The distinction between traditional management of IT "operations" and "software deployment" testing will blur as SOA becomes more commonplace, so testing tools will need to support both runtime and "design-time" testing.


  • III. Phase Three -- Testing Dynamic Runtime (2004/5 and beyond)
    In this most mature phase of web services deployment, developers/sysadmins will be concerned with "outside the firewall" dynamic SOA functions. Many of these will concern transaction integrity (reliability, security, authentication) for B2B web services, and require party-to-party orchestration and business process automation/management (BPA/BPM) tools.

    Tools in this era will also need to support versioning testing to guarantee integrity and availability of core web services between partners (or on demand) when one or more parties upgrade their internal systems.





    back