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.