1.3 The Web Services Cold Shower

The previous section showed the positive side of web services ” open standards, cross-platform interoperability, and loose coupling. But it's only half the story. As web services are more widely deployed, developers have found holes and shortcomings in systems described earlier.

The XML-RPC specification, for instance, has no standardized error system. Sure, there's a way for a server to say "something went wrong," and it can even return an error string and number, but there are no standard values for the string and number. Each application invents its own error codes. (There is an effort outside the XML-RPC specification to come up with some standard error codes, and this is described in Chapter 3).

The SOAP standard uses advanced features of XML, such as namespaces and XML Schema types (Chapter 2 introduces these if you've never met them before). This eliminates some parsers, which can't handle namespaces, and increases the processing overhead.

There are some who say that XML-RPC and SOAP promote a misleading view of distributed computing; that any complex application built around remote procedure calls is inevitably going to be poorly designed and ineffectively implemented. The Representational State Transfer (REST) philosophy of web services offers a completely different view of how you should design your web services. You'll see REST in detail in Chapter 11.

The web services world is so fractious that even REST has its detractors. They say REST is too academic, it is theory that's difficult to translate into practice, and it avoids the hard problems of standardized encodings that XML-RPC and SOAP are designed to solve.

UDDI is arguably the biggest example of the web-services hype. At one point there were predictions of artificially intelligent (AI) programs that would discover and connect web services automatically, from standardized descriptions of functionality offered and wanted. However, there are no standardized descriptions of functionality, UDDI covered only a very small part of the business relationship that most large-scale web services needed to express, and ultimately nobody has felt the need for this kind of Holy Grail strongly enough to implement it.

In addition, all the web services protocols are easily criticized on grounds of performance. HTTP is far from an optimal transfer protocol, and XML isn't an economical encoding system. Custom systems and even the older systems, such as Sun RPC and CORBA, can out-perform a web services protocol such as XML-RPC or SOAP (though obviously a lot depends on your ORB, the types of messages you're exchanging, and so on).

As if that wasn't bad enough, there are critics of the standards process at the World Wide Web Consortium (W3C), which oversees the development of SOAP, WSDL, and an ever-increasing set of standards built on top of them. Those critics say that the standards process is driven by big vendors such as Microsoft and IBM, who are less concerned with finding the right solution to the problem than coming up with something that they can build a marketing campaign around and sell. A cynic would say that there's a large industry in manufacturing XML solutions to overinflated problems.