Web Services - The Next Big Thing

Ed Yourdon
©2003 All Rights Reserved

Last week, I spent a day participating in a workshop on Web services with a group of high-powered IT executives and came away with some interesting impressions. In short, I believe this exciting, new technology is likely to move from "vision" to "reality" during the next year or two, and it could well spawn a new revolution in IT services and products.

Indeed, Web services are already a reality for many IT organizations, but that's primarily because they're implementing a rather limited version of the technology. Basically, Web services provide a collection of languages and protocols that enable software components to communicate with each other in a much more loosely coupled fashion than before. Not that we haven't been trying to do this before: the CORBA and DCOM technologies of the 1990s were a moderately successful attempt at facilitating the interaction between chunks of software on different computing platforms. But they generally required an unpleasantly tight degree of coupling between the components, which meant that a change in one component was likely to require a significant degree of reprogramming (and testing) in the others to which it was connected. And while CORBA/DCOM were specifically intended to support distributed computing, they tended to be implemented in the more narrow context of client-server computing, rather than today's paradigm of software components being located anywhere on the loosely connected Internet.

In fact, the initial applications of Web services are not likely to involve such grandiose notions as an application programmer at Citibank interacting with software components available, via the Web, with the First National Bank of Moscow or the Third National Bank of Bangladesh (if there are such banks). Instead, early adopters of Web services are using the technologies of XML, SOAP, and WDSL to integrate "stovepipe" applications within their own corporate boundary, in order to achieve enterprise application integration in a much easier, lower-cost fashion than before. The next step will be to use Web services to enable integration between "trusted" partners of a firm -- i.e., its long- standing suppliers, customers, and business partners with whom it has already developed a strong business relationship and with whom, for years, it has been attempting some form of computerized integration. Just as CORBA and DCOM supported some degree of distributed computing, electronic data interchange has been around for 20-plus years, supporting some degree of cross-enterprise computational integration. But XML, SOAP, and WDSL promise to improve the situation significantly, without a great deal of risk.

Meanwhile, there's one more component of Web services that represents the real revolution: UDDI, a technology for creating and querying "directories" of software components that may reside anywhere on the Internet (see http://www.uddi.org for details). Again, the big IT organizations have a fairly modest and conservative plan for employing this technology: creating private, internal UDDI directories of the various software components available to their own internal users. If, for example, you're a marketing manager in a huge multinational firm, it might occur to you that someone else within the vast reaches of the organization has already developed a spreadsheet/database component -- transformed into a Web service with XML, SOAP, and WDSL -- to keep track of the results of a new marketing campaign to sell the company's latest widget products. You don't have any idea where such a component resides on the company's thousands of servers, nor do you know who developed it, or even if such a component exists. But if such a component does exist, it's probably safer and more trustworthy than an externally accessible software component available from the marketing department of the Taliban. So if you can find a component you need, that provides the service you want, from a UDDI directory of internally available services, that would be useful indeed.

None of this is revolutionary. It's useful, it's productive, it could reduce some costs and improve productivity in some aspects of how IT organizations create, manage, and share their information resources internally and with their trusted partners. But the revolutionary aspect of Web services comes from public UDDI directories -- which provide information about, and access to, software programs and services to anyone, anywhere, anytime. Think of it as an interactive combination of google, Lycos, Yahoo, and AltaVista. Or, think of it as eBay on steroids. Or, think about it as a combination of Travelocity, Expedia, and the Web sites of every major airline and hotel in the world, to whom your Web site could send queries to help negotiate and organize the best-priced vacation within some constraints of budget, location, and schedule.

Actually, it doesn't really matter how you think about it because nobody has quite figured out what kind of "killer application" will emerge from this Web services vision. We know that all of the major vendors -- including IBM, Microsoft, Sun, Oracle, etc. -- are not only providing their products and tools in an XML/SOAP/WDSL environment, but are also beginning to provide tools for creating UDDI directories of Web services. We know that various applications and examples of such "public" Web services have been proposed and discussed, but we also know that large, conservative organizations are still worried about issues of security, scalability, interoperability, and so forth. Not only that, but many companies and investors are still licking their wounds from the dot-com hype of a few years ago. So perhaps we won't see any exotic applications or new business models for a while.

Or, maybe this will turn out to be another one of those MP3 revolutions. Maybe the brilliant innovative applications of Web services won't consist of traditional products and services introduced by General Motors and General Mills and General Electric -- maybe, instead, it will be a bizarre little game created by a college dropout, which can be played collaboratively by groups of people all over the world for a penny a game. Maybe it will be a charity organization that figures out how to use a Web services application to link donors and desperate recipients of the small-scale necessities of life -- a pair of socks, a bottle of aspirin, a schoolbook donated by a middle-class family in Idaho to a needy school child in Istanbul.

Maybe -- indeed, quite probably -- it will be something that our generation of middle-aged fuddy-duddies can't even imagine. Our generation tends to look at new technological innovations and ask, "Why?" as we try to find ways to cost-justify and defend the introduction of the innovation to the accountants and managers who run our companies. When shown the new innovation, the younger generation of teenagers and young adults asks, "Why not?" and experiments playfully with the technology to see whether it accomplishes something interesting. And an even younger generation -- the children who are being raised in an era of cell phones and Palm pilots and talking kitchen appliances -- doesn't even intellectualize the merits of a new innovation. Instead, they respond viscerally if the innovation intrigues them, and simply say, "That's cool!"

I certainly believe that Web services will be used in a productive, constructive, eminently businesslike fashion in the next few years by organizations that are simply trying to carry out their existing mode of business more efficiently. But, I also think that the full-scale implementation of Web services will provide the foundation for a revolution almost as comprehensive and far-reaching as the Web was in the mid-1990s. To get an overview of some of the things going on this area, visit http://www.webservices.org and http://www.xmethods.com -- but, perhaps more important, keep an eye on what your kids are doing because they are likely to be the ones who introduce the first tangible products of that revolution, in some area that you haven't paid any attention to at all.

Print page