Section 7.2. XPDL
7.2. XPDLXPDL,[7] a competitor of BPEL (Chapter 5) and BPML (Chapter 6), is the WfMC's XML process definition language. In the WfMC reference architecture, XPDL is the interface between process definition tools and the enactment service. Specifically, processes designed in a tool are exported in XPDL format and loaded into the enactment service for execution, XML being a suitable external representation. Other purposes of XPDL are to move process definitions between tools. A process definition tool should have both export and import capabilities: export to XPDL, and import from XPDL.
The WfMC does not prescribe a standard graphical notation language. Exactly how a given process definition tool represents a process visually is immaterial; what is essential is its support for the import and export of XPDL. 7.2.1. The XPDL ModelThe basic notions of XPDL and their relationships are depicted in Figure 7-3. The topmost entity is Package, which defines an entire application or a major system. A package consists of one or more workflow process definitions and supporting entities, which include participants (a list of human or system actors that perform key process roles), applications (programmatic components called by the process), and data fields (also known as workflow-relevant data). A workflow process, the central construct of XPDL, consists of one or more activities and a set of transitions. The mathematical idea of directed graph underlies this conception; each activity is a graph vertex; each transition is an arc connecting one vertex to another. The flow of a process is akin to the traversal of a graph: the process moves from one activity to another along routes specified by transitions. Additional features include conditional transitions and XOR and AND joins and splits, which give XPDL reasonable expressive power when rated on the P4 process patterns, including basic conditional and parallel branching, and still more advanced capabilities. XPDL activities fall into three categories: route, block, and implementation. A route activity performs no work but simply forwards control to the activities targeted by its outgoing transitions; route activities are typically used to manage control flow. A block activity is a set of activities having its own execution scope, reminiscent of the BPEL scope construct. The third type of activity, known as implementation, has three subtypes: null, tool, and subflow . A null activity is normally a manual activity, or an activity assigned to a human participant. A tool activity calls an invoked application through a tool agent. A subflow activity invokes another workflow process, either synchronously or asynchronously, as a nested subprocess. Figure 7-3. The WfMC XPDL model The key to understanding control flow in an XPDL process is to understand the organization of activities and transitions. XPDL's directed graph topology is markedly different from the structured programming style of BPEL and BPML (excepting BPEL's flow links, which mix directed graph semantics with BPEL's otherwise structured approach):
7.2.2. XPDL ExampleThe example of a travel reservation system, explored in earlier chapters, is used here to showcase several of XPDL features. The travel agency receives a customer's itinerary request, thenin parallelattempts to book hotels, car rentals, and flights. If all the steps succeed, the process prompts a travel agent to mail a confirmation to the customer. If some bookings failed, the process assigns a work item to a travel agent to contact the customer to fix the problem. The design of this process in the Enhydra Java Workflow editor (JAWE) is shown in Figure 7-4. Figure 7-4. The travel reservation process in Enhydra Java Workflow Editor (JAWE) The XPDL for this process is listed in Example 7-1. Example 7-1. Travel agency XPDL sample1 <?xml version="1.0" encoding="UTF-8"?> 2 <Package Name="Travel" xmlns=http://www.wfmc.org/2002/XPDL1.0 3 xmlns:xpdl=http://www.wfmc.org/2002/XPDL1.0 4 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance 5 xsi:schemaLocation="http://www.wfmc.org/2002/XPDL1.0 6 http://wfmc.org/standards/docs/TC-1025_schema_10_xpdl.xsd"> 7 <PackageHeader> 8 <XPDLVersion>1.0</XPDLVersion> 9 <Vendor>Together</Vendor> 10 <Created>2004-09-20 22:13:58</Created> 11 </PackageHeader> 12 <RedefinableHeader PublicationStatus="UNDER_TEST"/> 13 <ConformanceClass GraphConformance="NON_BLOCKED"/> 14 15 <!-- Three applications used by the process: one hotel, one air, one car 16 rental. Each takes in an itinerary and returns a result. --> 17 <Applications> 18 <Application Name="HotelApp"> 19 <FormalParameters> 20 <FormalParameter Mode="IN"> 21 <DataType> 22 <BasicType Type="STRING"/> 23 </DataType> 24 </FormalParameter> 25 <FormalParameter Mode="OUT"> 26 <DataType> 27 <BasicType Type="STRING"/> 28 </DataType> 29 </FormalParameter> 30 </FormalParameters> 31 </Application> 32 <Application Name="AirApp"> 33 <FormalParameters> 34 <FormalParameter Mode="IN"> 35 <DataType> 36 <BasicType Type="STRING"/> 37 </DataType> 38 </FormalParameter> 39 <FormalParameter Mode="OUT"> 40 <DataType> 41 <BasicType Type="STRING"/> 42 </DataType> 43 </FormalParameter> 44 </FormalParameters> 45 </Application> 46 <Application Name="CarApp"> 47 <FormalParameters> 48 <FormalParameter Mode="IN"> 49 <DataType> 50 <BasicType Type="STRING"/> 51 </DataType> 52 </FormalParameter> 53 <FormalParameter Mode="OUT"> 54 <DataType> 55 <BasicType Type="STRING"/> 56 </DataType> 57 </FormalParameter> 58 </FormalParameters> 59 </Application> 60 </Applications> 61 62 <!-- The process takes as a parameter an itinerary. 63 It uses three data fields, representing the results of 64 its calls to the hotel, air, and car rental applications. --> 65 <WorkflowProcesses> 66 <WorkflowProcess AccessLevel="PUBLIC" 67 Name="TravelWorkflow"> 68 <ProcessHeader DurationUnit="D"> 69 <Created>2004-09-20 22:15:14</Created> 70 </ProcessHeader> 71 <RedefinableHeader PublicationStatus="UNDER_TEST"/> 72 <FormalParameters> 73 <FormalParameter Mode="IN"> 74 <DataType> 75 <BasicType Type="STRING"/> 76 </DataType> 77 </FormalParameter> 78 </FormalParameters> 79 <DataFields> 80 <DataField IsArray="FALSE"> 81 <DataType> 82 <BasicType Type="STRING"/> 83 </DataType> 84 </DataField> 85 <DataField IsArray="FALSE"> 86 <DataType> 87 <BasicType Type="STRING"/> 88 </DataType> 89 </DataField> 90 <DataField IsArray="FALSE"> 91 <DataType> 92 <BasicType Type="STRING"/> 93 </DataType> 94 </DataField> 95 </DataFields> 96 <Participants> 97 <Participant > 98 <ParticipantType Type="ROLE"/> 99 </Participant> 100 </Participants> 101 102 <Activities> 103 104 <!-- The first activity is GetItinerary. It is a manual activity 105 performed by the travel agent role. When it completes, 106 it does an AND split to three submit activities. --> 107 <Activity Name="GetItinerary"> 108 <Implementation> 109 <No/> 110 </Implementation> 111 <Performer>TravelAgent</Performer> 112 <StartMode> 113 <Manual/> 114 </StartMode> 115 <FinishMode> 116 <Manual/> 117 </FinishMode> 118 <TransitionRestrictions> 119 <TransitionRestriction> 120 <Split Type="AND"> 121 <TransitionRefs> 122 <TransitionRef /> 123 <TransitionRef /> 124 <TransitionRef /> 125 </TransitionRefs> 126 </Split> 127 </TransitionRestriction> 128 </TransitionRestrictions> 129 <ExtendedAttributes> 130 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 131 <ExtendedAttribute Name="XOffset" Value="160"/> 132 <ExtendedAttribute Name="YOffset" Value="60"/> 133 </ExtendedAttributes> 134 </Activity> 135 136 <!-- SubmitAir calls the air application, passing the itinerary 137 and getting back a result. --> 138 <Activity Name="SubmitAir"> 139 <Implementation> 140 <Tool Type="APPLICATION"> 141 <ActualParameters> 142 <ActualParameter>itinerary</ActualParameter> 143 <ActualParameter>airResult</ActualParameter> 144 </ActualParameters> 145 </Tool> 146 </Implementation> 147 <Performer>TravelAgent</Performer> 148 <StartMode> 149 <Automatic/> 150 </StartMode> 151 <FinishMode> 152 <Automatic/> 153 </FinishMode> 154 <ExtendedAttributes> 155 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 156 <ExtendedAttribute Name="XOffset" Value="270"/> 157 <ExtendedAttribute Name="YOffset" Value="10"/> 158 </ExtendedAttributes> 159 </Activity> 160 161 <!-- SubmitHotel calls the hotel application, passing the itinerary 162 and getting back a result. --> 163 <Activity Name="SubmitHotel"> 164 <Implementation> 165 <Tool Type="APPLICATION"> 166 <ActualParameters> 167 <ActualParameter>itinerary</ActualParameter> 168 <ActualParameter>hotelResult</ActualParameter> 169 </ActualParameters> 170 </Tool> 171 </Implementation> 172 <Performer>TravelAgent</Performer> 173 <StartMode> 174 <Automatic/> 175 </StartMode> 176 <FinishMode> 177 <Automatic/> 178 </FinishMode> 179 <ExtendedAttributes> 180 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 181 <ExtendedAttribute Name="XOffset" Value="270"/> 182 <ExtendedAttribute Name="YOffset" Value="60"/> 183 </ExtendedAttributes> 184 </Activity> 185 186 <!-- SubmitCar calls the car rental application, passing the 187 itinerary and getting back a result. --> 188 <Activity Name="SubmitCar"> 189 <Implementation> 190 <Tool Type="APPLICATION"> 191 <ActualParameters> 192 <ActualParameter>itinerary</ActualParameter> 193 <ActualParameter>carResult</ActualParameter> 194 </ActualParameters> 195 </Tool> 196 </Implementation> 197 <Performer>TravelAgent</Performer> 198 <StartMode> 199 <Automatic/> 200 </StartMode> 201 <FinishMode> 202 <Automatic/> 203 </FinishMode> 204 <ExtendedAttributes> 205 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 206 <ExtendedAttribute Name="XOffset" Value="270"/> 207 <ExtendedAttribute Name="YOffset" Value="120"/> 208 </ExtendedAttributes> 209 </Activity> 210 211 <!-- Manual activity, performed by the travel agent, to 212 mail the itinerary to the customer. --> 213 <Activity Name="MailItineray"> 214 <Implementation> 215 <No/> 216 </Implementation> 217 <Performer>TravelAgent</Performer> 218 <StartMode> 219 <Manual/> 220 </StartMode> 221 <FinishMode> 222 <Manual/> 223 </FinishMode> 224 <ExtendedAttributes> 225 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 226 <ExtendedAttribute Name="XOffset" Value="480"/ 227 <ExtendedAttribute Name="YOffset" Value="20"/> 228 </ExtendedAttributes> 229 </Activity> 230 231 <!-- Manual activity, performed by the travel agent, to 232 call the customer to make modifications to the itinerary. --> 233 <Activity Name="CallCustomerForMods"> 234 <Implementation> 235 <No/> 236 </Implementation> 237 <Performer>TravelAgent</Performer> 238 <StartMode> 239 <Manual/> 240 </StartMode> 241 <FinishMode> 242 <Manual/> 243 </FinishMode> 244 <ExtendedAttributes> 245 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 246 <ExtendedAttribute Name="XOffset" Value="480"/> 247 <ExtendedAttribute Name="YOffset" Value="100"/> 248 </ExtendedAttributes> 249 </Activity> 250 251 <!-- Route activity: does a 3-way AND join from the submit 252 activities and then does 2-way XOR split to the mail 253 get mods manual activities. --> 254 <Activity Name="Route"> 255 <Route/> 256 <StartMode> 257 <Automatic/> 258 </StartMode> 259 <FinishMode> 260 <Automatic/> 261 </FinishMode> 262 <TransitionRestrictions> 263 <TransitionRestriction> 264 <Join Type="AND"/> 265 <Split Type="XOR"> 266 <TransitionRefs> 267 <TransitionRef /> 268 <TransitionRef /> 269 </TransitionRefs> 270 </Split> 271 </TransitionRestriction> 272 </TransitionRestrictions> 273 <ExtendedAttributes> 274 <ExtendedAttribute Name="ParticipantID" Value="Agency"/> 275 <ExtendedAttribute Name="XOffset" Value="380"/> 276 <ExtendedAttribute Name="YOffset" Value="60"/> 277 </ExtendedAttributes> 278 </Activity> 279 </Activities> 280 281 <!-- Highlights of the transitions: 282 1. GetItinerary routes to each of the submit activities. 283 2. Each of the submit activities routes to the route activity. 284 3. The route activity routes to MailItinerary if 285 airResult="ok" and carResult="ok" and hotelResult="ok". 286 Otherwise, it routes to GetMods. --> 287 <Transitions> 288 289 <Transition From="GetItinerary" 290 Name="Transition" To="SubmitAir"> 291 <ExtendedAttributes> 292 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 293 </ExtendedAttributes> 294 </Transition> 295 296 <Transition From="GetItinerary" 297 Name="Transition" To="SubmitHotel"> 298 <ExtendedAttributes> 299 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 300 </ExtendedAttributes> 301 </Transition> 302 303 <Transition From="GetItinerary" 304 Name="Transition" To="SubmitCar"> 305 <ExtendedAttributes> 306 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 307 </ExtendedAttributes> 308 </Transition> 309 310 <Transition From="SubmitAir" 311 Name="Transition" To="TravelWorkflow_Act7"> 312 <ExtendedAttributes> 313 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 314 </ExtendedAttributes> 315 </Transition> 316 317 <Transition From="SubmitCar" 318 Name="Transition" To="TravelWorkflow_Act7"> 319 <ExtendedAttributes> 320 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 321 </ExtendedAttributes> 322 </Transition> 323 324 <Transition From="SubmitHotel" 325 Name="Transition" To="TravelWorkflow_Act7"> 326 <ExtendedAttributes> 327 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 328 </ExtendedAttributes> 329 </Transition> 330 331 <Transition From="TravelWorkflow_Act7" 332 Name="Transition" To="MailItinerary"> 333 <Condition Type="CONDITION"> 334 airResult="ok" and carResult="ok" and hotelResult="ok" 335 </Condition> 336 <ExtendedAttributes> 337 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 338 </ExtendedAttributes> 339 </Transition> 340 341 <Transition From="TravelWorkflow_Act7" 342 Name="Transition" To="CallCustomerForMods"> 343 <Condition Type="OTHERWISE"/> 344 <ExtendedAttributes> 345 <ExtendedAttribute Name="RoutingType" Value="NOROUTING"/> 346 </ExtendedAttributes> 347 </Transition> 348 </Transitions> 349 350 <ExtendedAttributes> 351 <ExtendedAttribute Name="StartOfWorkflow" 352 Value="Agency;GetItinerary;90;60;NOROUTING"/> 353 <ExtendedAttribute Name="EndOfWorkflow" 354 Value="Agency;CallCustomerForMods;580;100;NOROUTING"/> 355 <ExtendedAttribute Name="EndOfWorkflow" 356 Value="Agency;MailItinerary;580;20;NOROUTING"/> 357 <ExtendedAttribute Name="ParticipantVisualOrder" 358 Value="Agency;TravelAgent;"/> 359 </ExtendedAttributes> 360 </WorkflowProcess> 361 </WorkflowProcesses> 362 363 <ExtendedAttributes> 364 <ExtendedAttribute Name="MadeBy" Value="JaWE"/> 365 <ExtendedAttribute Name="Version" Value="1.2"/> 366 </ExtendedAttributes> 367 </Package> The package travel has three applicationsHotelApp, CarApp, and AirApp (lines 17-60)and a single workflow process, called travelWorkflow (whose definition begins at line 65). travelWorkflow accepts a formal parameter itinerary (lines 72-78) and has three data fields airResult, hotelResult, and carResult (lines 79-95), as well as a participant called TRavelAgent (lines 96-100). The first activity in the process is a manual activity called GetItinerary (lines 107-134), assigned to the participant role TRavelAgency; the purpose of GetItinerary is for an agent to take an initial look at the itinerary and perform any initial manual processing. Upon completion, GetItinerary performs a three-way AND split to the tool activities SubmitAir (lines 138-159), SubmitHotel (lines 163-184) and SubmitCar (lines 188-209), which call the applications AirApp, HotelApp, and CarApp, respectively, passing in the itinerary formal parameter of the process and getting back a result field bound to the data field airResult, hotelResult, or carResult. A special Route activity (defined in lines 254-278) synchronizes with an AND join the results of the three tool activities and then branches with an XOR split to the manual activities MailItinerary (lines 213-229) and CallCustomerForMods (lines 233-249), each assigned to the role travelAgent. The direction of branching is determined by the evaluation of a condition; the transition to MailItinerary (lines 331-339) is activated only if the condition airResult="ok" and carResult="ok" and hotelResult="ok" is met; otherwise, the transition to CallCustomerForMods (lines 341-347) is followed. 7.2.3. XPDL ElementsThe following discussion captures at a very high level the basic programming elements and techniques of XPDL. 7.2.3.1 Basic process structureThe flow of a process is defined by its activities and the transitions that connect them. An XPDL flow is a directed graph. To build a basic sequential process of the form A <WorkflowProcess> <Activities> <Activity > . . . </Activity> <Activity > . . . </Activity> <Activity > . . . </Activity> </Activities> <Transitions> <Transition from="A" to="B"/> <Transition from="B" to="C"/> </Transitions> <ExtendedAttributes> <ExtendedAttribute Name="StartOfWorkflow" Value="A"/> <ExtendedAttribute Name="EndOfWorkflow" Value="C"/> </ExtendedAttributes> </WorkflowProcess> Notice the use of extended attributes to define the start and end activities of the process. That an extension is required for this is surprising. 7.2.3.2 Variables and assignmentsXPDL variables for a process include formal parameters and data fields , shown earlier. Expressions can be built from variables, as in the condition expression in line 334 of the travel agency example. Data types can be mapped to a particular XML schema. 7.2.3.3 Exception handling and compensationException transitions are supported. An exception transition fires when a particular type of exception occurs; the default exception transition is a catch-all that fires for any exception. XPDL has built-in support for timeout exceptions, but other types exceptions are engine-specific. XPDL has no explicit compensation support. 7.2.3.4 Split and joinThree constructs can help model splits and joins:
See Example 7-1 for examples of these techniques. 7.2.3.5 LoopsAn activity can transition to an upstream transition, provided the process conformance class in nonblocked. (A process can be configured not to allow loop-like cycles; the nonblocked setting enables cycles.) The effect is that of a GOTO. In the following code example, the sequence of activities A <Package> <ConformanceClass GraphConformance="NON_BLOCKED"/> . . . <WorkflowProcesses> <WorkflowProcess> <Activities> <Activity > . . . </Activity> <Activity > . . . </Activity> <Activity > . . . </Activity> </Activities> <Transitions> <Transition from="A" to="B"/> <Transition from="B" to="C"/> <Condition Type="CONDITION">okToProceed="yes"</Condition> </Transition> <Transition from="B" to="A"/> <Condition Type="OTHERWISE"/> </Transition> </Transitions> </WorkflowProcess> </WorkflowProcesses> </Package> XPDL does not support structured loops such as while or foreach. 7.2.3.6 Participant exchangeAn XPDL package can define applications, which can be defined as WSDL operations. Also, a participant type can be a system actor. The process can use these entities to communicate with external partners. 7.2.3.7 TransactionsThe specification does not provide information on transactions. 7.2.3.8 ExtensionsMost elements have extended attributes . For example, lines 350-359 in the travel agency example declare the start and end activities of the process. Also, in numerous places (e.g., lines 275-276), extensions are used to give activity screen positions for the graphical layout of the process. 7.2.4. XPDL and PatternsIn their web site http://www.workflowpatterns.com, members of the P4 rate the WfMC's process definition language, XPDL, on its support for the P4 patterns . The results, documented in http://is.tm.tue.nl/research/patterns/download/ce-xpdl.pdf,[*] imply that XPDL supports only 11 of the 20 P4 patterns. The P4 concludes that XPDL is relatively inexpressive, and moreover, its rules for AND and XOR splits and joins are ambiguous. The results are summarized in Table 7-1.
|
B 
EAN: 2147483647
Pages: 122