Rebecca, Why is there absolutely no mention of the BPEL standard in your presentation? Is BizTalk Server 2004 really that light on BPEL support? Overall, nice content and thank you for sharing.

Great Q... I spoke to the slides in context of WS-* interop. I generally don't think of BPEL4WS as an interop spec. Oooh I know that there is lots of dialog to be had on this topic. I have had it with many people. Scott Woodgate and I already spent hours on the topic. BTW: He disagrees with me. Regardless, as a spec, it should be represented on the deck. So my arguement on why I do not view it as an interop spec is as such: I view BPEL4WS more as a standard format for expressing business process flows, but unlike WS-Transactions or other specs, there will not be heterogenous systems in a deployed environment executing a schedule. thoughts?

Good points, Rebecca. As you have hashed over this with Scott at length, I won't dive into a deep BPEL perspective. I am disappointed that Microsoft isn't doing more than a topical import and export of BPEL in BizTalk 2004. Hearing the Microsoft reps at the conference vendor exhibit in Baltimore reference BizTalk as a "superset" of BPEL functionality and BPEL as a "frontier specification" wasn't encouraging. Then, to not see any mention of BPEL in your slides... Anyway, I'm part of a recently funded software startup who sees the value and potential in BPEL and would love to deploy up-the-stack into commercial-grade BPEL execution engines (BizTalk, WebSphere, etc.). We are complementary to BizTalk and have had many discussions with well-qualified enterprises who want process portability including the ability to leverage BPEL's notion of abstract processes. Gartner has an interesting research document about BPEL which includes a BPEL market timeline. My read is that Microsoft is 6-12 months behind Gartner's conservative BPEL timeline. Thanks for the great dialogue.

Here's my perspective: BizTalk Server 2004 supports the import and export of BPEL. It is the first product from a platform vendor with support for BPEL. We think of BPEL as an interchange format between brokers or trading partners which is where it has the technically strongest use case. We don't think about it as cross-platform execution - the specification deliberately doesn't describe bindings to native platform components etc. and even if it were used as a starting point each platform would have to put so much proprietary stuff into the BPEL skeleton that's it would no longer be cross platform. On the other hand trading partners, or integration brokers sharing BPEL representations (their public process) with each other is extremely valuable and an appropriate use-case for BPEL. You can expect more volume on BPEL when we get to release to manufacturing.

Two observations on the released version of BizTalk Server 2004:
1) BizTalk Server 2004 imports BPEL, but then requires pre-processing and conversion to an XLANG/S assembly, prior to execution. Thus BizTalk isn't executing native BPEL.
2) When trying to export BizTalk-native process definitions to BPEL, there are several warnings about process components that will_not be exported to BPEL - as much as one third of the process definition.

I welcome your corrections to my understanding of BizTalk's BPEL handling.

Thanks.

Both of these observations are correct and are consistent we the value of BPEL. To clarify let me draw an analogy with WSDL. WSDL describes the interface of a service. The web-service runs on the .NET Framework or on another execution environment like J2EE - while the WSDL itself does not run the value is the platforms can now interop together and customers can take advantage of platform specific services for execution.

BPEL describes the public behaviour across multiple web services. For example a BPEL interchange document describes the public process shared between two trading partners (send a po, get an invoice, wait 5 hours for the next step etc.) The BPEL doesn't include the private process (why would I share with my trading internal details such as the SAP system, .NET component, map I used). The BPEL is imported (just like WSDL is imported) and it is executed on the .NET Framework. Other vendors will import BPEL and execute it on their platforms. In the reverse scenario I can export my public process in BPEL.

The deliberate constraints in BPEL mean it isn't suitable for the use-case of "native execution". Other vendors may add proprietary extensions into BPEL to do this but that will defeat the purpose and make it proprietary. Microsoft is committed to supporting the standard without proprietary extensions.

BPEL just like WSDL is "less common demoninator". What that means is there are things you can do on the .NET framework that can't be described in WSDL and the same hold for process execution on the .NET framework that can't be described in BPEL.

BPEL will become much more useful for customers when other vendors implement support so we have something to export to an import from to support the interchange use case.

Hopefully that helps.

Thanks, Scott. I appreciate your taking the time to explain this. I know BTS2004 was a massive development effort - congratulations on getting it out the door.