There's an old expression - "When all you have is a hammer, everything looks like a nail." There's a wealth of applicable comment in this expression. It's an admonition to see the bigger picture as well as a suggestion that to be a true craftsman, one must have the right tools.

This month our focus is on tools and automation for Web services. That seems very apropos for the idea of needing a variety of tools, each appropriate to the task at hand. As with craftsmanship, Web service development requires the developer to know what is the right thing to do, and the right tool to do it with.

Knowing what is the right approach is often a matter of trial and error, of learning what will work and what will not. In the world of Web services, one of the key areas for concern is the definition of the APIs that will be exposed as WSDL and UDDI entries. As we present a Web service interface to the world, we must frequently wrestle with the level of granularity that we expose as a result. Too little granularity and we run the risk of confusing our service consumers by not providing enough specificity for the service to be easily understandable (and therefore consumable). Too much granularity and we run the risk of shutting down the network with excessive communications.

Best practices garnered from other distributed computer paradigms such as CORBA, J2EE, and COM are of some assistance in this matter. As we examine the patterns and paradigms adopted in each of these platforms and note the successes and failures, we can draw analogies to our own Web services implementations, which are often implemented on one of these platforms. Just as in J2EE, we can make our services very granular, but we would expect to incur a significant performance penalty for doing so.

So best practices is one tool in our toolbox. Another is automation tools. No one should ever have to write WSDL. It just should not be a task to be done by hand. Like Web-page design, once you understand the underlying structure and concepts, there's no need to code HTML in Notepad when you can use something like Dreamweaver.

Similarly, tools are being developed that make it easier to create, run, and consume Web services, tools that take away the tedium of writing WSDL by hand and automate the process. In the Microsoft camp, this area is filled nicely by Visual Studio .NET and augmented by some serious .NET development at Borland. In the J2EE world, BEA and IBM are producing toolkits that enable you to write Web services with very few lines of code, using a wire-together approach rather than a pure coding paradigm. EAI vendors such as webMethods are also producing development platforms.

Additionally, the concept of orchestration and management is receiving due attention. As Web services move from trial or proof-of-concept approaches to full implementation, the need for management becomes ever clearer. Companies such as Actional are developing approaches to meet this need.

But even further, as we start to see a wealth of Web services we realize that coordination of processes and atomicity of transactions are also critical. The WS-I and OASIS, as well as vendors such as HP, are trying to define both transaction standards and a standard model for description of the orchestration process in the hope of standardizing the approach and qualifying the need. It's always difficult to prove the necessity of orchestration systems - you can typically hardwire the code in less time. But the ability to make on-the-fly changes and the opportunity to finally have the business achieve the definition rather than having the IT department code it has significant value. What's missing is a strong case for ROI on this technology, but it will arrive shortly.

So we can see that we need more than a hammer and nails - we need a whole Web services toolbox. This issue highlights some of those tools. Enjoy, and don't use a screwdriver to pound in a nail - it doesn't work well.