Microsoft already supports BPEL in its ESB product BizTalk Server. Now the company has announced its plans to support BPEL within the Windows Workflow Foundation (WF), which is integrated into Windows Vista. BPEL will be supported by a set of WF activities available as BPEL for Windows Workflow Foundation.
Paul Andrew, Windows Workflow Foundation Technical Product Manager at Microsoft, announces the release schedule:
[…] the CTP release will implement the BPEL 1.1 specification. The final release of BPEL for Windows Workflow Foundation will implement the OASIS BPEL 2.0 standard and is planned for release in Q4 of calendar year 2007.
BPEL 1.1 was subject to many debates. David Chappell opened up the case against BPEL (1.1):
One thing I think we’d all agree on is that every BPEL product vendor wants to do at least two things: sell its products to customers, then make sure customers can use those products to solve real problems. Promoting BPEL’s portability helps significantly in the first of these goals, since customers like the idea of not being locked in to a single vendor. But actually making customers successful has typically required extending BPEL in proprietary ways, which works against the language’s promised portability. While BPEL purists might argue that all of these extensions should be provided via programming language-neutral web services interfaces, this isn’t what’s actually happening in the products. And in any case, vendors still want to lock users in (which isn’t evil—it’s just good business). Adding proprietary extensions is an effective way to do this.
John Evdemon agrees and puts the blame on the shortcomings of the BPEL 1.1 spec:
I expect the portability of executable BPEL will be relatively low to non-existent. This is because the spec is missing some fundamental concepts for executable scenarios and vendors must extend the spec in non-standard (read: non-portable/non-interoperable) ways to get it to handle more detailed scenarios.
Oracle’s Edwin Khodabakchian counters by saying:
Saying that BPEL is useful for abstract processes but not for executable processes is out of touch with reality. Many vendors have support for executable BPEL processes today (Oracle, IBM, open source technologies like ActiveBPEL, etc). No one is using BPEL for abstract processes today. The BPEL technical committee is the largest at OASIS. The only vendors fighting BPEL today are those who are behind in the race to support it.
However, BPEL 2.0 addresses the shortcomings of its predecessors. According to James Pasley, chief technology officer at Cape Clear Software,
… [BPEL 2.0] has stayed true to the spirit of BPEL 1.1; you’ll be hard pressed to find new features in to BPEL 2.0. However, don’t be put off by the fact that the table of contents remains almost unchanged. BPEL 2.0 represents a significant improvement and is perhaps a perfect example of what a standards body such as Oasis can do for a specification. Rather than taking off in a new direction, the working group have conducted a root and branch review of the specification. In every area, clarifications and corrections have been made, providing a much more concrete and precise specification.
David Chappell remains sceptical on BPEL and BPEL integration into WF/BizTalk:
If the popularity of BPEL in BizTalk is any indication, we shouldn’t expect widespread use of WF’s BPEL support. I very rarely run across organizations that are using BPEL with BizTalk Server today, and I remain skeptical about BPEL ever achieving widespread popularity. Adding the ability to export and import BPEL workflows to WF—and thus to Windows itself—will help WF in situations where support for BPEL is a political necessity. Yet I’ll be surprised if it becomes a widely used aspect of WF applications.
It will be interesting to see, if the BPEL 2.0 implementations of Microsoft, Tibco and others will provide a means for developing portable, executable processes in the final releases of their products.
