Those in the security business, like me, often complain that security is the last thing that people consider when designing a new application. If a little more thought had gone into the security of the e-mail protocols, for example, it would be easier to trace the true origin of an e-mail, which would make tackling the mounting problem of spam much less daunting.

One of the reasons Web services are so important is that they represent the first time security issues were considered at a very early stage in the design of a protocol framework. Now that Web services are being used to solve real-world problems, the issues we are starting to face are the problems of success - how will we manage when we are dealing with hundreds of Web services protocols connecting thousands of partners?

Managing changes to a network protocol is hard. The first lesson taught at network protocol design school is to include a version number so that the machine running version 4.2 or the protocol knows to refuse requests from a machine running the now obsolete version 2.3. At least, that's the theory. The practice tends to be that once a protocol is deployed, you rarely get a second chance. Most of the Internet protocols we use every day, such as e-mail and news, have changed remarkably little in the past 10 years. The Web, only a little over 10 years old, has seen more change but none of major consequence for the past eight. It is one thing to announce a new version of a protocol, quite another to see it deployed.

Stability has advantages. E-mail could never have become so widely used if the Internet mail protocols had changed each year. But the price of that stability is high. The effect is that the Internet tends to run using lowest common denominator technology. As the number of Internet users approaches a billion, we are using a two-decades-old protocol from the dawn of the Internet designed to serve a user community of thousands. The original design flaw that left security out of the design of the e-mail system would not have mattered so much if it was easier to correct its consequences.

This is why the WS-Policy mechanism currently in development is such an important part of the Web services architecture. Readers familiar with Web services will know that Web Services Description Language (WSDL) provides a description of a Web Service protocol. WS-Policy goes further and allows the configuration of a specific Web service to be described.

It's a bit like going to a hamburger restaurant. You know in advance that they serve hamburgers and fries, but do they serve onion rings or milk shakes? Do they accept credit cards or is it cash only? Knowing that information up-front allows you to choose the right place to eat.

The result is that administrative operations that used to be performed manually today can be automated. Automation may not sound like a big deal today when few enterprises are running Web services that can be seen outside their firewall. Few networks of Web services users have more than 10 members. If you need to do an upgrade you can just pick a public holiday to take down the network, change the software, and restart.

If you are running Web services in a production environment with links to a few hundred e-commerce partners, automated management becomes essential. Even though the protocols you are running may be "standard," there are inevitably configurations and options that have to be set right before your Web services can talk to each other. WS-Policy allows this to be done at the appropriate levels - let the machines do the work.

A similar change took place in the Internet 20 years ago when the Domain Name System (DNS) replaced the list of host names and IP addresses that used to circulate between network administrators. Without the DNS, the Internet could never have grown to a million users, let alone a billion. Yet today we take it for granted that when you type in www.verisign.com your browser will connect to one of the machines currently responsible for serving the VeriSign Web site even though a different machine may have been in use a few days or even a few hours earlier.

Arthur C. Clarke once wrote that any technology that is sufficiently advanced should be indistinguishable from magic. This same rule applies to the Internet and Web services. Ten years ago the magical feature of the Web was the fact that you didn't need to think about how you were getting the information you wanted from the Internet, you just pointed, clicked, and let the machine work out the details. WS-Policy allows that same principle to be applied to management of Web services.