Process languages such as the Business Process Model and Notation 2.0 or the Web Services Business Process Execution Language promise the portability of executable artifacts among different runtime environments, given these artifacts conform to the respective specification.
However, due to the natural imperfectness and differing priorities of runtime environments, actual portability of process code is often hard to achieve. A first step towards tackling this problem is the quantification of the actual degree of portability of process code using software metrics. The ISO/IEC 25010 software quality model defines portability as a main software quality characteristic with several sub-characteristics. One of these is adaptability, the degree to which a piece of software can be adapted in order to be executed in a different environment. In this paper, we propose a mechanism for quantifying the degree of adaptability of BPMN 2.0 processes and demonstrate its computation.
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.
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
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.
Although BPMN 2.0 is an international standard widely used in practice, interoperability of process models is still an issue. Even between tools and engines claiming to be BPMN compliant the model exchange is often complicated or impossible as the tools produce incorrect model representations or do not support the standardized BPMN serialization format. In this position paper we present reasons for interoperability issues and show why defining a set of constraints derived from the standard is crucial to fix an important subset of those issues. We are currently developing a tool which can check this set of rules automatically.
Correct and standard compliant serializations of BPMN process models are crucial for model exchange between tools, automatic application of academic verification approaches and executability on BPMN engines. The official standard document does not provide an extensive set of all constraints regarding the correctness of model serializations. This technical reports fills this gap by presenting a categorized list of generic, technology independent constraints stated by the standard. Furthermore it is analyzed which rules are already covered when the standardized XSD-based serialization format is used.
Service orchestration languages, like the Web Services
Business Process Execution Language (BPEL), have been
frequently used to provide an implementation platform for
model-driven development approaches. As avoidance of
vendor lock-in and portability of process definitions are
central aims of BPEL, most approaches claim to support
a large set of different runtime environments. But, even
though today various runtimes for BPEL are available, every runtime implements a different language subset, thus
hampering portability. Our idea is to improve this situation by using techniques, the Web Services Interoperability
Organization (WS-I) has used to improve services interoperability. We describe a portability profile for BPEL that
can detect portability issues in process definitions. Using
this profile, we evaluate the portability of BPEL mappings
used in several model-driven development approaches.
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.
Business Process Model and Notation (BPMN) 2.0 process models are used more and more, both in practice as in academia. Although academic research mainly
focuses on sophisticated semantic checks and extensions there still exist problems in the basic usage of BPMN. This paper investigates issues in BPMN model serializations which arise as a result of the complexity and inconsistency of the standard document. We present a set of serialization constraints as a starting point for sophisticated compliance checks on serialized BPMN models. Furthermore, these constraints are used to perform an evaluation of current modeling tools. This evaluation reveals that the creation of standard compliant models is still a non-trivial endeavor.