Is XML required for Web services? Not necessarily. Developers have been designing and building "Web services-like" solutions for several years - long before the term Web services (or the Web, for that matter) existed. RPC introduced the concept of location transparency - distributed objects (DO) that could be located and utilized regardless of their location on the Network. Clients used IDL for describing and contracting services with distributed objects.

The Good
Web services initially appear to be Web-based versions of the old DO technologies we've been using for the past 10-15 years. While they share many of the basic concepts associated with DOs, they're designed to be accessible across company firewalls and to enable loosely coupled business process integration. Tightly coupled multienterprise systems have been around for decades, but they rely on vendor-specific tools, opening custom ports in your firewall and some proprietary data formatting or marshaling techniques. Web services' loose coupling and support for open standards enables a service to be modified without disrupting other components. This is very difficult in traditional client/server environments.

The term Web services may be a bit of a misnomer. Web services are really the evolution of multitier client/server infrastructures. One vision of Web services is to change developers' perceptions about the Internet. The Internet (not just the Web) is no longer an external network. It's a server (albeit a very large and insecure one) for systems deployment.

The Bad
Web services aren't yet ready for high-volume, highly available production deployments. Of the available specifications, SOAP is probably the most mature, and has been deployed by numerous vendors within their products. Robustness, however, is not necessarily part of its maturity. SOAP's simplicity sacrifices some of the robustness expected in more traditional environments, such as type safety, versioning, and guaranteed delivery. The current UDDI spec lacks support for distributed queries or generic query syntax, and is not being developed by a standards body.

Reliance on a Web service mirrors the old "vendor-proprietary traps" that companies fell into in the past. If company A relies on a Web service provided by company B, what happens to company A when (if) company B goes out of business, or ceases to offer the previously available Web service?

Security is always an issue - especially where the Internet is concerned. Using HTTP for RPC mechanisms (as recommended by SOAP) hides the underlying intention of the packets from most firewalls since the firewall thinks it's just passing along HTTP requests.

The Ugly
To paraphrase Alan Greenspan, there appears to be an "irrational exuberance" regarding registry-based initiatives. Many companies will use Web services only if there is a clear competitive advantage/ROI. I believe we'll see these registry-based initiatives mirror recent trends in the B2B space. Private registries will be implemented by large firms to enhance communications with their internal departments (since many of these departments are larger than some corporations). Horizontally oriented corporations will be the largest publishers to use publicly available registries.

There's a potential backlash against XML if it continues to be applied to situations that aren't necessarily appropriate. This is especially true for Web services: anything touted as a "revolution" usually fails to live up to the inflated levels of expectation. As with past initiatives, evangelists should avoid trends unless there's a demonstrated need for the technology. Businesses resolve their issues in a low-cost, highly reliable manner - not necessarily by jumping on the next technology bandwagon coming down the road.