In 2007, OASIS finalized their Business Process Execution Language 2.0 (BPEL) specification which defines an XML-based language for orchestrations of Web Services. As the validation of BPEL processes against the official BPEL XML schema leaves room for a plethora of static errors, the specification contains 94 static analysis rules to cover all static errors. According to the specification, any violations of these rules are to be checked by a standard conformant engine at deployment time. When a violation is not detected in BPEL processes during deployment, such errors are only detectable at runtime, making them expensive to find and fix.
Due to the large amount of rules, we have created a tag system to categorize them, allowing easier reasoning about these rules.
Next, we formalized the static rules and derived test cases based on these formalizations with the aim to evaluate the degree of support for static analysis of BPEL engines.
Hence, this work is the foundation of the static analysis capabilities of BPEL engines.
Today, process-aware systems are ubiquitous. They are built by leveraging process languages for both business and implementation perspectives. In the typical context of a Web Services-based Service-oriented Architecture, the obvious choice to implement service orchestrations is still the Business Process Execution Language (BPEL). For BPEL, a variety of open source and commercial engines have emerged. Although the BPEL standard document defines a set of static analysis rules which should be checked by engines prior to deployment to be standard conformant, previous work revealed that most engines are not capable of revealing all violations of these constraints, resulting in costly runtime errors later on. In this paper, we aim to improve the static analysis conformance of BPEL engines. We implement the tool BPELlint that validates 71 static analysis rules of the BPEL specification, show that the tool can be easily integrated into the deployment process of existing engines, and evaluate its performance to measure the effect on the time to deploy. The results demonstrate that BPELlint can improve the static analysis conformance of BPEL engines with an acceptable performance overhead.
Service-oriented systems are increasingly implemented in a process-based fashion. Multiple languages for building process-based systems are available today, but the Business Process Model and Notation (BPMN) is becoming ubiquitous. With BPMN 2.0 released in 2011, execution semantics were introduced, supporting the definition of executable processes. Nowadays, more and more process engines directly support the execution of BPMN processes. However, the BPMN specification is lengthy and complex. As there are no official tests and no certification authority, it is very likely that engines a) implement only a subset of the language features and b) implement language features differently. In other words, we suspect that engines do not conform to the standard, despite the fact that they claim support for it. This prohibits the porting of processes between different BPMN vendors, which is an acclaimed goal of the language. In this paper, we investigate the standard conformance of open source BPMN engines to provide a clear picture of the current state of the implementation of BPMN. We develop a testing approach that allows us to build fully BPMN-compliant tests and automatically execute these tests on different engines. The results demonstrate that state of-the-art BPMN engines only support a subset of the language. Moreover, they indicate that porting BPMN processes is only feasible when using basic language constructs.
In 2007, OASIS finalized their Business Process
Execution Language 2.0 (BPEL) specification which defines
an XML-based language for building orchestrations of Web
Services. As the validation of BPEL processes against the
official BPEL XML schema leaves room for a plethora of static
errors, the specification contains 94 static analysis rules to cover
all static errors. According to the specification, any violations
of these rules are to be checked by a standard conformant
engine at deployment time. When a violation is not detected
in BPEL processes during deployment, such errors remain
unnoticed until runtime, making them expensive to find and fix.
In this work, we investigate whether mature BPEL engines that
claimed standard conformance implement these static rules.
To answer this question, we formalize the static rules and
derive test cases based on these formalizations to evaluate
the degree of support for static analysis of six open source
BPEL engines using the BPEL Engine Test System (betsy). In
addition, we propose a method to get more accurate static
analysis conformance results by taking the feature conformance
of engines into account to exclude false positives in contrast
to the classic approach. The results reveal that support for
static analysis in these engines varies greatly, ranging from
nonexistent to full support. Furthermore, our proposed method
outperforms the classic one in terms of accuracy.
The selection of the best fitting process engine for
a specific project requires the evaluation of engines according
to various requirements. We focus on the non-functional
requirement robustness, which is critical in production environments
but hard to determine. Thus, we propose an evaluation
framework to reveal important robustness criteria of process
engines. In this work, we focus on message robustness, i.e., the
ability to handle the receipt of invalid messages appropriately.
In a case study comprising five open source BPEL engines, we
determine message robustness by injecting faults into robustly
designed processes as a reply to a previously sent request from
an external virtual service and assert their behavior. The results
show that the degree of message robustness significantly differs,
hence, robustly designed processes do not necessarily lead to
robust runtime behavior, the selected engines still play a major
The Web Services Business Process Execution language (BPEL) is a standard
for modeling and executing automated processes and is tailor-made for service
orchestration. BPEL specifies a serialization format which every BPEL implementation
has to understand, thus allowing for the portability of processes among runtime engines.
Although the modeling and execution of BPEL processes is portable between engines
to a large degree, the lifecycle management of BPEL processes is not standardized and
varies a lot for different engines. This paper presents a first approach for a uniform
and cloud-based lifecycle management of BPEL processes and engines. We infer a
uniform interface for the lifecycle management from the capabilities of current engines
and provide a prototypic implementation of a tool that manages processes and engines
on a TOSCA-compliant infrastructure.
Nowadays, business processes and their execution are corner stones in
modern IT landscapes, as multiple process languages and corresponding engines
for these languages have emerged. In practice, it is not feasible to select the best
fitting engine, as engine capabilities are mostly hidden in the engine implementation
and a comparison is hampered by the large differences and high adoption
costs of the engines. We aim to overcome these problems by a) introducing an
abstract layer to access the functionality of the engines uniformly, b) by revealing
the engine capabilities through automated and isolated tests for typical requirements,
and c) support the user in their selection of a process engine by determining
and explaining the fitness of the engines for a single process or a given set of
processes using policy matching against previously revealed engine capabilities.
Early results show the general feasibility of our approach for BPEL engines for a
Keywords: BPM, process engines, engine selection, execution requirements,
Despite the popularity of BPEL engines to orchestrate complex and executable processes, there are still only few approaches available to help find the most appropriate engine for individual requirements.
One of the more crucial factors for such a middleware product in industry are the performance characteristics of a BPEL engine.
There exist multiple studies in industry and academia testing the performance of BPEL engines, which differ in focus and method.
We aim to compare the methods used in these approaches and provide guidance for further research in this area.
Based on the related work in the field of performance testing, we created a process engine specific comparison framework, which we used to evaluate and classify nine different approaches that were found using the method of a systematical literature survey.
With the results of the status quo analysis in mind, we derived directions for further research in this area.
Today, a plethora of enterprise middleware solutions are available, leading to the problem of choosing the right tool for a specific use case.
Automated tests can support the selection of such software by determining decision relevant metrics, like e.g., throughput or the degree of standard conformance.
To avoid side effects between tests, test isolation, i.e., to provide fresh instances of the software for each test execution, is essential.
However, middleware suites are inherently complex, provide a large range of configuration options, have tedious or sometimes manual installation procedures, and long startup times.
These idiosyncrasies aggravate the creation of fresh instances of such middleware suites, leading to slower turnaround times and increasing the cost for ensuring test isolation.
We aim to overcome these issues with methods and tools from the area of virtualization and devops.
In this work, we focus on BPEL engines which are common middleware components in Web Service based SOAs.
We applied our proposed method to the BPEL Engine Test System (betsy), a conformance test suite and testing tool for BPEL engines.
Results reveal that our method a) enables automatic creation of fresh instances of software without manual installation steps, b) reduces the time to create these fresh instance dramatically, and c) introduces only a neglectable performance overhead, therefore, reducing the overall costs of testing complex software.