I just listened in on To BPEL or Not To BPEL, the title of which I believe resolves the pronunciation issue once and for all: although the presenter (Danny van der Rijn, principal architect at TIBCO) said “BEH-pull”, clearly it must be “BEE-pull” to make the title work. 🙂
Intended for those with a technical interest in BPEL, van der Rijn went through the history of BPEL from its origins as a melding of IBM’s WSFL and Microsoft’s XLANG, through the BPEL4WS 1.0 specification in 2002, 1.1 in 2003 and the soon-to-be-approved WS-BPEL 2.0. More importantly, he looked at why BPEL emerged: basically, the web services stack didn’t do enough to allow the orchestration of processes.
He then talked about what you’re not going to do with BPEL — it’s not a process modelling notation, it’s not for service creation — and stated that it’s not for portability: he mentions XPDL as a solution in that area (with no mention of BPDM). What I’m seeing, however, is that although BPEL may not have been intended as an interchange format, that’s exactly what it’s being used for in many cases. For many BPM engines, the “E” in BPEL is apocryphal: BPEL is a format that’s used to import process models from other applications, but it’s then converted to an internal (proprietary) format for the actual execution.
He covers off all the changes in 2.0: data, scoping model, message handling, activities and more, and walks through the basic BPEL components in some amount of detail. Overall, a good technical introduction to BPEL.
Unfortunately, about 40 minutes into the presentation, I received an “Invalid Flash Player Version” stating that I needed Flash Player version 8 to view the current content, and I lost all audio and video of the presentation. Flash? I was supposed to be using the Windows Media Player version of the presentation! On24.com really needs to get their act together: changing system requirements mid-presentation is not cool. Even when I installed the new Flash version and did a successful test, I wasn’t able to get back in. Guess that I’ll have to see the last bit in reruns.
If it’s not to create business processes or business services, what the heck is it supposedly for then?
–Bruce
His point was that it’s not a process modelling notation like BPMN, nor is it a development language for creating services like Java. Presumably, it’s for orchestrating those services once they’re already there.
BEE-pull (yes, I’m one of “those”) is all about orchestrating message flows across service endpoints using constructs that model many common business patterns. That’s what the original spec-writers intended; that’s what the OASIS WS-BPEL TC has been endeavoring to accomplish through four years of grinding effort. BPEL 2.0 will serve the IT community very well as the de facto (and soon published) service orchestration standard.
What are organizations going to do with BPEL? Lots of creative and valuable things. Today, some are using BPEL as a cornerstone of EAI, replacing proprietary products with ones that offer portability of IP and knowledge. Some are using BPEL in concert with advanced UI technologies to deliver composite, service-oriented applications. Some are using BPEL to expose course-grained business services to their customers and suppliers. And, yes, some are even using BPEL to (gasp!) automate their business processes.
Over the coming years, BPEL will be used (and in some cases misused) in a wide variety of applications. I believe BPEL’s adoption will be extensive – perhaps not evidenced as much by a meteoric rise as a rolling thunder. Ultimately we will see many different and important applications of BPEL that help organizations close the gaps between their people, their processes, their information technologies and their extended value chains.
I don’t spend a lot of time worrying about BPEL’s role relative to BPMN, XPDL, WS-CDL and other adjacent standards. I’m not religious that way. Organizations that need to create and manage conceptual process models are likely to do that in something like BPML, from which they will produce executable BPEL when that is their chosen deployment environment. I do believe, however, that advising IT audiences not to learn BPEL syntax and semantics (amazingly, I’ve read this and heard it spoken in the analyst community) is ill-advised. IT needs to learn BPEL for the same reasons it needs to know SQL – even if you’re using a higher-level tool most of the time, you will eventually need to get under the hood.
<blatant vendor self-promotion mode>
As an aside, in Danny van der Rijn’s webcast today, he (or his colleague) stated that migration from BPEL 1.1 to 2.0 is a difficult task. I would invite anyone who has an inventory of BPEL 1.1 processes to use our ActiveBPEL Designer tool (it’s free) to do the heavy lifting for you. Just load up your BPEL 1.1 process definition into the tool, Save As a 2.0 process, and presto – migration problem solved! There are a couple of semantics the tool can’t migrate without some human assistance, but the majority of constructs are handled automatically. Download a copy of the tool at:
http://www.active-endpoints.com/active-bpel-designer.htm
</blatant vendor self-promotion mode>
BEE-pull…is the pronunciation difference just like that concerning PROOH-ject or PROOH-cess as opposed to the obviously correct pronunciations PRAHH-ject and PRAHH-cess.
🙂 🙂
Bob, hard to say how the BEE-pull versus BEH-pull pronunciation wars will be resolved. However, the Americanized PRAW-cess is just plain wrong. 🙂
Fred, Bruce and I really do know what BPEL is intended for, but thanks for the refresher course. I’m not sure that I agree, however, that IT needs to learn BPEL they way that they know SQL — if the graphical modelling notations provide a complete representation of BPEL, why would you need to dig into the code?
Sandy, I realize that you, Bruce and others know what BPEL is and why it exists. But Bruce teed up the question “what the heck is it [BPEL] supposedly for then?”, so I thought his question should not go unanswered for those who are trying to sort out where BPEL fits.
In response to your question about graphical modeling notations and BPEL, let’s look at the characteristics of BPMN and BPEL to get some perspective. While BPMN provides rich constructs for expressing conceptual models, it does not require users to create those models in structured ways. BPEL, on the other hand, is all about execution, so BPEL’s semantics are highly structured to suit its purpose. For all the right reasons, BPMN is more expressive than BPEL, and BPEL is more strictly structured than BPMN.
It is easy to create conceptual models in BPMN that require significant restructuring to produce executable models in BPEL. (Note that I’m not saying BPMN inhibits structured modeling, only that BPMN does not require structured modeling.) While it’s true that flow path analysis and restructuring algorithms can automate some of the conversion from unstructured conceptual models to structured, optimized executable models, many conversions will require significant human re-engineering. Thus, analysts and engineers on the receiving end of a BPMN-to-BPEL conversion must be well versed in BPEL’s semantics to get their executable model to a deployable state.
Looking beyond BPMN-to-BPEL conversion issues, BPEL has many uses outside of the BPM domain. An example is the orchestration of message flows in composite applications. In these applications, BPMN (and other high level modeling notations) will often not be the tools of choice, and detailed knowledge of BPEL’s syntax and semantics will be needed to get the job done properly. This is where the analogies between SQL and BPEL are most relevant.
Fred, thanks for the feedback. If you’re using a process modelling tool that fully supports BPMN, then I agree that you would have to do some rework to make it work in BPEL since there are things that you can do in BPMN that just don’t translate directly to BPEL — that’s one of the major criticisms of BPEL. Some BPM vendors that use BPEL as their underlying serialization and/or execution engine restrict the BPMN that’s available in their modelling tool for exactly that reason: effectively, they expose the subset of BPMN that maps onto BPEL without requiring coding at the BPEL level.
Orchestration of message flows in composite applications is, arguably, within the BPM domain — it just depends where you draw the lines. 🙂
Sandy, as I said in a previous post here, I’m not religious about where the lines are drawn among things like BPM, EAI, B2B, workflow, etc. In contrast with the sometimes polarizing views expressed by others, I believe there are many shades of grey across these domains. That said, I have observed numerous SOA architects and developers using BPEL to build high-powered composite applications (regardless of whether one considers composite apps falling within the BPM domain), so perhaps the lines are drawing themselves. 🙂