Abstract. Model transformations facilitate to process source models and generate other artifacts, output models and source code, based on algorithms.
Generating Executable BPEL Code from BPMN Models Márk Asztalos, Tamás Mészáros, László Lengyel Budapest University of Technology and Economics Department of Automation and Applied Informatics {asztalos, mesztam, lengyel}@aut.bme.hu
Abstract. Model transformations facilitate to process source models and generate other artifacts, output models and source code, based on algorithms and well-defined rules embedded into model transformations. Current paper presents two model transformations developed in Visual Modeling and Transformation System (VMTS) that facilitate the transformation between two languages for business process modeling: BPMN and BPEL. We also discuss how our model transformations achieve the case study related evaluation criteria: completeness, correctness, readability and reversibility. Keywords: Model Transformation, BPEL, BPMN
1
Introduction
Model-driven software development (MDSD) approaches (for example ModelIntegrated Computing (MIC) and OMG’s Model-Driven Architecture (MDA)) emphasize the use of models at all stages of system development. They have placed model-based approaches to software development into focus. Model transformations appear in many, different situations in a model-based development process. Modelbased development and model-based environments are driven by model transformations. In this paper we introduce how we implemented model transformations restricted to structured process models as defined in [3]. Our environment, Visual Modeling and Transformation System (VMTS) [2] supports editing models according to their metamodels, and allows specifying constraints written in Object Constraint Language (OCL). Models are formalized as directed, labeled graphs. VMTS uses a simplified class diagram for its root metamodel (”visual vocabulary”). VMTS not only facilitates rapid modeling language development and modeling, but also efficient model processing techniques. There are two main means to access the models: (i) traversing model processors and (ii) visual model processors. Traversing processors access the models via an automatically generated-object oriented programming interface in an object-oriented language. It usually traverses the model graph, and the processing code is described in a general purpose language. In VMTS, the graph rewriting based transformations are defined with the use of two modeling languages: the Visual Control Flow Language (VCFL) and the Visual
2
Márk Asztalos, Tamás Mészáros, László Lengyel
Transformation Definition Language (VTDL). The activity diagram-like VCFL models control the execution order of the rewriting rules, while the rewriting rules are expressed with VTDL models. These VTDL models define the searched (left hand side, LHS) pattern and the replacement (right hand side, RHS) pattern of a rewriting rule, actually in VMTS the LHS and the RHS patterns are merged into a single model. Our transformation engine applies an instance-based matcher with both OCL and C# script support for constraint definition. In case of this engine, both the control flow models and the rewriting rules are processed with traversing processors and converted into executable code. With this technique VMTS model transformation engine represents an efficient model processing environment.
2
Solution
We have completed the first variant of the published case study, where transformation restricted to structured process models needed to be implemented. We have implemented the BPMN to BPEL and its reverse transformation presented in Section 2.1 and 2.2 respectively. In our model transformations, models are primary artifacts, which means that BPMN and BPEL models are transformed and the output models are also BPMN and BPEL models. Generating and parsing XML documents are not part of the model transformation definitions. However, a simple tool is provided that can be reached in VMTS to generate XML documents from BPEL models. Models can be created, viewed, and modified inside VMTS.
Fig. 1. Extended BPMN metamodel
Fig. 2. Extended BPEL metamodel
The BPMN and BPEL metamodels are presented in Fig. 1 and Fig 2. We extended the BPMN metamodel provided by the case study with three nodes: a BPMNComposite element that can contain other BPMN elements supports creating hierarchical models. BPMNTimerEvent and BPMNMessageEvent elements have been added in order to make the metamodel more complete.
Generating Executable BPEL Code from BPMN Models
2.1
3
Transforming BPMN to BPEL
Fig. 3. BPMN to BPEL Control Flow Model In [1], the algorithm of the transformation BPMN to BPEL defines 7 patterns. In each pattern, a well-defined BPMN structure is transformed to a BPEL structure. The control flow model of the transformation itself is presented in Fig. 3. The concept of our implementation is demonstrated on the transformation pattern (b) [1] (FLOWpattern): we fold the concrete pattern into a single model element of type BPMNComposite, therefore, a hierarchical model is generated from the original BPMN input model. This hierarchical model can be trivially translated into the corresponding BPEL model fragment. The transformation of the FLOW-pattern is realized with three rules in VMTS, the first one of which is presented in Fig. 4.
Fig. 4. 1st Rule of FLOW-pattern This rule matches a BPMNFork and a BPMNJoin element and another node (a simple or a composite) between them. In this case, an instance of the FLOW-pattern is found. The elements of this instance will be contained in a new BPMNComposite element, while the corresponding BPELParallelFlow element is created. The second and the third rules match the elements between the already found BPMNFork and BPMNJoin elements, create the corresponding BPEL elements and remove them to the BPMNComposite element created in the first rule.
4
Márk Asztalos, Tamás Mészáros, László Lengyel
All other patterns are performed similarly, elements of the instances of the patterns are folded into BPMNComposite elements that can be trivially mapped to the concrete BPEL composite element. 2.2
Transforming BPEL to BPMN
We perform the reverse-direction transformation in two main steps: (i) in the first step, we convert the BPEL input model into its hierarchical BPMN equivalent presented in section 2.1, and (ii) in the second step, the hierarchical BPMN model is flattened, and the valid BPMN model is generated. The control flow graph of the reverse-direction transformation is depicted in Fig 5. The model can be divided into six main parts. Part (1) creates and assigns a BPMNComposite element for each compound BPEL element, and also creates the initial nodes inside them (e.g. parallel fork and parallel join elements inside the BPMNComposite element for a Flow construct). Parts (2) - (6) process the internals of the FLOW, SWITCH, PICK, WHILE and SEQUENCE BPEL structured activities, and generate the corresponding BPMN activities inside the connecting composite BPMN elements.
Fig. 5. Control flow model of the reverse direction transformation Note, that we do not process the REPEAT and REPEAT-WHILE patterns separately, as they can be originated from the combination of the SEQUENCE and WHILE patterns. Each BPEL construct is processed using three rules: the first rule (in block (1)) creates the corresponding BPMNComposite element, and the other two rules process the contained elements of the current BPEL node, depending on the contained node is a single activity or another composite node.
a)
Rule RCInitFlow
b) Rule RCProcessFlow1
c)
Rule RCProcessFlow2 Fig. 6. Rules processing the FLOW BPEL structure
Generating Executable BPEL Code from BPMN Models
5
Fig. 6 illustrates a typical scenario for transforming a BPEL construct, namely the FLOW BPEL structure. The RCInitFlow rule creates a BPMNComposite node, a BPMNFork and a BPMNJoin element for each BPELParallelFlow element. The RCProcessFlow rule matches BPELSimpleActivities inside BPELParallelFlow nodes, and creates either a BPELTimerEvent or a BPELTask for each of them (the creation of these elements is controlled by additional constraints). The RCProcessFlow2 rule matches further composite nodes inside a BPELParallelFlow node, and their connecting BPMNComposite nodes (created in block (1) of Fig. 5) are connected to the BPMNFork and BPMNJoin (start and end) nodes of the container composite node.
3
Conclusions
This paper has presented the VMTS-based solution for the transformations between BPMN and BPEL business process models. The provided solution fulfills the evaluation criteria of the first variant of the published case study, namely: Completeness: The developed transformations cover the complete transformation of structured BPMN models, and the reverse transformation as well. Correctness: The presented solution is based on the realization of the given algorithm. Our implementation is the appropriate representation of the required algorithm; therefore, correctness does not need to be analyzed. Readability: We generate human-readable well structured XML document. The generated BPEL model is hierarchic and does not contain events. The results of the implemented transformations can also be presented in a visual way using VMTS. Reversibility: Our solution contains two transformations. The first one covers the BPEL to BPMN way, and the second one the BPMN to BPEL direction.
Acknowledgement The fund of ”Mobile Innovation Centre” has partly supported the activities described in this paper. This paper was supported by the János Bolyai Research Scholarship of the Hungarian Academy of Sciences. VMTS environment utilizes the user interface controls developed by Infragistics.
References [1] C. Ouyang, M. Dumas, A.H.M. ter Hofstede, and W.M.P. van der Aalst. Patternbased translation of bpmn process models to bpel web services. International Journal of Web Services Research, 5(1), January 2008. Available at: http://is.tm.tue.nl/staff/wvdaalst/publications/z9.pdf [2] VMTS Website, http://vmts.aut.bme.hu [3] Case Study: BPMN to BPEL Model Transformation, http://is.tm.tue.nl/staff/pvgorp/events/grabats2009/cases/grabats2009synthesis.pdf
