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.
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,
Cloud Computing has been one of the most vibrant topics in the last years. Especially Platform as a Service (PaaS) is said to be a game changer for future application development. Taking away most of the configuration work, it pledges to foster rapid application development which seems even more important in a world of complex scalable distributed systems. Whereas Infrastructure as a Service (IaaS) is in the process of consolidation and standardization, the PaaS market is largely fragmented offering varying ecosystem capabilities. In this situation, application portability is a major concern for companies utilizing PaaS to avoid vendor lock-in and to retain the ability for future strategical decisions. To categorize portability problems of PaaS, we define a model of current PaaS offerings and identify different portability perspectives. Starting from the model, we derive a standardized profile with a common set of capabilities that can be found among PaaS providers and matched with one another to check application portability based on ecosystem capabilities. We validate our findings with a comprehensive data set of 68 PaaS offerings together with a web-based application for portability matching. We also identify further portability problems by porting the application to different PaaS vendors, validating ecosystem portability and giving hints for future research directions.
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.