Right now, a lot of people think Web services, or "service-oriented architectures," are the Next Big Thing, and they're probably right. Why Web services? Every business computer lives in a network, and software has to deal with that. The marketing suits where I work at Sun Microsystems (SUNW
) like to say "the network is the computer," and they're not just talking about the computers we make.
"SUBTLE ANSWER." Problem is, it's hard to do business on networks full of different kinds of computers, and the industry has wanted to make it easier for a long time now. We've tried over and over again to extend the traditional "application programming interface" (API) over the network. The results, with names like CORBA and DCOM, came out too complicated, too fragile, and too expensive.
Web services provide a subtle answer to the problem. Software that has to work on the Net shouldn't have to understand about APIs. It just needs to know what kinds of messages it should send, and what it can expect to get back. It sounds obvious but, until recently, the players found it too hard to agree on what should be in the messages. Extensible markup language (XML) changed that. XML provides an easy way of packing and unpacking just about any data on any computer -- and making data into a chunk of text that fits nicely in a network message.
So, there you have it: Web services are an agreement to work with XML messages instead of APIs. Is that all it takes? In many cases, yes. Right now, many business systems are quietly doing their jobs across the network, exchanging XML messages.
POLITICAL PROBLEMS. I remember seeing an early one, back around 1999, inside one of the big Web portals. The project participants pulled together fragments of XML from many sources to build a flexible, personalized page for each user. I talked to the project architect and asked him how they designed the system for interchanging messages. "Um," he said, looking a little sheepish, "we e-mailed examples back and forth until we were happy. Then we put the system together." Your business probably has some of this kind of homegrown integration at work right now.
We'd all like something a little more automated and maintainable, hence the birth of "Web services." But while we're starting to see some useful business tools, there are problems: a scramble of acronyms, a herd of companies operating both in secret back rooms and in public committees, and a whole lot of industry politics.
There's no escaping those politics. The official public face of Web services is mostly IBM (IBM
) and Microsoft (MSFT
). This worries some people, and you don't have to be that paranoid to wonder whether these two make the best choice to design a simpler, cheaper, open future.
NO STOPPING PROGRESS. Politics aside, the suite of Web services technologies is growing awfully large and complex, it's far from finished, and people are wondering if it's going to end up working any better than CORBA and DCOM did. One important indicator will come when the big company projects turn into products: Microsoft's Indigo, Sun's Kitty Hawk, and whatever IBM is cooking up. They'll either be simpler, cheaper, and better than what we have now, and will change the world -- or not.
Meanwhile, those weeds are rustling. Amazon.com (AMZN
) is doing tens of millions of Web services transactions a day, without waiting for the "official" products and protocols. Salesforce.com (CRM
), eBay (EBAY
), and Google (GOOG
) are at work here, too. Far back in the bushes, some of the people who built the Web are advocating a radically simpler way of thinking about Web services, called REST (representational state transfer). It forms the basis of the new Yahoo! (YHOO
) Web-search service launched at the end of February.
Web services will happen. But they'll probably come at us from a surprising direction. Tim Bray, co-inventor of XML, is director of Web technologies at Sun Microsystems