One of the most interesting paradoxes of the information age is the challenge of obtaining critical mass for a technology - the classic chicken-and-egg problem. Remember when you could buy your software on floppy disks because only a few people had CD-ROM drives? How about the plethora of high-density floppy drive replacements? Our industry has frequent problems adapting technology, in part because there are so many players, and so few who will work together. It's interesting to see that many folks regard Web services as yet another possible technology, but one without widespread adoption.

Interesting, but only partially true. It's definitely true that Web services are in their early stages - standards are being proposed, emerging, failing, and competing. Vendors are moving quickly to carve out their turf along the usual battle lines. There's Microsoft, of course, with its .NET vision and grand theories of being everyone's electronic wallet, and taking a small piece of every electronic transaction. Then there's the Open Standards group - Sun, IBM, HP, BEA, and the like-that champions a more utopian solution where transaction fees are left to individual vendors, and whose software provides the interconnectivity.

What most people are quick to point out is that some of the enabling technologies proposed for Web services are either on the drawing board, in committee, or have significant implementation challenges.

But what's ignored by those who want to keep Web services in a fluid state in order to seize the ideological and financial high ground is the fact that some forms of Web services are already widespread.

In our first issue we looked at Dun & Bradstreet's Global Access Toolkit, which allows customers to access the wealth of financial statistics that D&B provides as part of its own business processes. In this issue we discuss how Dupont is changing its business climate with Web services. Future issues will cover other well-known companies that are moving along with Web services.

Clearly, not all of these services meet the most narrow of definitions of Web services. I've had discussions with some technology companies that want to define Web services along very narrow, strictly technological boundaries. If it doesn't use UDDI, it's just not a Web service. If it's not a centralized server, it must be something else. These companies will undoubtedly be disappointed in my definition of a Web service, but there's a strong reason for adopting a broader view - adoption of Web services will be a business decision, not a technology decision.

If we've learned one thing from the dot-coms, it's that technology for technology's sake is a sure path to failure. It wasn't the Internet that was the revolution; it was the change in business models that resulted from increased connectivity that was the true revolutionary force. Sites like eBay aren't distinguished by technology - they're distinguished by business principles and superior service. Let's face it, almost all of the dot-com companies used the same technologies. And the brick and mortars cleaned their clocks, using the same technologies but providing better service. The myriad of Net markets showed the various industries that spot markets could in fact contribute value - but their business propositions had no underlying staying power because any large company with enough funding could create their own Net market and use their liquidity and established partnerships to drive the traffic to their site instead.

The same issue applies to Web services, and really to any new technological solution. There needs to be a business value for a technology, or there will be no adoption. A strict adherence to definitions of technology doesn't provide that business value. It doesn't matter if the service uses all of the components of the technology as long as it embodies the spirit of the technology. D&B provides information worldwide using an XML interface and some of the other components of the technology but has not implemented UDDI or WSDL. It's still a Web service.

In coming issues we'll focus on a variety of the technologies that will make Web services successful. Some, like UDDI, SOAP, ebXML, and WSDL, fit almost everyone's definition of a Web service. And that's good, because we have a common denominator of significant capabilities. But we'll also explore other aspects of the technology where definitions diverge - things like Business Process Management, Workflow Definition Language, and peer-to-peer computing. And we'll focus on business issues as well as technology, because business reasons will drive the adoption of Web services.

It's likely that you're reading this because you want to know about Web services - what they are, how to do them, what they can do for your business. And you've come to the right place. We're here to answer those questions. Stay tuned as we watch Web services evolve and grow.

Author Bio:
Sean Rhody is the editor-in-chief of Web Services Journal. He is a respected industry expert and a consultant with a leading internet service company. sean@sys-con.com