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.
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.
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.
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.
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.
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. Installability, 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 installability of service orchestrations based on the
Systems and software Quality Requirements and Evaluation
(SQuaRE) method, the new series of software qual-
ity standards currently under development by the ISO/IEC.
We develop a measurement framework based on SQuaRE and
tailored to evaluating the installability of service orchestrations and their runtimes. We validate the measurement framework theoretically and show its applicability in a case study.
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.