Choosing the Right Development and Testing Tools
Commercial development tools are an asset in the Web services creation process, and developers should make it their goal to leverage their existing tools and development environments as much as possible. To that end, find out whether Web service extensions or plug-ins have been created for the IDE that you use. Microsoft's Visual Studio .NET and the DotGNU Portable .NET both support the Web services creation for .NET. In the J2EE world, Borland provides an extension to JBuilder, Borland Web Services Kit. There are also standalone products, such as CapeClear and Systinet. Some tools provide plug-ins to other development environments, like the Eclipse open-source framework.
If you're going to adopt a new development environment, there are important questions to ask:
- Does the tool support the creation of document-style services?
- Does it support the creation of asynchronous messages?
Some tools let you select what document model you want to use, while others provide simple mechanisms for creating asynchronous requests.
- How does the tool support or extend current standards?
- What specific languages (Java, C/C++, etc.) can be imported into the tool?
Look for tools that can automatically generate Web services components. This can reduce the learning curve for the developer and increase productivity. It can also help isolate the developer from changing specifications.
SOAP monitoring tools can assist with another important aspect of development: the debugging process. A SOAP monitoring tool, or sniffer, is included in many tools and allows a developer to view SOAP requests and responses that flow through the application.
A sniffer acts as a proxy server, sitting in front of the actual Web service host. Requests are sent to the proxy, which traps the SOAP messages that come in and out, and displays them in a graphical window for the developer.
There are many other aspects of debugging to consider. In particular, runtime issues such as availability, performance, security, and scalability all must be tested, both during development and in production. For this, some form of integration with your management platform is essential.
Building a Web Service
Finally, it is important to consider the approach that will be used to build and deploy your Web services applications. Using an automated build tool can greatly enhance developer productivity. One of the more popular build tools on the market today is an open source offering called Ant.
You can think of Ant as a next-generation Make utility. Like Make, it can be used to simplify and automate almost any build process. Unlike Make, it is based on Java and XML. This makes Ant much more portable across multiple platforms. Because Ant uses XML, it is component-basedyou can easily add new types of build targets or import from existing build files, etc.
Ant can also be used to help generate Web services components. The example below defines a task for creating WSDL from a Java class and a task for creating Java client proxies from WSDL. From these tasks, specific targets can automatically generate the Web services components. Overall, this approach can speed up the develop-deploy-test cycle.
<project name="demo" default="genwsdl" basedir=".">
<taskdef name="java2wsdl" classname="org.apache.axis.wsdl.Java2WSDL"/>
<taskdef name="wsdl2java" classname="org.apache.axis.wsdl.WSDL2Java"/>
<java2wsdl class="com.hp.MyService" wsdl= "MyService.wsdl"/>
Some products, such as Collaxa and BEA WebLogic, provide Ant support out of the box, which makes it even easier to integrate Web service builds into your environment. Ant appears to be the defacto standard build tool for Web service, but many companies have their own internal build environments. Regardless of what build tool you use, the important thing is to follow the model of continuous integrationbuilding and deploying early and often.