I am glad to announce that I will attend the 25th International Conference on Software Engineering and Knowledge Engineering, SEKE’2013. The Conference will be held from June 27 until June 29, 2013, in Boston, Massachusetts. My presentation is due on the first conference day in the second session on process and workflow management.
The paper I am presenting is titled Detecting Portability Issues in Model-Driven BPEL Mappings and is one step in my recent work on code portability. You can find a preprint version of the paper here. It explains some of the reasoning behind the bpp tool, which I have introduced in a previous post and uses the tool in a particular case: Model-driven mappings. Techniques of model-driven development have been studied extensively in areas such as object-orientation, but not only there. Also the workflow, business process modeling, and service-orientation communities have seen a fair share of such approaches. There, typically high-level and domain-specific process models are transformed into executable workflow code. The point of using BPEL here is to have a target language that, being an open standard, is executable on and portable to any platform. This is basically also the assumption I put into question. I try to find out if the code produced by the mappings is really portable, or if it is only likely to work in the environment the authors of the respective approaches have used for experimentation.
In the paper, I look at three such mappings that translate a higher-level model to BPEL code. These are an academic mapping from BPMN 1.0, the mapping in the BPMN 2.0 specification, and a mapping from the ebXMNL Business Process Specification Schema (BPSS) (if you want the exact references, please have a look at the paper). The mappings are classified concerning their degree of portability in a qualitative fashion. Basically, the approach sorts them into one of the following categories:
- Widely Portable
- Partially Portable
- Limited Portability
The classification depends upon what type of code elements the mappings translate to. I use the bpp tool to analyze the code the mappings produce and look at the warnings this results in. Bpp builds upon test assertions. For every problematic code element, it lists a test assertion that can be used to detect a portability issue and qualify that issue in terms of its severity. In this manner, bpp works similar to the interoperability profiles published by the Web Services Interoperability Organization (WS-I): It defines assertions and limitations on existing standards. The WS-I aims at making services more interoperable, bpp aims at making them more portable. As this is in principle quite similar, bpp uses the same structure for its profile definition and also for its report fromat. For instance, a test assertion looks like this (you can see a complete listing here):
<testAssertion enable="true" id="bpp-r2"> <description>A process definition should not rely on the semantics of keepSrcElementName in a <copy> construct</description> <target>//*[@keepSrcElementName='yes']</target> <predicate>empty(//*[@keepSrcElementName='yes'])</predicate> <reporting true="passed" false="warning"/> <errorMessage>The process definition sets the keepSrcElementName attribute in a <copy> construct to yes</errorMessage> <diagnostic>limited portability</diagnostic> </testAssertion>
predicate specify XPath 2.0 expressions for detecting problematic elements and the
diagnostic parts describes the severity. This severity depends on the amount of runtimes that support the element – the less, the more severe a violation can be considered. A mapping is classified to the most severe category it violates.
The BPMN 1.0 mapping ends up being classified as nonportable (it uses non-standard elements for control-flow structuring), the BPMN 2.0 mapping as of limited portability (for reasons concerning data-handling mainly, especially because of the usage of the
parts syntax), and the ebXML BPSS mapping as widely portable. I don’t want to discuss all technical details here, but they can be found in the paper. I also had a look at several more approaches, which did not make it in the paper because of space limitations, and they basically resemble the same aspects: The biggest obstacle to portability in the mappings tends to be data handling – either because it is not specified at a necessary level, or because it uses a syntax that is not particularily portable.