Over the last years, the utilization of cloud resources has been steadily rising and an increasing number of enterprises are moving applications to the cloud. A leading trend is the adoption of Platform as a Service to support rapid application deployment. By providing a managed environment, cloud platforms take away a lot of complex configuration effort required to build scalable applications. However, application migrations to and between clouds cost development effort and open up new risks of vendor lock-in. This is problematic because frequent migrations may be necessary in the dynamic and fast changing cloud market. So far, the effort of application migration in PaaS environments and typical issues experienced in this task are hardly understood. To improve this situation, we present a cloud-to-cloud migration of a real-world application to seven representative cloud platforms. In this case study, we analyze the feasibility of the migrations in terms of portability and the effort of the migrations. We present a Docker-based deployment system that provides the ability of isolated and reproducible measurements of deployments to platform vendors, thus enabling the comparison of platforms for a particular application. Using this system, the study identifies key problems during migrations and quantifies these differences by distinctive metrics.
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.