The IT industry must love standards, to paraphrase Abraham Lincoln, "otherwise it wouldn’t have made so many of them." Nowhere is this love affair more obvious than in the emerging world of Web services. Industry consortia and standards bodies alike are pumping out a glut of specifications that define every element of a Web service's look, feel, functionality and operating environment.
It's enough to make even veteran software managers and developers lose hope. "We watch all of these emerging standards, and frankly they seem to be breeding like rabbits," says Greg Carter, CTO at Metastorm, developer of the e-Work business process management platform. "Every time we meet internally to refine our strategy, there’s a new standard or something that's subtly different in an existing one. It's been very challenging for us to figure out the best way to take advantage of them all."
Part of the problem is that Web services is still an evolving discipline, and as technologies and development techniques remain in flux, so do the commonly accepted rules for making sure everything works well together. In some cases, specifications exist to guide the low-level interactions of two services. Other times, the rules have loftier goals—to create an environment where far-flung services can track each other down and become part of a larger business process, all without their creators ever interacting or even anticipating that their services might one day have reason to work together. The ultimate goal for an increasing number of organizations today is a service-oriented architecture, an organizational framework for launching, locating and orchestrating Web services into flexible and reusable business activities.
