Just as rules are made to be broken, it sometimes appears that standards are made to proliferate. On the face of it, this may seem to be the case in the emerging battle over business process standards for Web services.

BEA Systems, Microsoft, and IBM introduced their Business Process Execution Language for Web Services (BPEL4WS) with much fanfare during the summer of 2002. In doing so, they added another clumsy acronym to what is becoming a battle to define the way Web services are combined and deployed to accomplish business tasks. BPEL4WS is just one of a number of emergent standards in the general area of Business Process Management, also known as BPM. Others include:

• WSCI: Web Services Choreography Interface
• BPML: Business Process Modelling Language
• XPDL: XML Processing Description Language
• BPSS: Business Process Specification Schema
• EDOC: Enterprise Distributed Object Computing

Of the competing standards, BPML is the most direct competitor for BPEL4WS, especially in the Web services arena. Both BPML and BPEL4WS actually form parts of rival standards' "stacks," with the familiar SOAP, WSDL, and UDDI standards as their common underpinning. Where BPEL4WS uses the (simultaneously announced) WS-Coordination and WS-Transaction standards to provide support for simple and extended transactions through Web services, BPMI endorses the WSCI standard as its Web services underpinning.

This combination and consolidation of standards is natural. BPEL4WS itself is the result of a merging of IBM's WSFL and Microsoft's XLANG. Time will tell if such a marriage of rival standards can last, but history suggests it can: the defining protocol of Web services - Simple Object Access Protocol (SOAP) - originated as a joint submission to the World Wide Web Consortium (W3C), by both IBM and Microsoft.

Decree or De Facto Standards?
With so much competition, it is clear that the struggle for standards is far from over. In fact, research from Gartner released in August suggests that the development of Web services standards won't be complete by 2007.

At the same time, enterprises are ready to begin Web services deployment today. They want to experience the decreased costs and increased integration promised by Web services and are anxiously looking for any clue as to how this battle will turn out.

This may eventually come down to a decision by the W3C. Oracle Corp. has already asked them to intervene on the issue. There have been rumors that IBM and Microsoft will submit BPEL4WS alongside the next version of the Universal Description, Discovery and Integration (UDDI) standard.

However, a decision from the W3C is not likely to come any time soon. It may take a long time for the organization to get anything to a recommendation stage. In the meantime, the hands of developers would be tied as they awaited a decision.

With that in mind, the question may be settled more immediately through the emergence of a de facto standard. Enterprises may be anxiously awaiting a formal standard, but they will not wait forever. They will soon start developing with their standard of choice. Once one standard emerges as a clear favorite among users, it will quickly outdistance its rivals. Thus, a de facto standard could emerge prior to a formal announcement from a regulatory body, and render any such decision unnecessary.

In the struggle to become the de facto standard, BPEL4WS appears to be the front runner, with Vitria and webMethods already signed up. Microsoft and IBM have a history of success in developing Web services standards. IBM already has, in Alpha, tools to build and implement processes in the language, and Microsoft can safely be expected to follow soon.

However, BPML and WSCI, whose combination presents the one direct challenger to BPEL4WS in the Web services arena, have been around a (very) little longer, and are likely to find champions among those who use neither IBM nor Microsoft. With the endorsement of BPMI.org and Sun Microsystems, the support base is very large. BPMI.org is also courting supporters of BPEL4WS by accepting the language, but positioning it as a subset of BPML (WfMC has taken the same approach with XPDL).

In both the short and the long term, the one criterion that will have the greatest effect upon the adoption of any of these standards is the availability of tools to build, deploy, and manage real systems that make use of them.

The final result, whether by decree or popularity, is still highly uncertain - which may explain why companies like BEA Systems are hedging their bets. In backing both BPEL4WS and BPML/WSCI, BEA assures itself of coming out on the right side no matter what happens. Alternatively, many intelligent companies are achieving the same goal by keeping a close eye on the struggle, while maintaining a firmly agnostic stance. This will keep them well positioned to act once a true standard emerges - though perhaps at the cost of any first mover advantage.

Beyond Web Services
Several of the proposed business process standards are not targeted at Web services. For these non-Web services BPM standards, each of the offerings will gravitate towards the areas that hold the most opportunity to exploit their advantages.

Large organizations looking to build secure, high-end B2B inter-enterprise integration in the EDI mold will look at BPSS (through ebXML) and EDOC. But it is at the lower end - the ability to orchestrate internal processes - that the real growth will be found. Here, BPML and BPEL4WS will battle for acceptance in the traditional EAI and BPM areas. XPDL is almost a non-factor, especially if WfMC gives up the fight and backs one of the other standards.

At the same time, the ability of BPEL4WS to address both Web services orchestration and traditional BPM and EAI requirements should give concern to some of these remaining players. For now, they have been content to stick to their specific niches and to leave Web services orchestration to a separate standard. However, IBM and Microsoft clearly see BPEL4WS as capable of expanding to handle both EAI and B2B processes. Proponents of niche standards may not have their market segments to themselves anymore.

Time and again, the industry has chosen simple de facto standards over complex formal standards. TCP/IP was embraced; the Open Systems Integration (OSI) seven-layer communication model has largely fallen by the wayside. The same fate may one day be in store for BPSS, if and when BPEL4WS sets its sights on the high-end integration market.

Does It Matter?
The major candidates for BPM standards today have one thing in common: all are XML-based. Supporters of BPML and XPDL claim they are supersets of BPEL4WS. Therefore it should, in principle, be possible to transform a definition written in any one of these into one written in the other, using XSL Transformations (XSLT). Such a translation would lose any meaning that is not available in the target language, but to some extent the choice of standards ought not to matter too much.

But in reality, it does matter. The longer developers are left with a confusing array of acronyms and competing standards, the more difficult life becomes for vendors and customers alike.

Today, both clients and suppliers are using Web services predominantly as "intra-enterprise glue." Organizations can now see their way to linking all their legacy systems without incurring the expense of traditional EAI systems, or hand-coded solutions.

The real beauty of Web services is not only in how easy it is to call (or "consume") an existing Web service. It lies in how easy it is to generate (or "produce") a Web service interface on top of an existing application programming interface (API), whether DCOM/COM+, Corba/IIOP, RMI, EJB, or traditional C or C++ native interfaces.

With the promise of Web services beginning to be realized, there is a danger of killing the momentum by not putting the best standards in place to facilitate the move from intra-enterprise deployments to inter-enterprise transactions. Standards development is necessary if we are going to realize the true promise of Web services.

Whether settled by the W3C, some other regulatory body, or the establishment of a de facto standard, it is incumbent upon those involved in the development of standards to consider the potential of the technology and the impact of the standard. There is a delicate balance between innovation and regulation. Reconciling the benefits of pushing the development envelope through innovation with the necessary establishment of standards will be one of the biggest challenges to the acceptance of a true standard for business processes.

But the biggest challenge of all will be in the provision of non-technical tools, based on the standard, which swing control of business processes away from technical departments and towards the business process owners themselves.

Author Bio
Steve Brown is chief technology officer of Metastorm Inc. (www.metastorm.com). Metastorm is the leading provider of Business Process Management (BPM) software to government and commercial organizations. sbrown@metastorm.com