Microsoft, IBM, and BEA Systems have released a trio of proposed Web services standards to address several unmet requirements to realize the promises of the services-oriented application model. The August 12th release was part of the companies’ efforts to standardize business process workflow and execution to increase transaction reliability and synchronization. The standards included: Business Process Execution Language for Web Services (BPEL4WS), WS-Coordination, and WS-Transaction.

“The merger of WSFL and XLANG has been long anticipated, so it’s sort of an anticlimactic announcement,” said Brent Sleeper. “I will say that the tongue-twisting BPEL4WS moniker is horrible.”

Sleeper is a partner in The Stencil Group and a leading expert on the emerging Web services market. We interviewed him, Bernhard Borges, managing director of advanced technology practice at PwC Consulting, and several others in the Web services market. We asked about the significance of the BPEL4WS release and the impact it may have on the Web services market. Here’s what they had to say.

More about BPEL4WS
BPEL4WS will provide a standard programming language that businesses can use to define how to combine Web services to accomplish tasks. WS-Coordination describes how the individual Web services within that task will interact. The WS-Transaction standard will ensure that all the transactions are either successfully completed or fail as a group.

In the Web services protocol stack, BPEL4WS is a layer on top of Web Services Description Language (WSDL). It uses WSDL to specify actions that should take place in a business process, and to describe the Web services provided by a business process. IBM’s Web site offers a visual representation of this relationship, along with a detailed explanation of BPEL4WS.

BPEL4WS represents the uniting of two previously competing standards: Web Services Flow Language (WSFL) from IBM, and Microsoft’s XML business process language in BizTalk Server (XLANG). It is one of a number of emergent standards in the general area of Business Process Management. Others include:

Will BPEL4WS become a universal standard?
There is no question that BPEL4WS is a standard; the question is whether it will emerge as the dominant, de facto standard to describe and share processes within and among enterprises, said Borges. The second question is whether enterprises will be willing to share their process models with one another—an issue that will ultimately drive the success of Web services at large, he said.

Borges said he thinks enterprises will be willing to expose their process models because of the options that BPEL4WS provides. The specifications offer the “executable” approach, in which the process model reflects the actual behavior, and a “protocol” approach, in which descriptions specify the message exchange resulting from the process model.

“The latter approach is called the abstract process and does not reveal the internal behaviors and process maps of a particular model,” Borges said. “Of course, this level of abstraction requires additional efforts from a development and execution perspective.”

If the construction of that abstract process can be made reliable, secure, and relatively effortless—if tools automate the design based on the executable source, for example—Borges said he thinks BPEL4WS will provide a significant functionality necessary to the adoption of Web services. He believes BPEL4WS is very likely to succeed as the de facto standard and will have a significant impact on the redesign and deployment of processes within the enterprise, because of the disparate, but quite substantial, efforts around XLANG and WSFL.

“BPEL4WS builds on both WSFL and XLANG and has the necessary industry backing to become the dominant XML-based standard to share and describe process models,” Borges said. “Microsoft, IBM, BEA, WebMethods, etc. are all enthusiastically backing BPEL4WS in spirit and with product.”

Andy Astor, vice president of enterprise Web services for WebMethods weighed in with his opinion, saying that BPEL4WS has emerged overnight as the front-running standard. On first read, the specification seems to be a move in the right direction, combining some of the best features of WSFL and XLANG, he said.

“As with any new specification, it needs time to mature, but the pure marketing muscle of the Men In Black (Microsoft, IBM, and BEA) will give it the freedom to do so, in spite of it being perhaps the most awkwardly named specification in history,” Astor said.

Two opposing imperatives for orchestration standards
Sleeper said previous proposals have failed to garner support outside the sponsoring companies. However, it takes more than consensus to make a standard successful, he said. He suggested that there are two imperatives that BPEL4WS or any competing orchestration standards must address:

  1. Is the proposed standard really independent of a particular product implementation?
  2. Does the proposed standard support a variety of complex, stateful, asynchronous, business process interactions?

Sleeper said that one gripe with the XLANG and WSFL standards was that they reflected the way BizTalk and MQ, respectively, worked. He said he hopes that BPEL4WS will provide a strong platform for competing products like Collaxa’s, Iona’s, Avinon’s, Intalio’s, and others.

“It’s hard to do this in a generic way, and a risk is that the standard either becomes so unwieldy that no one wants to use it—like ebXML or BTP [Business Transaction Protocol] seem to be—or it remains so trivial that it can’t solve any of the hard problems,” Sleeper said.

Market impact of BPEL4WS: Competition based on standards
Sleeper said he believes that the introduction of the BPEL4WS is a harbinger for direct competition based on standards. For example, BPEL4WS is in direct competition with WSCI, pitting IBM and Microsoft against Sun and the rest of the pack.

“This use of standards is an axis of competition that’s only going to increase, for better or for worse, and I suspect IBM and Microsoft will muscle WSCI out of the way,” Sleeper said. “It’s interesting that BEA is working both sides of the fence.”

“I think we’re at or near the end of the practical realm of standards because the higher up the stack this stuff goes, the more it intrudes on vendors’ own product strengths and, potentially, customers’ own business process expertise,” Sleeper said. “Whereas things like SOAP, WSDL, and some form of orchestration all benefit from common understanding and implementation, anything higher in the stack—so-called horizontal standards driven by software vendors—are most likely just marketing vehicles.”

“Questions of semantics and business processes are really best addressed by industry groups in whatever vertical,” he said.

BEA hedging its bet on the future of Web services standards
Steve Brown agreed that BEA is working both sides of the standards fence by backing both BPEL4WS and WSCI and said that the battle for the Web services orchestration arena may eventually come down to a decision by the W3C.

“Rumor has it that BPEL4WS will actually be submitted as a subset of the next version of UDDI,” Brown said. “Or it may be settled earlier in a battle to become the de facto standard.”

Brown is CTO of Metastorm, a business process management (BPM) vendor that is tracking all BPM standards closely while maintaining a “firmly agnostic stance.” He predicts that a “division of spoils” is likely, with ebXML taking the large B2B interenterprise supply chain integration business currently dependent on EDI, and BPML taking the enterprise application-integration side of the BPM market. However, he said that eventually a Web services orchestration standard might supersede both ebXML and BPML.

“History again suggests that large, formal, complex standards, such as the OSI seven-layer communications model, x.500 directories, or ebXML, eventually lose out to simpler, de facto standards such as TCP/IP, LDAP, or the growing Web services protocol stack,” Brown said.

Yet which standards win out may be a moot point, Brown said. Since they’re all XML-based, automatic translation between competing standards may be possible to some extent via Extensible Stylesheet Language Transformations (XSLT), although he admits that differences in the underlying models—rather than in the syntax of the XML used to describe the models—may make this more difficult.

Competition breeds progress
The longer the current pandemonium of standards continues, the more confusing life becomes for customers and software vendors alike, Brown said. “In the end, of course, it will probably be the relative capabilities of the underlying execution engines that determine which standards rise to the top,” he said.

Regardless of which standard, or vendor, wins the battle for business process standards, Bill Ericson believes the competition is good for the development of Web services. Ericson is vice president of development at SwapDrive, a developer of online data backup systems.

“Anytime competing vendors get together to hash out some kind of standard for cross-platform/cross-business communication, it’s a good thing,” Ericson said. “There is no guarantee it will be the standard, or even accepted, but it does have a much better chance and it does address some of the problems facing e-commerce today.”