In this chapter, we show how a BPEL process can be translated to a Petri net model an then exported to several output file formats. Consider the following simple BPEL process example.bpel:
<process name="exampleprocess" targetNamespace="www.gnu.org/software/bpel2owfn"> <partnerLinks> <partnerLink name="PL" partnerLinkType="PLT" myrole="exampleprocess" partnerRole="exampleuser" /> </partnerLinks> <sequence> <receive partnerLink="PL" operation="req" createInstance="yes" /> <reply partnerLink="PL" operation="ack" /> </sequence> </process>
This process just waits for a message req on partner link PL and replies to this message with ack on the same partner link. To parse this BPEL process, BPEL2oWFN has to be invoked with
bpel2owfn -i example.bpel |
which responds with the output:
============================================================================== GNU BPEL2oWFN 2.0.1 reading from file `example.bpel' ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ 3 activities (2 basic, 1 structured, 0 scopes) + 3 implicit activities 0 handlers (0 FH, 0 TH, 0 CH, 0 EH) + 1 implicit handlers 0 links, 0 variables [SYNTAX ANALYSIS] No syntax errors found. [STATIC ANALYSIS] No errors found checking 44 statics analysis requirements. [OTHER ANALYSIS] No other errors found. ------------------------------------------------------------------------------
This means, the process consists of three activities (two basic activities and one structured activities), no handlers, no links and no variables. On the bottom the analysis results are summarized: no syntactic, static, or other error was found.
Furthermore, three “implicit” activities are counted: The WS-BPEL specification describes several implicit transformations of the input process, as well as standard fault, termination and compensation handlers. In the considered BPEL process, no fault handlers are specified. Thus, a standard fault handler is added by BPEL2oWFN:
<faultHandlers> <catchAll> <sequence> <compensate /> <rethrow /> </sequence> </catchAll> </faultHandlers>
To see how the BPEL process looks like after applying the transformation rules and adding the standard handlers, BPEL2oWFN output the manipulated process using its pretty-printer:
bpel2owfn -i example.bpel -m pretty |
The manipulated process looks like this:
<process id="1" abstractProcess="no" exitOnStandardFault="no" name="exampleprocess" suppressJoinFailure="no" targetNamespace="www.gnu.org/software/bpel2owfn"> <partnerLinks> <partnerLink id="3" myrole="exampleprocess" name="PL" partnerLinkType="PLT" partnerRole="exampleuser" /> </partnerLinks> <faultHandlers id="4"> <catchAll id="13"> <sequence id="12" suppressJoinFailure="no"> <compensate id="11" suppressJoinFailure="no"> </compensate> <rethrow id="10"> </rethrow> </sequence> </catchAll> </faultHandlers> <sequence id="7" suppressJoinFailure="no"> <receive id="8" createInstance="yes" operation="req" partnerLink="PL" suppressJoinFailure="no"> </receive> <reply id="9" operation="ack" partnerLink="PL" suppressJoinFailure="no"> </reply> </sequence> </process>
Each activity is printed together with its attributes. Note that the standard values of several attributes (e.g., abstractProcess or suppressJoinFailure) are added. Furthermore, an identifier (attribute id) was added to every activity.
We now want to create a compact Petri net model of the BPEL process, using the petrinet mode and the small parameter:
bpel2owfn -i example.bpel -m petrinet -p small |
BPEL2oWFN now also displays statistics of the generated Petri net model:
|P|=5, |P_in|= 1, |P_out|= 1, |T|=2, |F|=6
The generated Petri net model consists of five places, including one input and one output place, two transitions and six arcs. To create a graphical representation, invoke BPEL2oWFN with the following options:
bpel2owfn -i example.bpel -m petrinet -p small -f dot -o |
This command creates a file example.dot, containing a Graphviz dot representation of the Petri net, and—if the dot
tool was found in the search path—a PNG (Portable Network Graphics) an image file example.png. The latter looks like this:
The graphic depicts the generated open workflow net. The inner of the net, that is, all nodes except the interface places, are depicted inside the dashed box, whereas the interface is depicted outside the frame. Input places and all connected transitions are colored orange. Similarly, output places and connected transitions are colored yellow. Gray places belong to the final marking, that is, the marking [p3] is the final marking of the oWFN.
To reach this final marking, the environment has to send a message in.PL.req, followed by receiving a message out.PL.ack. The name of the communication places is composed by the communication direction (“in” or “out”), the partner link's name (PL) and the operations name (req or ack).
For this very small process, it is easy to validate the generated Petri net model, that is, to compare the intended semantics by the actually modeled semantics. Especially the correlation between the nodes of the Petri net and the activities of the input BPEL process is not obvious for larger processes. To this end,
bpel2owfn -i example.bpel -m petrinet -p small -f info |
displays an information file, consisting of all the Petri net nodes' roles.
PLACES: ID TYPE ROLES p1 internal 1.internal.initial 7.initial 7.internal.initial 8.initial 8.internal.initial p2 internal 8.final 8.internal.final 9.initial 9.internal.initial p3 internal 1.internal.final 7.final 7.internal.final 9.final 9.internal.final in.PL.req input in.PL.req out.PL.ack output out.PL.ack TRANSITIONS: ID ROLES t1 8.internal.receive t2 9.internal.reply
This file has to be read as follows: the place p1 has the type internal (i.e., is not
connected with an interface place) and has the roles 1.internal.initial, 7.initial,
7.internal.initial, 8.initial, and 8.internal.initial. While the prefix of
each role is the identifier of an activity (1 for the <process>
, 7 for the
<sequence>
, and 8 for the <receive>
), the suffix specifies the role inside the
respective pattern. Without going too much into details, 1.internal.initial is the role of
the initial place of the pattern for the <process>
, whereas, for example
7.internal.final is the final place of the <sequence>
's pattern. Similarly, roles of
transitions are specified. Multiple roles of a single place arise due to the merging of distinct
places during the composition of the several patterns.
Now that we have convinced ourselves that the generated net reflects the intended behavior of the BPEL process, we can export the Petri net model to an output file to process it by analysis tools. In this case, we want to create a Fiona open workflow net executing
bpel2owfn -i example.bpel -m petrinet -p small -f owfn -o |
which creates a file example.owfn:
{ generated by: BPEL2oWFN 2.0.1 input file: `example.bpel' (process `exampleprocess') invocation: `bpel2owfn -i example.bpel -m petrinet -p small -f owfn' net size: |P|=5, |P_in|= 1, |P_out|= 1, |T|=2, |F|=6 } PLACE INTERNAL p1, p2, p3; INPUT in.PL.req {$ MAX_OCCURRENCES = 1 $}; OUTPUT out.PL.ack {$ MAX_OCCURRENCES = 1 $}; INITIALMARKING p1: 1 {initial place}; FINALMARKING p3 {final place}; TRANSITION t1 { input } CONSUME in.PL.req, p1; PRODUCE p2; TRANSITION t2 { output } CONSUME p2; PRODUCE out.PL.ack, p3; { END OF FILE `example.owfn' }
This is finally the oWFN model of the BPEL process that can be analyzed by Fiona1.