What remains of the technology hype machine is currently buzzing about the goodness and the glory of what's to come through "Web services." But of all the "hot new things" that have ever rolled down the Internet pipeline, Web services are the most ill-defined. And what's particularly challenging is that, with the exception of some demonstration sites, this is not yet a reach-and-touch technology. You can't go to a Web site and see or do something and say, "Aha! Web services."
Folks who work in the publishing community should understand something about Web services because they probably have a lot to do with the future of Web content delivery. Somewhere in the dizzying array of breathless hype there's some truth in the idea that the future of XML is being written and the form it will take is in Web services. But the question is, in these cautious times for technology investment, is this a necessary plunge that should be made now or something that should be integrated into strategic plans for the future?
Defining Web Services
The fundamental idea behind Web services has been around for years. A company could get its software and its data to interact with another company if they shared a standard. This is not unusual. Two database companies, for example, could have made the decision to partner years ago and have selected a standard between them. But what if one of the companies decides it wants to share part of its database with a new company that doesn't use the same standard? Data sharing then becomes difficult and expensive, perhaps even requiring data to be re-keyed into the system.
Web services let various applications communicate with each other through the Internet. In theory this will allow software and data development to be streamlined. Let's say that a content developer wants to replicate another company's knowledge management system. With the Web services model, instead of buying a software package, the knowledge management company could syndicate its functionality to the content developer with only the addition of a few lines of code.
Web services' underlying standards are Internet-based. But Web services go beyond http and XML and use three recently created XML-based standards. SOAP (Simple Object Access Protocol) provides a platform independent way for applications to communicate with each other over the Internet. UDDI (Universal Description, Discovery, and Integration) is a Web-based distributed directory system (much like a telephone book) that's a standard way for businesses to list and query each other. WSDL (Web Services Description Language) describes Web service capabilities and is an integral part of UDDI. WSDL describes not only what Web service can be done, but also where it is and how to use it.
All of these have gone through the World Wide Web Consortium (W3C; http://www.w3.org) standards process, and new updates are already in the works. Web services will not stick with these standards as more will follow, but these three provide the essential foundation. Now, in the grand old tradition of standards and the Web, initiatives like Microsoft.NET and Sun's J2EE are already developing their own approaches using competing standards. This could undermine any hope of creating a distributed application-sharing network environment that is truly platform-independent.
Sorting It Out
One of the core issues that will need to be settled is rethinking information technology strategies. Instead of buying software and developing applications from the ground up, the new thinking will have to shift to a services-based model. In the current economic climate, the driving force to mediate such a change will likely come from more cost-effective and efficient operations as a result of Web services rather than from the development of new consumer services.
Although Microsoft stole the first round of thunder throughout last year with its assorted . …