There's no doubt about it, Web services are a hot topic in the XML world. It's somewhat ironic that when Jon Bosak, then an online information technology architect at Sun, brought a group of us together in 1996 to bring the powerful concept of generic markup to the Web, Web services were far from our minds.

Like so many applications in which XML is being used, it's not a particular technical characteristic of XML that's making new things possible. Rather, it's the fact that otherwise disparate groups are agreeing on how to communicate - at least agreeing enough that the aspects in which they differ are shrinking and hence are far more manageable.

The concept of Web services actually predates XML, and examples abound of Web services that aren't XML based. Ever since HTTP parameters and the Common Gateway Interface (CGI), it's been possible to send inputs to a Web server and receive some output, either passively or triggering some kind of active operation on the back end. Examples of the former include search engines or a map site, the latter a stock trade execution or purchase from your favorite online bookstore.

The key difference between these examples and Web services today is that the previous focus was on the browser (especially HTML forms) as an interface between a human and a service. With the inputs as XML they can have a richer structure; with the outputs as XML they can be processed by other services, repurposed, embedded, and more. All the benefits of XML for publishing - media independence, repurposability, easier processing by applications - apply to using XML for Web services too.

Without XML, people are adopting screen-scraping techniques along the lines of those used on 3270 applications. HTML-based Web applications have now become legacy applications. In the transition to XML-based Web services, companies are discovering the benefits of separating data and business logic layers from the presentation layer. Once the data and business logic are made available as a Web service, it can be repurposed in different ways and the human UI simply becomes a layer on top of the Web services.

One of the most exciting aspects of Web services is this notion that businesses can offer their core competencies to other businesses with a reach that wasn't possible before. As more pieces of the Web services infrastructure are agreed on, the cost of plugging in some other business's services into your own offerings drops dramatically. Entirely new business models are starting to emerge out of this idea. It's a move away from simply using XML to integrate two applications or two businesses in a fixed way. It's all about dynamically assembling Web services into what are now being referred to as business webs.

This dynamism is made possible through standard ways of describing and discovering Web services. There's a lot of activity in this area and, as the names suggest, the Universal Description, Discovery, and Integration (UDDI) specification plays a huge role in this area. In September, Ariba, IBM, and Microsoft, with the support of a wide range of other companies, announced UDDI as a means to publish to and retrieve from registries information about a business and the services it offers. As with any system used to discover resources, taxonomy is of vital importance. UDDI provides hooks for the classification of businesses and their services; I see a number of companies providing a lot of value in making their classifications available.

Another important requirement for this dynamic discovery is the whole issue of trust. It's not enough to find a Web service that provides the wanted functionality; there needs to be a guaranteed quality of service associated with it. Undoubtedly there'll be companies whose core competency will be certifying Web services and, of course, this core competency will itself be provided as a Web service.

Although classification and certification are part of the overall description of a Web service, the real core of a Web service definition is the schema for the XML input and output and a binding to a particular access point via a particular protocol.

IBM and Microsoft also announced the Web Services Description Language. WSDL is principally a convergence of the two companies' previously separate attempts to standardize the way information about a Web service is expressed. For type definitions WSDL favors the W3C's XML Schema language that, at the time of writing, had been through its final working draft and was about to go to Candidate Recommendation Status. For protocol WSDL is somewhat agnostic, allowing for SOAP as well as XML over HTTP.

The W3C recently chartered a working group to look at protocols for distributed communication using XML. This XML Protocol WG is taking SOAP 1.1 as the starting point and should complete its work toward the end of 2001.

Until then most of these specifications will remain the publications of a small number of companies. UDDI will likely be handed over to a standards body late next year, and possibly WSDL will be folded into that effort soon. While there has been a lot of consolidation, it still remains to be seen how widespread the adoption of some of these specific technologies will be. There are alternatives, such as HP's e-speak.

Of course, all these initiatives are just the infrastructure that enables businesses to communicate. Layered on top of what's been discussed is the whole area of XML vocabularies specific to the business being conducted. But that's another topic.