Características de las Boletas de Garantía

To deal with the challenges described in Section 4.2.2 we applied the separation of con- cerns paradigm to the model and code generation framework. Solutions of the described challenges can be integrated in the framework from separate components, which overlap as little as possible. This allows flexible reuse and combination of components in the model and code generation framework.

We made the observation that solutions for some of the described challenges highly depend on the application domain, the modelling context, and the execution environ- ment, while others are independent of the application domain. Hence, we introduced a common process modelling format and divided the framework into a domain-specific and a domain independent part like in compiler theory [6], where an intermediate lan- guage is used to allow language independent code optimization. However, it is not totally correct to identify a front end and a back end like in compiler construction, since the front end (the adapter for DSL model (I)) and the code generator (the generation templates (IV)) both depend on the DSL specific process format and thus are not independent from each other. Figure 4.14 depicts a structural view on the generation framework.

common process modelling format DSL specific process format

Figure 4.14: Model and code generation framework

• The process transformer and optimiser (II) and the process visitor (III) are do- main independent. They address general graph transformation problems and graph traversing independent to any concrete process modelling languages. These com- ponents access process descriptions that are represented in a common process

modelling format. The framework makes use of a process modelling format that was derived from the Standard Workflow Models [156]. For block-structured graphs it provides a common process modelling format that is based on WS-BPEL. • The other two components of the framework, the adapter for DSL process models (I) and the code and model generation templates (IV), directly access the process modelling format of the DSL that is used for modelling the input model. Hence, adapters and generation templates have always to be used in combination, i.e. they must use the same DSL specific process format.

The model and code generation framework not only allows to plug together compo- nents via common interfaces, but also provides a workflow that composes these compo- nents. Once the framework is configured, i.e. the components are registered and plugged in, the user only has to provide the input model and start the generation workflow of the framework. Figure 4.15 shows this generation workflow. It depicts the four states of the workflow execution (a)-(d) and the transitions.

1 2

1 2

transform common process graph

1

create common process model traverse standard process graph & apply code generation templates

1 DSL specific process format 2 Common process modelling format

<assign> <copy>

<from part=“ticketnumber” variable=“nextActionReq”/> <to part=“ticketnumber” variable=“setValueToObjectReq”/> </copy>

</assign>

<invoke name=“setValueToObject_SOR” partnerLink=“agilpro” portType=“agi:AgilproIssuer” operation=“setValueToObject” inputVariable=“setValueToObjectReq”> </invoke> ... II I III & VI (a) (b) (d) (c)

Figure 4.15: Code generation

(a) The first state of the workflow comprises the input process model that is repre- sented in a format specific to the DSL used for modelling the input process. (b) The second state is reached by applying the adapter on the input model. The

adapter creates a representation of the input process in the common process mod- elling format. To ensure traceability between the processing steps of the two pro- cess models, it further links the processing steps in the common representation format to the processing steps of the input model.

(c) The process transformer restructures and optimizes the process represented in the common process modelling format. For example it generates a block-structured graph. Though in state (c) the control flow of the two process representations differs, their processing steps are still linked to the respective processing steps of the other representation format.

4.2 Transforming PIM to PSM 81

(d) The last transition is used for model and code generation and ends in the final state (d) of the framework’s workflow. Therefore the process visitor traverses the pro- cess of state (c) that is represented in the common process modelling format. The code or model generation templates are called via a notification mechanism pro- vided by the framework.2 Like we can see in Figure 4.15 the workflow terminates with state (d) when the code or a new model was generated.

The main power of the model and code generation framework lies in the process transformer and optimiser (II)and the combination of a visitor-based and a template- based code generation approach ((III) and (IV)). (II) identifies SESEs in the process descriptions [112, 142]. SESEs are the basis for graph transformations that allow to gen- erated block-structured (WS-BPEL) code [241]. SESEs are also used to test the sound- ness of the process’s control flow in reasonable time [294]. (III) and (IV) combine the advantages of visitor-based and template-based code generation approaches (see also Section 3.3.2). The process visitor traverses the process flow of the input model and calls templates for workflow code generation. The visitor allows to generate the work- flow code in the sequence that is given be the process’s control flow. This is especially important for e.g. Sequences in WS-BPEL, where the process steps are performed ac- cording to the order they have in the WS-BPEL text file. The template mechanism has the advantage that generation templates can easily be derived from examples [65].

The framework allows graph transformation from flexible higher-level process de- scriptions into constructs that are provided through the target process execution language and supports users to easily implement code generation for process execution via com- plex invocation patterns.

4.2.4 Case Study

This section presents a case study that illustrates the code generation for the Create Offer process introduced in Figure 4.13 of Section 4.2.1.

Configuration of the Generation Framework

To generate BPEL4WS code the generation framework has to be configured first. Hence, the process transformer that transforms arbitrary processes into BPEL4WS and the pro- cess traverser that can process common block-structured process models are registered at the framework. While the process traverser is already provided by the framework, we use the Token Analysis component [274] as a process transformer. The adapter for AgilPro LiMo models and the respective BPEL4WS code generation templates for the AgilPro JBoss workflow engine (jBPM) are also registered at the framework. Now, the workflow of the generation framework can be executed as shown in Figure 4.15. Creation of Common Process Model

In the first step of the framework’s workflow, the adapter for AgilPro LiMo process models generates a representation of the input process in the common process modelling format. The resulting process is depicted in Figure 4.16 in UML concrete syntax (the common process modelling format itself has no concrete syntax representation). Further the adapter connects the respective processing steps of the two process representations.

Figure 4.16: Create offer process as common process model Transformation of Common Process Graph

The process transformer transforms the process generated by the adapter into a block- structured process. It implements the algorithm described in [112]. Figure 4.17 depicts this block-structured process. As we can see, an alternative block was generated from the decision and merge gateways.

