Simon Harrer

BPEL conformance in open source engines

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.

Open Source versus Proprietary Software in Service-Orientation: The Case of BPEL Engines

It is a long-standing debate, whether software that is developed as open source is generally of higher quality than proprietary software. Although the open source community has grown immensely during the last decade, there is still no clear answer. Service-oriented software and middleware tends to rely on highly complex and interrelated standards and frameworks. Thus, it is questionable if small and loosely coupled teams, as typical in open source software development, can compete with major vendors. Here, we focus on a central part of service-oriented software systems, i.e., process engines for service orchestration, and compare open source and proprietary solutions. We use the Web Services Business Process Execution Language BPEL and compare standard conformance and its impact on language expressiveness in terms of workflow pattern support of eight engines. The results show that, although the top open source engines are on par with their proprietary counterparts, in general proprietary engines perform better.

Measuring the Installability of Service Orchestrations Using the Square Method

Service-oriented software consists of middleware, such as application servers and runtime engines, into which service applications are deployed. This middleware is often complex and difficult to install. The deployment of services requires the crafting of deployment descriptors and packaging of applications. As a consequence, the installation of service-oriented software systems can be a daunting task. Install ability, however, is an important influencer of the portability of software. Portability in turn is one of the main goals of service orchestration languages based on open standards. In this paper, we investigate the install ability of service orchestrations based on the Systems and software Quality Requirements and Evaluation (Square) method, the new series of software quality standards currently under development by the ISO/IEC. We develop a measurement framework based on Square and tailored to evaluating the install ability of service orchestrations and their runtimes. We validate the measurement framework theoretically and show its applicability in a case study.

BPMN Conformance in Open Source Engines

More than five years have passed since the final release of the long-desired OASIS standard of a process language for Web Services orchestration, the Web Services Business Process Execution Language (BPEL). The aim of this standard was to establish a universally accepted Web Services orchestration language that forms a core part of service-oriented architectures and, because of standardization, avoids vendor lock-in. By now, several fully conformant engines should have arrived in the market. It is our aim to shed light on this situation and to provide a comprehensive picture of the current state of BPEL support. We present an evaluation of the standard conformance of five open source BPEL engines. To obtain these results we have developed betsy, a tool that allows for a fully-automatic standard conformance testing of BPEL engines. The results demonstrate that full standard conformance in contemporary engines is still far from given.

Automated and Isolated Tests for Complex Middleware Products: The Case of BPEL Engines

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.

BPMN 2.0: The state of support and implementation

The Business Process Model and Notation 2.0 (BPMN) standard has been hailed as a major step in business process modeling and automation. Recently, it has also been accepted as an ISO standard. The expectation is that vendors of business process management systems (BPMS) will switch to the new standard and natively support its execution in process engines.This paper presents an analysis of the current state and evolution of BPMN2.0 support and implementation. We investigate how BPMN2.0 implementers deal with the standard, showing that native BPMN2.0 execution is an exception. Only three out of 47 BPMS considered support the execution format defined in the standard, although all of them claim to comply to the BPMN2.0 standard. Furthermore, we evaluate three process engines that do provide native BPMN support, namely camunda BPM, jBPM and activiti, and examine the evolution of their degree of support over a period of more than three years. This lets us delimit the areas of the standard that are considered important by the implementers. Since there is only a limited increase in supported features over the past years, it seems that the implementation of the standard is more or less concluded from the perspective of the implementers. Hence, it is unlikely that features which are not available by now will be implemented in the future. Only three out of 47 vendor implementations of BPMN do support the direct execution of the native BPMN format.These three implementations only support around half of the features of BPMN.The feature support is sufficient to implement at least 13 out of 20 workflow control-flow patterns.Erroneous process models are often not rejected at deployment.There is only a limited increase in feature support over the last four years.

BPEL Conformance in Open Source Engines: The Case of Static Analysis

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.

On the Evolution of BPMN 2.0 Support and Implementation

The Business Process Model and Notation 2.0 (BPMN) standard has been hailed as a major step in business process modeling and automation. Recently, it has also been accepted as an ISO standard. The expectation is that vendors of business process management systems (BPMS) will switch to the new standard and natively support its execution in process engines. This paper presents an analysis of the current state and evolution of BPMN 2.0 support and implementation. We investigate how current BPMN 2.0 implementers deal with the standard, showing that native BPMN 2.0 execution still is an exception. Most BPMS do not support the execution format, despite claiming to be BPMN 2.0 compliant. Furthermore, building on past work, we evaluate three process engines that do provide native BPMN support and examine the evolution of their degree of support over a three-year period. This lets us delimit the areas of the standard that are considered important by the implementers. Since there is hardly an increase in supported features over the past three years, it seems that the implementation of the standard is more or less seen as finished by vendors and it is unlikely that features which are not available by now will be implemented in the future.

Towards a Robustness Evaluation Framework for BPEL Engines

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 role.

QoS-Enabled Business-to-Business Integration Using ebBP to WS-BPEL Translations

Business-To-Business Integration (B2Bi) is a key mechanism for enterprises to gain competitive advantage. However,developing B2Bi applications is far from trivial. Inter alia,agreement among integration partners about the business documents and the control flow of business document exchanges, applying suitable communication technologies for overcoming heterogeneous IT landscapes as well as ensuring a Quality of Service (QoS) level that is sufficient for B2Bi are major challenges.In this context, applying choreography languages like ebXML BPSS (ebBP) for agreement among integration partners, orchestration languages like WS-BPEL for specifying partner-specific behavior, and Web Services for communication promises seamless interactions among business partners. In this scenario, the conformance of orchestration models to choreography models and cost-effective development are of paramount importance.Consequently, top-down approaches that automatically translate choreography models into orchestration models have been proposed.By now, the realization of QoS attributes has not yet received the necessary attention that makes such approaches suitable for B2Bi. In this paper, we describe a proof-of-concept implementation of a translation of ebBP choreographies into WS-BPEL orchestrations that respects B2Bi relevant QoS attributes.