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.

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.

In one corner is the Business Process Execution Language for Web Services (BPEL4WS, but most often pronounced "bee-pell"). BPEL4WS is a business process and choreography API that was co-authored by IBM, Microsoft and BEA. Although it is completely proprietary and hasn't even been submitted to a standards-setting body, all three companies already have plans to support the specification in their solutions as though it were a standard. At the very least, IBM and Microsoft will be able to continue focusing on picking off each other's customers as well as BEA's.

Unfortunately, while the three companies steam forward on BPEL4WS, the rest of the world is standing in the other corner with a competing specification--the Web Services Choreography Interface (WSCI, pronounced "whiskey).

Unlike BPEL4WS, WSCI has taken the first step towards standardization through a submission to the World Wide Web Consortium (W3C) by BPMI.org (which also developed an alternative to BPEL4WS called BPML), Commerce One, Fujitsu Limited, Intalio, IONA, Oracle Corporation, SAP AG, SeeBeyond Technology Corporation, Sun Microsystems, and strange as it may seem, BPEL4WS co-author BEA.

This industry chasm over the handling of choreography and transactions in service oriented architectures (SOA), and the costs that could be associated with it, are not to be underestimated. Nor is BEA's duplicitous hedging by appearing as a proponent of both.

Forget for a moment the problem of interoperation, or lack thereof, should the industry not agree on a common language for this very critical part of any mission critical application. Let's suppose that BPEL4WS becomes the de facto standard, by virtue of BEA's, Microsoft's, and IBM's support for BPEL4WS in their application servers (which happen to be the application server market's three leading products). The three intellectual property owners would be in the driver's seat not only when it comes to Web services, but for a portion of the Web itself.

It will be exactly the scenario that I've warned about, where the intellectual property owners of one critical protocol could end up in control of an important part of the Internet. At the very least, if you end up being seduced by the promise of standards by using the two Web services protocols (SOAP and WSDL) that IBM and Microsoft shoved down the W3C's throat, it may not be long until you find out that your investment in open standards has locked you into using a proprietary technology.

As I have posited before, following a path where you eventually find yourself locked into a proprietary technology puts the intellectual property owner in control of a lot of things, including cost.

If BPEL4WS becomes the de facto standard for Web services choreography and transactions, will the intellectual property owners take advantage of you? That's not absolutely clear. Implying that there are barriers to BPEL4WS becoming a W3C standard, the W3C's Janet Daly said, "BPEL4WS has a [intellectual property] statement that, as it stands, makes it questionable as to whether it could be used as a foundation piece." That stands in stark contrast to the promise for WSCI, should it progress to the ratification stage at the W3C. The W3C recently adopted a royalty-free position with respect to the standards it ratifies.

Hinting at the Microsoft's potential to control the cost of Web services, WSCI co-submitter Iona Technologies' chief technology officer Eric Newcomer said, "The W3C is trying to take a hard stand on royalties and patents" and that "Microsoft is trying to move to a royalty-based model for the specification. This stalemate between Microsoft and the W3C is about the patent and royalties question."

So far, no legal document release exists that says BPEL4WS will be royalty-free. IBM and BEA have each told me that they have no interest in charging royalties for Web services choreography and transaction protocols. During my keynote interview of IBM's director of Web service strategy Bob Sutor at a CNET Networks-organized Web services conference, Sutor revealed IBM's plans to make its contribution to the BPEL4WS specification available on a royalty-free basis.

BEA's director of Web services strategy John Kiger is similarly committed to a royalty-free path. According to Kiger, "BEA has professed a commitment to making these specifications royalty-free. It remains to be seen if any of the other participants in the process are aligned with that goal. There has not been a submission of BPEL4WS to a standards body, and no intellectual property declaration exists." Echoing the concerns of Iona's Newcomer, Kiger said, "I don't know what Microsoft's position on this will ultimately be."

But Kiger also doesn't believe that industry division over the specifications for choreography and transactions could bring the entire Web services house of cards crashing down. "More important," said Kiger, "are security, reliability, and state. The work on WS-Security should be tackled by the end of 2003 and, recently, a royalty-free WS-Reliability specification was proposed by some companies. Then there's the issue of how you manage and maintain state information across a Web services dialogue. This is being called WS-Conversation. It covers multiple messages whose state must be independently managed. If we have those building blocks as standards, then you can have a very powerful service oriented architecture. BPEL4WS, on the other hand, is an important building block, but not critical to the Web services house."

I'm not so sure. For B2B integration, which has long been called the Holy Grail of Web services, it seems to me that transaction management and choreography are critical building blocks. If they are, then the question is whether the work so far done on BPEL4WS will find its way into the work that the W3C is doing on WSCI, and will it therefore be subject to the W3C's intellectual property policies. This appears to hinge on whether Microsoft is willing do what IBM and BEA have so far pledged--make their contributions royalty-free.

I asked Microsoft's director Web services technical marketing Steven Van Roekel, and he responded, "Microsoft has not made any decisions or announcements in this specific area." The last time we heard Microsoft say this, it also had to do with Web services protocols. During the US v. Microsoft antitrust proceedings, Microsoft Platform Strategy Group General Manager Charles Fitzgerald testified that, although Microsoft had not yet decided whether to charge royalties for Web services specifications under consideration at the W3C, it was at the time reserving the right to do so.

While the specifications in question at the time either turned royalty-free, or lost momentum at the W3C, it looks as though we could be in for another intellectual property-based controversy over Web services.

Why would Microsoft want to get at least some piece of patent-related action out of Web services? You don' t have to look much further than the 800-pound gorilla, IBM. According to some estimates, IBM's patents annually generate $1 billion in royalties. That's not chimp change, if you ask me.

With the lion's share of Microsoft's revenues coming from the licensing of Windows and Office, and with those franchises coming under increasing pressure from viable competitors such as Linux, and with other attempts to diversify (such as XBox) losing money hand over fist, Microsoft could use a healthy portfolio of patents to help secure its future.

Enter Web services. Should Web services become the rage they're expected to be, and if Microsoft can maintain at least some intellectual property rights to one or more of the essential Web services protocols, then the software giant is guaranteed a revenue stream at least for as long as Web services are important. One reason the trust busters were asking about Microsoft's intent when it came to royalties on Web services specifications is that should Web services become as important as operating systems or office application suites, Microsoft could end up with yet another monopoly. Precedent antitrust law, set by the U.S. Supreme Court, requires an antitrust remedy to prevent the current monopoly and others like it from being repeated.

My sense is that Microsoft will buckle under pressure from IBM and BEA and let BPEL4WS go royalty-free. Otherwise, BPEL4WS, or some portion of it, has no chance of becoming a standard, even a de facto one. In addition, any application server like IBM's WebSphere, Microsoft's NET, or BEA's WebLogic that supports BPEL4WS instead of another standard runs the risk of quickly becoming irrelevant.

BEA's Kiger thinks that the situation will work itself out. "There is a working group in W3C called WS Choreography Working Group and BEA is a member," Kiger said. "Our number one goal in this arena is to drive the industry to a single widely adopted, open, and royalty-free standard for choreography." Addressing BEA's hedge, Kiger said, "While we're working from two starting points --BPEL4WS and WSCI -- the W3C has a predisposition to WSCI. It's not clear at this point what the ultimate product will be or how close to WSCI it will be. The process within the W3C is an open process. All players can bring whatever they want to the table."

Hopefully, Microsoft, which is member of the W3C, will break the intellectual property logjam over BPEL4WS, thereby allowing that material to be taken into consideration as the W3C's Web Services Choreography Working Group starts to make progress.

Should Microsoft not break the logjam, or should it and its BPEL4WS co-authors IBM and BEA take it to a more IP-friendly standards setting body like OASIS where it can continue to reserve the right to charge royalties, then it will be up to you, your dollars and your application development plans to hold Microsoft's feet to the fire.

What can you do? Refuse to develop anything with BPEL4WS or the applications servers that support it (to the exclusion of something standard) until the specification is royalty-free. Furthermore, start demanding that Microsoft or any other company with patent claims to Web services specifications come clean once and for all by saying that any contributions that they make to Web services specifications that they co-author with others will be royalty-free.

And let's get it in writing. For example, even though IBM and BEA have stated their royalty-free intentions with respect to choreography specifications, we haven't seen either put it in writing. Without a more broadly encompassing promise, getting Microsoft and others to go royalty-free on the next Web services protocol will be like getting Iraq to come clean on its weapons. It will be up to the market (and the press) to look for the gotchas and to begin the arm twisting process all over again. Frankly, I'm getting a little tired of repeating myself.

Until this happens, the idea of Web services standards is in jeopardy and the chances of your organization becoming addicted to a proprietary, royalty-laden technology are significantly increased. Going that route improves your chances of getting locked into the vendors of a proprietary technology which, in turn, puts those vendors in control of your costs--precisely what you don't want.

What would you do? Are you willing to turn the control and cost of an important piece of your Web services infrastructure to a patent holder, or will you hold off on Web services development until you're assured of the benefits of using standards. Share your thoughts with your fellow ZDNet readers by using TalkBalk below or write to me at david.berlind@cnet.com.