Myths on BPEL

Like any other new technology, BPEL has its share of miscommunications and misconceptions.

Let’s consider a few of them:

• BPEL is a human interaction workflow language: FALSE

BPEL is focused on system-to-system interactions.The omission of native language support for human interaction scenarios is being addressed by BPEL4People.

• BPEL is well suited for programming in the small, that is, programming at the module level: FALSE

BPEL is better suited for programming in the large, that is, at the inter-module level (i.e. interconnection of modules). This issue is being addressed by BPELJ.

• BPEL provides a standard visual notation for representing business processes: FALSE

BPEL provides a standard language for specifying and executing business processes, the BPEL specification does not include a standard notation. However, there exists a business process modeling notation (BPMN) to BPEL mapping.

• BPEL provides process choreography, that is, means of specifying a network of communicating processes: FALSE

BPEL is not WS-CDL! BPEL specifies the interaction between peer business processes, and not among a network of several processes.

• BPEL is a declarative language, especially so as it is specified in XML: FALSE

BPEL, just like Java, and C/C++, is an imperative language, based upon states, statements, and the usual structured language constructs we are used to, such as if-then-else, switch-case, while, etc. Being specified in XML, does not make it more or less declarative.

• BPEL allows the modeling of long running processes: TRUE

BPEL provides native support for compensation handling, a very useful feature for modeling undo work needed to guarantee some form of atomicity when locking resources is prohibitive.

• BPEL allows the modeling of highly concurrent activities: TRUE

BPEL provides native support for concurrent flows and advance synchronization of these flows.

 

Advertisement