Figure 4.17: Block-structured create offer process as standard process model in UML syntax

Generating the BPEL Code

In a last step, the block structured process is traversed and the BPEL4WS code gener- ation templates are applied. In the following we present some code excerpts generated by the code generation for the Create Offer process. The full version of the generated BPEL4WS code can be found in Appendix A.

Before the process visitor starts, statical information like partnerLinks, variables, and correlationSets is generated for the BPEL4WS process. Further, some initial in- vocations on the process engine are made (see line 1-129 in the BPEL4WS process in Listing A.1). Then the visitor starts to traverse the block-structured process description. For each node a scope is generated that gets the name of the node and contains the further processing instructions that are necessary for this node.

The first node the visitor accesses is the start node. For this node an empty process instruction is generated within a scope. Since the start node has no name the scope gets the default name (see code excerpt in Listing 4.3).

Listing 4.3: Generated BPEL code for start node

130 <scope name= " Defaultname "> <sequence >

132 <empty />

</sequence > 134 </ scope >

Next, a scope that contains the further processing instructions for the Create Offer node is generated in the BPEL4WS code (see line 135-292 in Listing A.1). The process execution engine has an execution context in which information about the process exe- cution can transiently be stored. The input data of each process node has to be copied

4.2 Transforming PIM to PSM 83

to the execution context. Listing 4.4 depicts respective BPEL4WS code for the OfferID input of the Create Offer step.

Listing 4.4: BPEL instructions for OfferID input data of Create Offer node

196 < assign name= " set_DTO_OfferID "> <copy >

198 <from part= " Ticketnumber " variable= " nextActionReq "/ > <to part= " Ticketnumber " variable= " setValueToObjectReq "/ > 200 </copy >

<copy >

202 <from expression= " string ('ID')"/>

<to part= " DataTypeIN " variable= " setValueToObjectReq "/ > 204 </copy >

<copy >

206 <from expression= " string ('0')"/>

<to part= " ValueIN " variable= " setValueToObjectReq "/ > 208 </copy >

<copy >

210 <from expression= " string ('OfferID ')"/>

<to part= " NameIN " variable= " setValueToObjectReq "/ > 212 </copy >

<copy >

214 <from expression= " number ('-1')"/>

<to part= " HashCodeIN " variable= " setValueToObjectReq "/ > 216 </copy >

</assign >

218 < invoke name= " setValueToObject_OfferID " portType= " agi : AgilproIssuer "

220 operation= " setValueToObject "

partnerLink= " agilpro "

222 inputVariable= " setValueToObjectReq ">

<correlations >

224 <correlation pattern= " out " set= " atmInteraction "/ > </correlations >

226 </ invoke >

To process the Create Offer step, again several BPEL4WS instructions are necessary. In line 227-239 the execution of Create Offer is started and the receive statement in line 240-246 waits for a notification that the processing step is completed. Finally the execution of Create Offer is stopped (line 247-259). Listing 4.5 shows some excerpts of the necessary processing instructions. Finally the result data Offer (line 260-290) is fetched from the process execution context.

Listing 4.5: BPEL instructions for execution of Create Offer node

233 < invoke name= " startAction_CreateOffer "

234 portType= " agi : AgilproIssuer " operation= " startAction " partnerLink= " agilpro " inputVariable= " startActionReq "> 236 <correlations >

<correlation pattern= " out " set= " atmInteraction "/ > 238 </correlations >

</invoke > 240 < receive

partnerLink= " atm " variable= " nextActionReq " 242 portType= " atm : FrontEnd " operation= " nextAction ">

<correlations >

244 <correlation set= " atmInteraction "/ > </correlations >

246 </ receive > ...

252 ...

<invoke name= " endAction_CreateOffer "

254 portType= " agi : AgilproIssuer " operation= " endAction " partnerLink= " agilpro " inputVariable= " endActionReq "> 256 <correlations >

<correlation pattern= " out " set= " atmInteraction "/ > 258 </correlations >

</invoke >

Another interesting part of the generated code is how the alternative is translated into BPEL4WS code. The block-structure that represents this alternative in the process flow is mapped onto a switch-statement in the process code. Listing 4.6 depicts the respective BPEL4WS code.

Listing 4.6: BPEL instructions generated for processing alternative

458 < switch name= " Defaultname ">

<case condition= " bpel : getVariableData ('checkGuardRes ',

460 'ValueOUT ')=1">

<sequence >

462 <scope name= " CheckOfferConditions "> ... 607 ... 608 </scope > <empty /> 610 </sequence > </case >

612 <case condition= " bpel : getVariableData ('checkGuardRes ',

'ValueOUT ')=0"> 614 <sequence > <empty /> 616 </sequence > </case > 618 </ switch > 4.2.5 Discussion

In the context of executable WS-BPEL workflow code, there exist a variety of solu- tions that provide hardly more than another concrete syntax (graphical instead of tex- tual) for WS-BPEL (cp. UML profile for BPEL [11], Oracle BPEL Process Manager [240], or the ActiveBPEL designer [179]). These solutions do not narrow the gap be- tween higher-level process descriptions and workflow execution. Tool chains that allow model-driven development and the generation of WS-BPEL code like the IBM WebSh- pere Tool Suite [128], still have restrictions that prevent all process models from being fully transformed [317, p.109]. To ensure the execution through workflow engines they impose restrictions on the types of modelling elements that can be used, such as loops [320, p.18]. These approaches further require manual model refinement at multiple ab- straction levels. [147] describes a generic mapping approach of business process models to other process-oriented representations by the means of XPDL. To our experience a generation of XPDL from higher-level process models does not have to deal with the