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.
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.
The errors in BPEL processes that are only detected at runtime are expensive to fix. Several modelers and process engines for BPEL exist, and the standard defines basic static analysis (SA) rules as a detection mechanism for invalid processes, but the actual conformance of BPEL modelers and engines regarding these rules is unknown. We propose to develop test cases to evaluate the conformance of BPEL modelers and engines regarding static analysis. The evaluation results enable decision makers to identify and use the most conformant engine and modeler that detect errors before runtime and therefore reduce costs