When people ask me to define Web services, I tell them that it's primarily an idea hatched by IBM and Microsoft to steal customers from each other.

IBM, which is still licking its wounds over the loss of thousands of customers to Microsoft in the early 1990s, wants those customers back. Microsoft desperately wants to penetrate the datacenter where the remaining bastion of IBM's customers--most of them using mainframes-- resides.

Both companies have realized that in a world where successful transactions now depend on multiple, networked systems that talk to each other, stealing customers means replacing one or more of a competitors' components without causing so much as a hiccup in the overall system.

Why would you want to make such a substitution? The number one reason, especially given today's economic pressures, is cost. If you replace a component of your B2B network with another that costs half as much, the impact to your company's balance sheet isn't difficult to figure out.

[an error occurred while processing this directive]

But, on the heels of several architectural revolutions that were both painful and costly to technology buyers, IBM, Microsoft, and other vendors realize that customers aren't prepared to make such substitutions if the anticipated savings in technology acquisition or licensing charges are wiped out. Unless someone comes up with a layer of application programming interfaces (APIs) that completely insulate each system or component of a network-based application from the others, interchanging components will have financial hurdles.

Those APIs are the basis of Web services. Microsoft and IBM played a critical role in making sure that the first Web services protocol necessary to get the ball rolling--the Simple Object Access Protocol (SOAP)--was compatible with both of their solutions.

Sure, the promise of interoperability and cost savings via Web services is intriguing to IT shops. But the vendors have another motive in establishing a standard set of insulating APIs. Creating a more level playing field in the cost of switching vendors is less hazardous, and potentially favors those companies with the most market clout.

Once I get done explaining this to people, the next question is, "Why on earth would IBM or Microsoft want to make it easy to steal each other's customers?" Picture Clint Eastwood (IBM) and Lee Van Cleef (Microsoft) in one of those spaghetti westerns where each sees an opportunity to hit pay dirt, but they have to work together if either is going to have a chance at the booty.

Not only that, they'll have to trick the rest of the West's most notorious gunslingers (BEA, Oracle, Sun, etc.) into helping them. Ultimately, though, Eastwood and Van Cleef have no intention of splitting the loot--not with the other bad guys and certainly not with each other. Both know that they'll have to kill the bandeleros once they've served their purpose (industry-wide support for XML, SOAP, WSDL, UDDI and other Web services specifications). Then they'll have a death match of their own.

Throughout the movie, both know this is the plan, but neither would in a million years admit it to the other. Both are confident that they'll prevail. "Welcome to most important battle taking place in our industry today" I say as I finish my explanation of Web services.

One disclaimer: I randomly picked IBM to be Clint Eastwood and Microsoft to be Lee Van Cleef. I'm not implying that IBM will emerge victorious. That said, IBM is a far greater threat to Microsoft than it has ever been, and on all fronts-- technology, services, marketing, and public relations.

Unfortunately for the vendors who want to steal each other's customers and the customers who want to benefit from that war, there's a small problem. And, if the problem is not resolved soon, the entire Web services plan could end up being scuttled.

The bandeleros, whose assistance is imperative, were on board with the preliminary plans--the first few Web services APIs (XML, SOAP, WSDL, etc.). Those basic APIs are essential for dissimilar systems to hold hands, but another set of APIs is essential to making sure that those systems can go to the next level--dance.

In particular, to the extent that multiple systems are involved in the processing of a transaction or series of transactions, the order of execution of every step is imperative, as is the application's response if one of those steps fails. Whereas enterprise databases have long been capable of tracking transactions and rolling back data to its pre-transaction state should an error occur, choreographing a business process that involves multiple dissimilar systems, and then building in a similar degree of fault tolerance, is far more complex. These dissimilar systems--dance partners, if you will-- would need a common API if the dance were to result in an award-winning performance (successful transaction execution or roll-back) each and every time. It is this API and the current disagreement over it that is threatening the future of Web services.

1 2 3	| Next page

[an error occurred while processing this directive]

[an error occurred while processing this directive]