How do you define a Web service? If you ask five people to give you a definition, you'll probably get at least six answers. Is a Web service any application that can be accessed over the Web, or is it limited to applications that expose a programmatic interface? Is it the code that implements the service or the interface to the code? Do you have to use SOAP? What about XML-RPC? Or RosettaNet? Or FIXML? Or some other XML protocol? And do you have to use XML? Does SWIFT qualify as a Web service?

I know that many people will disagree with me, but my basic definition is as follows: a Web service is a programmatic interface to some application function, and that interface communicates using an XML protocol - any XML protocol. As a best practice I recommend that you use a standardized or well-known XML protocol (e.g., SOAP 1.1), and describe your service using some type of standardized or well-known description language (e.g., WSDL 1.1). But as long as you're using an XML protocol, I would say that it qualifies as a Web service.

I draw the line at XML because I think that XML is the secret sauce that gives Web services technology its enormous power and flexibility. It is the Web's universal data language. Any application programming language can interpret XML. And Web services can run on any platform - from the largest mainframe to the smallest embedded device. Web services technology is the first distributed-computing middleware that is completely vendor and platform independent. This little feature is a huge win and by itself provides a very strong incentive to adopt Web services.

But there's another reason why you might want to adopt Web services: multichannel client support. If you think back to ancient history - to the days before the Web - I'll bet that you can recall discussions about three-tiered client/server computing. One of the core themes of three-tiered client/server computing was the clean separation of presentation logic and business logic. The idea was that you could build a business service, and you could access that service from both Windows and Macintosh clients. (Remember how hard it was to do something like that in 1992?)

Now you would most likely just build an HTML client that talks to the application through a Web server. But is that enough? Wouldn't it be nice if you could access your services from a wide assortment of client environments: Windows, Macintosh, Linux, Unix, Palm OS, BlackBerry, a mobile handset, etc? And wouldn't it be nice to access them from Visual Basic, WinForms, Excel, reporting tools, business intelligence tools, WebForms, Flash, Java applets, and IVR applications? The requirement for multichannel client support is more critical than ever.

Enter Web services. Web services offer the ultimate in presentation and business logic separation. A Web service doesn't have a native human interface. It has a programmatic interface. You send it an XML message and it returns an XML message. Hence any client application that can process and interpret XML can speak to a Web service. And what's so wonderful about XML is that it's so malleable. XML can be validated and transformed on the fly. This little feature allows you to dynamically resolve any inconsistencies that might exist between a client and the service. You can also customize your messages for different types of clients.

XML can be transformed at runtime into a presentation markup language, such as HTML, WML, or VoiceXML. You can also transform the XML into binary formats to send to a device that doesn't understand XML. More and more GUI development environments, such as Microsoft WinForms/WebForms and Macromedia Flash, can consume and display the data from XML messages. The business intelligence vendors are adding inherent support for XML data sources. Microsoft's forthcoming XDocs product will capitalize on the power of XML to blur the distinction between client types, such as a spreadsheet, a document, or a form.

So if you're looking to cook up a nice little application that can be consumed by any possible client environment, don't forget the special sauce: XML. Build your application as a Web service.