Download: WS-I Testing Tools Ease Dev Pains
The Web Services Interoperability Organization has released a pair of testing tools for devs building web services to help them make sure their services will interoperate with others across the enterprise or the wide area. IDN speaks with a WS-I exec to get insights on how devs can begin using the Java and C# tools, and learned how WS-I may prompt better vendor standards.
The WS-I (Web Services Interoperability Organization) has released a pair of testing tools for devs building web services to help them make sure their services will interoperate with others across the enterprise or the wide area. IDN speaks with a WS-I exec to get insight on how devs can begin using the tools, which are available for both C# and Java devs.
The testing tools help developers determine whether their Web services built to comply with Basic Profile 1.0 guidelines are available for download. They are available as: C# testing tools and Java testing tools packages. Each includes two major tools/components:
WS-I Monitor: Works like a network sniffer. Sits between the client and the web service and logs all messages, requests and responses, as they go back and forth. Then the tool puts these messages into a file which can be processed later, which provides developers a "trace." Of all the activities.
WS-I Analyzer: Goes through every message in the trace and analyzes them against all the BP's requirements. In addition, it verifies that the messages in the trace do not violate the BP rules, and in turn produces a report.
The output from the Analyzer is a report that indicates whether or not a Web service meets the interoperability guidelines of the WS-I Basic Profile. The report provides details on the specific deviations and failures, so that users know which requirements of the WS-I Basic Profile were not met. These artifacts include the WSDL document(s) that describes the Web service, the XML schema files that describe the data types used in the WSDL service definition, and the UDDI registration entries. More than 300 test cases have been written and automated for the Analyzer tool. Each test case exercises between 50 and 90 test procedures.
"We see the [WS-I] deliverables as a three-legged stool," Chris Kurt, a WS-I board member and group program manager from Microsoft, told IDN. The legs are: (1) the Basic Profile, (2) Sample Applications and (3) the testing tools to help devs get from whiteboarding to real applications that can be deployed in their enterprise.
"Paper can only get you so far," Kurt said, adding developers need those two other legs of the stool. "From the start, WS-I's goal was to be very practical, to give developers real examples [of WS-I applications] that let me download some sample code, if I'm having trouble, and testing tools so that developers can check their work to see if they've done it right and give them resources to help them fix any mistakes."
Putting WS-I Tools To Use
While Kurt admitted that WS-I has yet to do a study to quantify the benefits from their testing tools, he said there is evidence that end users are finding "some real benefits."
Kurt said that the tests catch a wide range of errors that can bring interoperability to a crashing halt. Some errors, he said, can be simple to fix, but hard to detect. Using the wrong namespace, or even missing a namespace can affect interoperability. "There are a lot of these errors that are just ankle biters," Kurt told IDN, "but when it comes to getting these things to work together, everybody needs to do these things the same way."
The tests also catch more complicated errors, such as WSDL errors. "In these, developers have to figure out 'Are the messages being exchanged in the right order?' Or, there are cases where some requests only will accept two 'responses,' and the developer has coded in a third alternative -- which is unaccepted by the original request."
Combined, the WS-I testing tools are crafted to help the developers detect, repair and deploy any inconsistencies or flaws that will interrupt interoperability between web services -- either across silos within an enterprise, or even across the firewall. WS-I's work is proving especially valuable to firms which support apps in both Java and .NERT, and need them to work together.
For example, Kurt mentioned one large SI working on a B2B project, where the hub company used Java and the smaller partner companies were using .NET. "Working on this project before the WS-I guidance, and they found it was difficult to include the smaller partners. Now, the SI has updated their methodology to includes the WS-I Basic Profile, so they review all the web services they develop against the Basic Profile, and then run their services against our testing tools before they try to deploy," Kurt said.
The result should be encouraging to all developers: "Their first test messages now have 100% success rate. Granted, they are not insanely complex web services, but they went from an environment that for every new system they had to integrate they had this long testing cycle (in house-developed)"
Making Standards More Practical
The WS-I focus on practical deployment issues is a sign of what Kurt called "a shift in thinking on how to best develop a specification or standard."
He explained it this way: "It had been the case for a long time that standards architects spend a lot of time creating specs and creating paper early on. It was traditionally very late in the process, perhaps even after the standard was completed, where folks started writing code, putting into products and really testing how practical what their inventions were."
Now, Kurt said, because so many WS-I members -- vendor, SI and end users -- also serve on conventional standards committees and working groups, WS-I's insights are having an impact earlier in the process.
Kurt added the new WS-I tools reflect a great deal of input from system integrators (SIs) and end users building web services, and not simply the vision of software vendors. "A big piece of the technical discussions involve the end user companies or the consulting firms who are running into issues with projects they are doing. They are involved with profile development, and bring to [WS-I] concrete examples of issues they run into. For the most part, we're all engineers in a room, working on providing the right guidance."
The common theme across all customers involved in early WS-I work is that they have complex, heterogeneous environments, Kurt said, and that led to some deployment problems. "The existing [web services] technology out-of-the-box, that is without WS-I guidance, just isn't interoperable. End users and SIs found there are just too many things that get in the way. Mostly, this is because the web services specifications offer vendors a lot of flexibility when they make their [products]."
It's the WS-I's role to find common ground and interoperability approaches among vendor products that comply with the standards, without constraining standards processes, Kurt said. But, he said, the WS-I's efforts to put hard muscle behind getting vendor implementations of standards to work in the real world is having some unintended positive effects.
"Now, in parallel with writing of the specifications, engineers are validating the design and making sure that interoperability issues are addressed much earlier on. This is becoming a core part of the initial standards development process, as opposed to a few years ago where this would happen at the very end," Kurt said.
Aside from the tools, devs can also use a growing collection of WS-I Sample Applications, developed by major WS-I vendors, the samples are implementations to demonstrate the WS-I Basic Profile 1.0 interoperability among them in supporting the supply chain application scenario. IDN's story (with links) to WS-I's Sample Apps is available here.
Implementations of the Sample Application have been delivered by BEA Systems, Bowstreet, Corillian, IBM, Microsoft, Novell, Oracle, Quovadx, SAP and Sun Microsystems. The vendor implementations are available here.