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
Despite the popularity of BPEL engines to orchestrate complex and executable processes, there are still only few approaches available to help find the most appropriate engine for individual requirements.
One of the more crucial factors for such a middleware product in industry are the performance characteristics of a BPEL engine.
There exist multiple studies in industry and academia testing the performance of BPEL engines, which differ in focus and method.
We aim to compare the methods used in these approaches and provide guidance for further research in this area.
Based on the related work in the field of performance testing, we created a process engine specific comparison framework, which we used to evaluate and classify nine different approaches that were found using the method of a systematical literature survey.
With the results of the status quo analysis in mind, we derived directions for further research in this area.
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
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.
More than five years have passed since the final release of the long-desired OASIS standard of a process language for Web Services orchestration, the Web Services Business Process Execution Language (BPEL). The aim of this standard was to establish a universally accepted Web Services orchestration language that forms a core part of service-oriented architectures and, because of standardization,
avoids vendor lock-in. By now, several fully conformant engines should have arrived in the market. It is our aim to shed light on this situation and to provide a comprehensive picture of the
current state of BPEL upport. We present an evaluation of the standard conformance of five open source BPEL engines.
To obtain these results we have developed betsy, a tool that allows for a fully-automatic standard conformance testing of BPEL engines. The results demonstrate that full standard
conformance in contemporary engines is still far from given.
Service orchestrations are a powerful tool for
implementing intra– and interorganizational business processes
that base on services. Several heterogeneous orchestration
languages can be found in contemporary IT landscapes. While
the Web Services Business Process Execution Language (BPEL)
is the de facto standard, others gain attention, including Windows
Workflow (WF) in the .NET segment. When integrating
orchestrations, incompatibilities between them can easily arise.
In this paper, we investigate an automated Petri net–based
integration between BPEL and WF to solve these issues with
behavioral adapter services. We provide a mapping of WF to
Open Workflow Nets (oWFNs) and implement it in a compiler.
Thereby, we integrate our approach with existing approaches
for BPEL and adapter synthesis and validate the integration
with a standards–based case study using the two languages.