1.4 Who to Believe?

Reality, as always, lies somewhere between the optimist and the cynic. There are real advantages to using web services instead of systems such as CORBA, as well as real drawbacks.

The toolkits for SOAP and XML-RPC are far more convenient to use than CORBA or COM, and convenience matters. Perl programmers know that you don't have to run the fastest , just fast enough. (As the old joke says, I don't have to outrun the bear, I just have to outrun you). In a world in which development cycles are shrinking, and deadline pressures are growing, convenience leads to quicker development, which means higher profits.

Web services succeed in being lightweight, in the sense that it's easier to implement an HTTP server and client than it is to write an ORB or talk to one. As a result, there are SOAP and XML-RPC libraries for languages that don't have ORBs, and web services have spread further than CORBA, COM, and Sun RPC ever did.

While the AI pipe dream of UDDI servers reducing programming problems to a set of XML transformations has gone up in smoke, UDDI isn't a complete bust. For domain-specific applications, UDDI is still useful. For example, in bioinformatics you don't care which human genome server you search, so long as it has the data. A UDDI registry of searchable databases has been proposed to let programs say "I want to search the human genome" and respond by automatically finding a current list of servers.

Interoperability does remain a bugbear, though. The web-services standards are long and often nebulous, so it's quite easy to write a server or client that appears to conform to the standards but actually doesn't. There are interoperability suites and periodic "bakeoffs" in which toolkit implementers run extensive tests against one another to ensure interoperatability. However, there are many toolkits that have some interoperability problems, and the promise of transparent interoperability is still just that.