Jörg Lenhard

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.

Performance Measurements of Tor Hidden Services in Low-Bandwidth Access Networks

Being able to access and provide Internet services anonymously is an important mechanism to ensure freedom of speech in vast parts of the world. Offering location-hidden services on the Internet requires complex redirection protocols to obscure the locations and identities of communication partners. The anonymity system Tor supports such a protocol for providing and accessing TCP-based services anonymously. The complexity of the hidden service protocol results in significantly higher response times which is, however, a crucial barrier to user acceptance. This communication overhead becomes even more evident when using limited access networks like cellular phone networks. We provide comprehensive measurements and statistical analysis of the bootstrapping of client processes and different sub-steps of the Tor hidden service protocol under the influence of limited access networks. Thereby, we are able to identify bottlenecks for low-bandwidth access networks and to suggest improvements regarding these networks.

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.

Measuring the Portability of Executable Service-Oriented Processes

A key promise of process languages based on open standards, such as the Web Services Business Process Execution Language, is the avoidance of vendor lock-in through the portability of process definitions among runtime environments. Despite the fact that today, various runtimes claim to support this language, every runtime implements a different subset, thus hampering portability and locking in their users. In this paper, we intend to improve this situation by enabling the measurement of the degree of portability of process definitions. This helps developers to assess their process definitions and to decide if it is feasible to invest in the effort of porting a process definition to another runtime. We define several software quality metrics that quantify the degree of portability a process definition provides from different viewpoints. We validate these metrics theoretically with two validation frameworks and empirically with a large set of process definitions coming from several process libraries.

Edit distance-based pattern support assessment of orchestration languages

Orchestration languages are of paramount importance when implementing business processes based on services. Several languages for specifying Web Services-based orchestrations are available today. Examples are the Web Services Business Process Execution Language or WindowsWorkflow. Patterns for process-aware information systems have frequently been used to assess such languages. Various studies discuss the degree of support such languages provide for certain sets of patterns. However, the traditional trivalent support measure is limited in terms of granularity and selectivity. This paper proposes an edit distance complexity measure that allows to overcome these issues. The applicability of this measure is demonstrated by an analysis of several orchestration languages using four different pattern catalogs.

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.

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.

On the Measurement of Design-Time Adaptability for Process-Based Systems

Today, process languages are frequently used for implementing service-oriented systems and a variety of specifications for this task exist. These specifications strive for the portability of processes among different runtime environments, i.e., process engines. However, direct portability, especially of executable processes, is seldom achieved. If processes cannot be ported directly among engines, an option is to adapt them. Such an adaptation is nontrivial and hence automated support is desirable. A first step in this direction is the quantification of the design-time adaptability of a process. This quantification is the goal of this paper. We formally define software metrics for measuring the design-time adaptability of processes and validate them theoretically with respect to measurement theory and construct validity using two validation frameworks. Moreover, we implement the metrics computation for Business Process Model and Notation (BPMN) processes and demonstrate their practical applicability with an evaluation of a large set of open source processes.