BPMN2BPEL transformation with Fujaba - a Case Study

Transcription

1 BPMN2BPEL transformation with Fujaba - a Case Study Ruben Jubeh SE, Kassel University Wilhelmshöher Allee Kassel ruben.jubeh@uni-kassel.de ABSTRACT We have modeled a BPMN to BPEL synthesis transformation for the GraBaTs 2009 Tool Contest with the Fujaba Tool Suite. The basic problem of transformation is to create a hierachical a block structure out of a given flow graph. We use the same approach as already successfully implemented in the Fujaba code generator CodeGen2, which transforms amongst others SDM diagrams with arbitrary control flow into java code, which is as well formed as block structure. 1. INTRODUCTION This paper reports on our case study with the Fujaba environment, cf. [ on building a BPMN to BPEL transformation for the GraBaTs 2009 tool contest.the transformation reads a BPMN XML file as input and writes a corresponding BPEL XML file. The transformation is specified using Story Driven Modeling (SDM). Business Process Model Notation (BPMN) is a graphical notation for specifying business processes in a workflow. In this case study, the input BPMN models used just utilize a subset of the BPMN features. These simplified models consist of a set of typed nodes and directed arcs, forming a flow graph. Business Process Execution Language (BPEL) is an executable language for specifying interactions with Web Services. In contrast to BPMN, it is not a graphical notation, but a block structured language specified in XML. The central problem of this case study is now to transform BPMN into BPEL. A BPMN model is a directed graph. That graph has a dedicated entry node where traversal could start, but has possibly many paths from the entry node to the exit node. Paths split at a gateway node, either indicating a fork/parallel execution or a conditional branch. The graph might even contain cycles, depicting an iterative workflow. BPEL on the other hand, is a block oriented language. It forms a parse tree or abstract syntax tree. To generate BPEL, we need to construct such a tree. In our BPEL class diagram, all elements are TreeNodes, which have a parentchild relationship. Our transformation takes the flow graph and transforms individual fragments iteratively into a tree, which finally builds the output BPEL program structure. We used the same approach successfully for the Fujaba code generator, called CodeGen2 [1]. The code generator transforms Fujaba class diagrams and SDM diagrams into source code and is specified in SDM as well. SDM diagrams consist of a (control) flow of activities, similar to the BPMN model. Those activities (among other types) represent nodes and transitions form directed edges of the whole control flow. A SDM diagram might have cycles, branches etc. as well, and transitions might be guarded, like in this case study. A subcomponent of the code generator, called the sequencer, is responsible for transforming the control flow into a block structured tree. Nodes of that tree, called the Token Layer, refer the original diagram elements. The token tree is constructed iteratively: the algorithm tries to identify a fragment in the control flow, replaces it with one token, adds the nodes of the fragment as token children, and continues with the next iteration. Code can be generated when just one root token remains by traversing the token tree in a bottom-up manner. We will explain that approach in more detail in section META MODELS AND FRAMEWORK At first we imported and reverse engineered the ProM [3] meta models for BPMN and BPEL, which seem to be quite complete. But they directly depend on a 3rd party graph library which handles the associations between the model elements, so type checking associations between concrete BPMN respective BPEL elements were not available. For that reason, we decided to re-model all required meta model elements by ourselfs. Furthermore, programming against a legacy / pure java library is difficult because the fujaba code generation relies on its own standard of access methods for associations. Figure 1: Graph class diagram The BPMN and BPEL model is build upon a very simple graph model, as shown in figure 1. Nodes belong to a NodeSet indicated by the contains-association and have connecting directed edges via the edges-association. There are subclasses which form the flow graph underlying BPMN

2 (FlowGraph and FlowNode) and a tree, which is the final underlying structure for BPEL. As we use an iterative transformation from the flow graph into a program tree, TreeNode and ProgramStructureTree are subclasses of the flow graph classes, so the program tree can form a directed flow graph as well. Note that FlowNode and TreeNodes refer to each other, so a mapping for the transformation is stored in our data model. For a BPMN model, there must be exactly one entry and one exit node. Nodes that split and join the workflow are called gateways in BPMN. Regular nodes are either gateways or activities. Only split nodes can have two or more successors, only join nodes can have more than one predeccessor node. There are two types of splits and joins: XOR splits indicate a switch-case flow, whereas AND splits indicate parallel execution. AND join nodes are used to synchronize parallel flow. This gives seven types of nodes, these are represented as separate classes in our BPMN class diagram, see figure 2. The common superclass Node has a many-to-many selfassociation edges, which allows to build a directed graph of nodes. As arcs/edges might have a guard, we store that guard in a separate object with source and target associations to FlowNode. This allows inconsistencies between those three associations, but this way it is much simpler to specify the graph transformation rules, as one doesn t have to specify a in-between edge object for each edge. Fujaba doesn t support edge attributes, for this use case this feature would have made the model more intuitive. Figure 3: BPEL class diagram 3. THE TRANSFORMATION Figure 4: Transformation class diagram Figure 2: BPMN class diagram Our BPEL meta model is shown in figure 3. All language constructs used are represented as individual classes. Associations are not necessary, because the common superclass TreeNode has a one-to-many self association children with preserved order, which allows to build a hierarchical tree of BPEL elements. Importing and exporting XML was implemented by hand using the JDOM library. The import/export code adapts to the Fujaba generated model elements and is as small as about 100 LOC each. Besides these classes, everything else was modeled using Fujaba. Figure 4 shows the class diagram of our transformation. The central class Transformation refers to both the input flow graph and the output program tree. It delegates the work to so called ReductionHandlers. Each reduction handler is responsible for identifying a certain basic structure in the input flow graph and transforming that fragment into a block structure by adding new nodes to the the program tree, whose child nodes become the previously identified fragment. That way, each transformation step performed by one handler instance removes at least one node from the flow graph and adds at least one node to the program tree. Currently, we implemented five reduction handlers. A handler provides a transform(node:treenode) method, which tries to identify a basic structure at the given node and then reduces it. In the following, we will have a detailed look at two of them: The sequence handler, although being the simplest transformation intuitively, is quite complex, because we have different cases reducing the sequence. The whole graph transformation rule for this reduction consists of five story ac-

3 tivities, connected with success/failure-guarded transitions in between. Note that a reduction should only return true, when it successfully identified and reduced a basic structure. The precondition, which is the first story activity, is that two BPEL activities are connected sequentially with just one incoming and outgoing edge each. Now we have to distinguish between three cases, which will be explained in reverse order, because we have the most specialized case first (both nodes are already a sequence) and continue with the next more general one if it fails: Two activities are in a direct flow (last story activity). The rule creates a BPELSequence instance, which replaces the two activities in the flow graph by disconnecting them and connecting the sequence instead to the pre/post set (multi-instance objects) nodes (edgeslink). The sequence becomes the parent node of the activities (children-link). Note that the sequence needs to be connected to the program tree (contains-link) and preserves the referring flow nodes (refers-link). There is already a sequence, either before or after the the current matching start tree node. All we have to do is push the activity node down as additional child of the sequence, and connect its predecessor resp. successors to the sequence. This is performed in story activity 3 and 4 respectively. Both connected nodes are already a sequence, which is the second story activity. We add all children of the second sequence to the first one and connect all successor nodes to it. The second sequence instance is deleted finally. node instance, which gets the two flow body nodes assigned as children. Similar to the sequence reduction, we have to connect the context (predeccessors, successors multi-instance nodes) and the program tree to it as well. The gateway nodes will remain unconnected. The remaining reduction handlers look similar to the parallel handler, consisting of a match activity, which identifies a basic structure of four nodes as max, and a operation activity, which creates at least one concrete BPEL tree node instance. We will explain the transformation with a running example, which is a simple workflow with two nested parallel flows, each one containing an activity (see figure 7). The transformation works as follows: 1. Copy the whole flow graph by creating a corresponding BPEL tree node. For the start node, a BPELReceive is created, for regular nodes, BPELInvoke instances are created. Gateways map to plain tree nodes. The number of nodes is reduced by one, because there is no mapping for the end node required. The copied nodes are connected using the edges association and form exactly the same graph structure. The result of the copy process for the given example is depicted in figure 11. The created tree nodes refer to their corresponding flow nodes, because in case of a gateway just the flow node holds the concrete type information. 2. The reduction iteration is a double nested iteration: we iterate over all reduction handlers and try to apply a reduction to the program tree, which is a flow graph at the first iteration. Each handler iterates over all tree nodes and tries to apply itself on it. The iterations are repeated until no handler can reduce any node anymore. It is easy to tell whether the transformation is finished successfully, because ten the tree contains no flow-connected nodes anymore. 3. The post-processing step verifies the program tree. As long as the given flow graph is transformable, the result tree contains only a single node having no parent, which will be assigned as root, Note that usually the start node is always the child of the root node, which is a sequence. Figure 7: Transforming a simple parallel flow example: given flow graph The ParallelHandler is responsible to identify a parallel flow with an And-Split and -Join gateway. The graph transformation rule consists of a matching story activity and an operation story activity (could be simplified into one). It looks for the gateways by searching the corresponding flow nodes holding the gateway type. The matched tree node must have two successors and a common join. Then it reduces this four basic structure nodes by creating a BPELFlow Figure 8: Transforming a simple parallel flow example: step 1 Note that for quasi-structured flow graphs, this algorithm is slightly modified, as described in section 4. We will now apply the basic transformation algorithm to our example (figure 7): In figure 11 you see the initial flow graph, identically with the one from figure 7 on the left and the corresponding

4 Figure 9: Transforming a simple parallel flow example: step 2 Figure 10: Transforming a simple parallel flow example: step 3 created initial program tree on the right. The tree is yet to be build, and the nodes still form the initial flow graph structure. Now three iterations will be performed to transform the graph (the program tree connected with flow edges is shown in left-to-right order in the following figures): 1. On the first iteration (figure 8, the ParallelHandler matches the node t12, together with the nodes b16, b18 and t19 a basic structure for parallel flow is identified. An instance b20:bpelflow is created, b18 and b16 become it s children, and the nodes t19 and t12 are removed from the tree. 2. Next, the parallel handler again matches: starting with t17, b15, b20 and t13 form another parallel flow. Note that b20 has tree children from the previous iteration step: b16 and b18. Those are pushed further down the program tree: a new b12:bpelflow instance has the children b20 and b15. Tree nodes t13 and t17 will be dropped. We still have one flow edge left, and already a program tree of depth = 3. The result of this iteration is shown in figure Finally, the sequence handler matches the nodes b14 and b21. A new b21:bpelsequence tree node is created, and the existing tree together with the node b14 is pushed down as children of b12. We now have the resulting program tree with b21 as root node, shown in figure QUASI-STRUCTURED FLOW GRAPHS Our rules ensure that split and join gateways have no more than two successors/predecessors. To transform a quasistructured flow graph (for an example, see figure 12), one Figure 12: Quasi structured flow graph could replace a gateway with more than two edges by a sequence of two (or more) gateways, each one limited to two edges. That way, the quasi-structured flow graph gets transformable again. The difficult part is to identify the edge that should connect to the created gateway. We are not using an analysis to determine that, we just try all edges iteratively in a backtracking algorithm, shown in figure 13. It modifies the flow graph, and when the reduction handler chain can continue transforming the graph, the method returns. Otherwise, the modification of the flow graph is reverted we continue with a different node/edge pair. This approach is not very runtime efficient, because for complex quasi-structured flow graphs, we basically do a brute-force modification with exponential runtime. But our experiences with CodeGen2 have shown that this is not a problem, because given flows are rarely that complex to make the transformation slow. 5. SUMMARY AND OUTLOOK This case study was a nice exercise for our Fujaba Case Tool. The transformation rules are intuitive and the iterative approach is easy to understand. Our approach reduces the problem down to (at the moment) five simple graph transformations, which identify basic structures and transform them individually. That way, the implementation can be easily extended to support more BPMN/BPEL features. The development of the transformation was greatly supported by the edobs [2] eclipse plugin, which visualizes the runtime object graphs, so one can follow the execution of the transformation in detail by stepping with the debugger and watch how the graph is modified. Adding a reverse transformation would double the graph transformation rules. Basically, we would run all transformation rules in reverse. Fujaba does not support that directly as language construct, so the rules have to be modeled in separate methods, without direct relation to the forward transformation. A triple graph grammar based approach might help here, as it would provide a bidirectional mapping between the flow graph and program tree modification operations. 6. REFERENCES [1] L. Geiger, C. Schneider, and C. Record. Template- and modelbased code generation for MDA-tools. In 3rd International Fujaba Days, Paderborn, Germany, [2] The EDobs Dynamic Object Browser [3] ProM Framework - Process Mining Toolkit

5 Figure 5: Graph transformation rule for reducing sequences Figure 6: Graph transformation rule for reducing and-flow to parallel execution

6 Figure 11: Transforming a simple parallel flow example: initial graph copy Figure 13: graph transformation for quasi-structured flows