This section will cover a mapping to BPEL4WS that are derived by analyzing the BPMN objects and the relationships between these objects as described in the sections above.
A Business Process Diagram can be made up of a set of (semi-) independent components, which are shown as separate Pools. Thus, there is not a specific mapping to the diagram itself. Rather, there are separate mappings to each of the Pools that are in the diagram. That is, each Pool in the diagram, if it is a "white box" that contains process elements, will map to an individual BPEL4WS process. However, in the course of mapping the contents of the Process, there may be one or more derived processes necessary to handle complex behavior, such as looping. The attributes of "black box" Pools will also be used in determining specific BPEL4WS elements, such as partnerLink.
The following table displays a set of mappings for the attributes of a Business Process Diagram that can be mapped to BPEL4WS:
There can be one or more Business Processes within a Business Process Diagram, each within a separate Pool. The following table displays a set of mappings from attributes of a Process to BPEL4WS elements (the mappings for the objects contained within a Process, its contents, are mapped separately and these mappings can be found in the sections that follow):
If the Process is to be used to create a BPEL4WS document, then the attribute MUST be set to Private or Abstract. If the attribute is set to Private, then the abstractProcess attribute of the BPEL4WS process MUST be set to "no." If the attribute is set to Abstract, then the abstractProcess attribute of the BPEL4WS process MUST be set to "yes." |
|
These Elements do not map to any BPEL4WS elements or attributes. |
|
The Name attribute of the Process SHALL map to name attribute of the appropriate process. The extra spaces and non-alphanumeric characters MUST be stripped from the Name to fit with the XML specification of the name attribute. Note that there may be two or more elements with the same name after the BPMN name has been stripped. |
|
This is a list of all the graphical elements contained within the Process. Each of these elements will have their mapping, as defined in the sections below. |
|
The set of Properties of a Process, as a whole, will map to a BPEL4WS variable. The variable element will be structured as follows: <variable name="[Process.Name]_Data" messageType="[Process.Name]_ProcessDataMessage" /> The individual Properties will map to the parts of a WSDL message. The message element will be structured as follows: <message name="[Process.Name]_ProcessDataMessage" > <part name="[Property.Name]"type="xsd:[Property.Type]" />There will be as many parts to the message as there are Properties in the input group. |
|
This only applies to Properties of Type = "Set." The Name of the Property will map to the name of a correlationSet. The Name of each child Property for the Set will be added to the list of properties of the correlationSet. |
|
Ad Hoc Processes are not executable. Thus, this attribute MUST be set to False if the Process is to be mapped to BPEL4WS. |
|
This attribute only applies to Ad Hoc Processes. Thus, it will not be mapped to BPEL4WS. |
|
This will map to a BPEL4WS assign. See Assignment Mapping. for more details about the mappings associated with the assign element. |
|
A BPEL4WS sequence will be created and the assign will follow the instantiation of the process (through a receive or a pick). |
|
A BPEL4WS sequence will be created and the assign will follow |
|
This maps to the BPEL4WS process attribute suppressJoinFailure. |
|
This maps to the BPEL4WS process attribute enableInstanceCompensation. |
The following table displays a set of mappings for the attributes common to Flow Objects (Events, Activities, and Gateways):
These Elements do not map to any BPEL4WS elements or attributes. |
|
The Name attribute of the object SHALL map to name attribute of the appropriate derived BPEL4WS element (as per mappings described in the sections below). The extra spaces and non-alphanumeric characters MUST be stripped from the Name to fit with the XML specification of the name attribute. Note that there may be two or more elements with the same name after the BPMN name has been stripped. |
|
Each Assigments Expression will map to a BPEL4WS assign activity. See Assignment Mapping. for more details about the mappings associated with the assign element. |
The following table displays a set of mappings from the variations of a Start Event to BPEL4WS elements (these mappings extend the mappings common to objects--See Common Flow Object Mappings.):
The mapping to BPEL4WS is specific to the Trigger setting. These mappings are defined in the rows below. |
|
There is no BPEL4WS element that a Start Event will map to with a Trigger that is None. The object(s) that are the Target(s) of Sequence Flow that originate from the Start Event will determine the first BPEL4WS element of the Process. Note that a valid BPEL4WS process must begin with a receive or a pick activity that has a createInstance set to "yes." The receive or pick will likely be placed within a sequence or a flow. |
|
This will map to the receive element. The createInstance attribute of the receive element will be set to "yes." |
|
The Message attribute maps to the variable attribute of the receive activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The Implementation attribute MUST be a Web service or MUST be converted to a Web Service for mapping to BPEL4WS. The Web Service Attributes are mapped as follows: The Participant attribute is mapped to the partnerLink attribute of the BPEL4WS activity. The Interface attribute is mapped to the portType attribute of the BPEL4WS activity. The Operation attribute is mapped to the operation attribute of the BPEL4WS activity. |
|
This will map to the receive element. The createInstance attribute of the receive element will be set to "yes." The remaining attributes of the receive will be mapped as shown for the Message Start Event (see above). The functionality of the timing as defined in the Start Event must be implemented in a separate process that will start itself, then use a wait element for the defined time, and then use an invoke to send a message that will be received by the above receive element. A specific Message and Web service implementation must be provided so that the mappings to receive element can be completed. |
|
This will map to the receive element. The createInstance attribute of the receive element will be set to "yes." The remaining attributes of the receive will be mapped as the same way as for the Message Start Event (see above). Note: the Message is expected to arrive from the application that tracks and triggers Business Rules. |
|
This will map to the receive element. The createInstance attribute of the receive element will be set to "yes." The remaining attributes of the receive will be mapped as shown for the Message Start Event (see above). A specific Message and Web service implementation must be provided so that the mappings to receive element can be completed. |
|
This will map to a BPEL4WS pick will be required to process the messages with a separate onMessage for each defined Trigger. The createInstance attribute of the pick element will be set to "yes." This means that a single instance of the process will be instantiated when the first message received through the pick onMessage is triggered. The onMessage mappings are the same as that of a receive and as defined for the Message Start Event (see above). |
|
Each Assigments Expression will map to a BPEL4WS assign that will follow the receive. See Assignment Mapping. for more details about the mappings associated with the assign element. |
The following table displays a set of mappings from the variations of a End Event to BPEL4WS elements (these mappings extend the mappings common to objects--See Common Flow Object Mappings.):
The mapping to BPEL4WS is specific to the Result setting. These mappings are defined in the rows below. |
|
There is no BPEL4WS element that a End Event will map to with a Result that is None. However, it marks the end of a path within the Process and will be used to define the boundaries of complex BPEL4WS elements. The object(s) that are the Source(s) of Sequence Flow that Target the End Event will determine the final BPEL4WS elements of the Process. |
|
This will map to a BPEL4WS reply or an invoke. The appropriate BPEL4WS activity will be determined by the implementation defined for the Event. That is, the portType and operation of the Message will be used to check to see if an upstream Message Event have the same portType and operation. If these two attributes are matched, then the Event will map to a reply, if not, the Event will map to an invoke. |
|
The Message attribute maps to the variable attribute of the reply or the outputVariable of the invoke. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The Implementation attribute MUST be a Web service or MUST be converted to a Web Service for mapping to BPEL4WS. The Web Service Attributes are mapped as follows: The Participant attribute is mapped to the partnerLink attribute of the BPEL4WS activity. The Interface attribute is mapped to the portType attribute of the BPEL4WS activity. The Operation attribute is mapped to the operation attribute of the BPEL4WS activity. |
|
This will map to a throw element. The ErrorCode attribute of the Event will map to the faultName attribute of the throw. |
|
The mapping of the Cancel Intermediate Event to BPEL4WS is an open issue. See Open Issues. for other Open Issues. |
|
This will map to a compensate element. The Name of the activity referenced by the Compensation Event will map to the scope attribute of the compensate element. |
|
The LinkId attribute maps to the outputVariable of the invoke. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The Implementation attribute MUST be a Web service or MUST be converted to a Web Service for mapping to BPEL4WS. The Web Service Attributes are mapped as follows: The Participant attribute of the Pool where the Process is contained is mapped to the partnerLink attribute of the BPEL4WS activity. The Name attribute of the Process is mapped to the portType attribute of the BPEL4WS activity. The LinkId attribute is mapped to the operation attribute of the BPEL4WS activity. |
|
This will map to a this will map to a combination of invoke, throw, fault, and compensation elements as they are defined above. |
|
This will map to a BPEL4WS assign that will precede any other mappings required by the Event. See Assignment Mapping. for more details about the mappings associated with the assign element. |
The following table displays a set of mappings from the variations of a Intermediate Event to BPEL4WS elements (these mappings extend the mappings common to objects--See Common Flow Object Mappings.):
The mapping to BPEL4WS is specific to the Trigger setting. These mappings are defined in the sections below. |
|
this will map to a BPEL4WS assign. See Assignment Mapping. for more details about the mappings associated with the assign element. |
The mappings for None Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mappings for Message Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
If the Participant defined in the To attribute of the Message is the same Participant as that of the Process that contains the Event, then this will map to a receive. The createInstance attribute of the receive element will be set to "no." If the Participant defined in the From attribute of the Message is the same Participant as that of the Process that contains the Event, then this will map to an (one-way) invoke. |
|
The Message attribute maps to the variable attribute of the reply or the outputVariable of the invoke. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The Implementation attribute MUST be a Web service or MUST be converted to a Web Service for mapping to BPEL4WS. The Web Service Attributes are mapped as follows: The Participant attribute is mapped to the partnerLink attribute of the BPEL4WS activity. The Interface attribute is mapped to the portType attribute of the BPEL4WS activity. The Operation attribute is mapped to the operation attribute of the BPEL4WS activity. |
|
Without an incoming Sequence Flow (but not attached to an Activity Boundary) |
The Participant defined in the To attribute of the Message MUST be the same Participant as that of the Process that contains the Event. The process will be given a scope (if it doesn't already have one). A eventHandlers element will be defined for the scope. An onMessage element will be added to the eventHandlers element. |
The Message attribute maps to the variable attribute of the onMessage. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The Implementation attribute MUST be a Web service or MUST be converted to a Web Service for mapping to BPEL4WS. The Web Service Attributes are mapped as follows: The Participant attribute is mapped to the partnerLink attribute of the onMessage. The Interface attribute is mapped to the portType attribute of the onMessage. The Operation attribute is mapped to the operation attribute of the onMessage. |
|
The mappings of the activity (to which the Event is attached) will be placed within a scope. A faultHandlers element will be defined for the scope. A catch element will be added to the faultHandlers element with "<message name>_Exit" as the faultName attribute. An eventHandlers element will be defined for the scope. The Event will map to an onMessage element within the eventHandlers. The mapping to the onMessage attributes is the same as described for the receive above. The activity for the onMessage will be a throw with "<message name>_Exit" as the faultName attribute. |
|
This will map to an onMessage within a pick.The mapping to the onMessage attributes is the same as described for the receive above. |
The mappings for Timer Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mappings for Error Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mappings for Cancel Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mapping of the Cancel Intermediate Event to BPEL4WS is an open issue. See Open Issues. for other Open Issues. |
The mappings for Rule Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mappings for Compensation Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mappings for Link Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
The mappings for Multiple Intermediate Events are described in the following table (these mappings extend the mappings common to Intermediate Events--See Intermediate Event Mappings.):
This will map to a this will map to a combination of the mappings as they are defined in the Intermediate Event sections above. |
The following table displays a set of mappings from the variations of activities to BPEL4WS elements (these mappings extend the mappings common to objects -- See Common Flow Object Mappings. -- Note that See Basic Activity Loop Mappings to BPEL4WS. contain additional mappings that must be included within this set if extended by any other mapping table):
The set of Properties of an activity, as a whole, will map to a BPEL4WS variable. The variable element will be structured as follows: <variable name="[activity.Name]_ActivityData" messageType="[activity.Name]_ActivityDataMessage" /> The individual Properties will map to the parts of a WSDL message. The message element will be structured as follows: <message name="[activity.Name]_ActivityDataMessage" > <part name="[Property.Name]"type="xsd:[Property.Type]" />There will be as many parts to the message as there are Properties in the input group. |
|
This will map to a BPEL4WS assign. See Assignment Mapping. for more details about the mappings associated with the assign element. |
|
A BPEL4WS sequence will be created and the assign will precede |
|
A BPEL4WS sequence will be created and the assign will follow |
The mapping to BPEL4WS for looping activities is complex and is made up of a number of activities that will surround the original mapping of the activity itself (which may be complex). The description of this mapping is divided into three sections to describe the basic setup of the loop (common to all loops), then the details of Standard looping, then the details of Multi-Instance looping.
The basic set up mappings, which are common to both Standard and Multi-Instance looping activities, are described in the following table (these mappings extend the mappings common to objects--See Common Activity Mappings.):
The loop mappings for Standard loops are described in the following table (these mappings extend the mappings of the Basic Loop Setup--refer to the previous section):
For a Standard Looping activity, the mapping of the base BPMN activity will be placed within a BPEL4WS sequence that is within a while, and this will follow the assign described in the Basic Loop Setup (see See BPMN Depiction of BPEL4WS Pattern for a Standard loop, TestTime = Before. and See BPEL4WS Sample for a Standard Loop.). See Sub-Process Mappings. or the See Task Mappings. for details about how the base activity will be mapped to BPEL4WS. |
|
The LoopCondition, which MUST be a boolean expression, will be used as the condition attribute of the while element.The while condition be structured as follows: |
|
An After TestTime will map to the BPEL4WS while activity. However, to insure that the Task is performed at least once (i.e., the functionality of an until loop), a copy of the mapping for BPMN activity will be performed first in a sequence, followed by the while (which will contain the original copy of the mapping for the BPMN activity). |
|
Any value in Maximum will be appended to the LoopCondition. For example with a LoopCondition of "x < 0" and Maximum of 5 (loops), the final expression would be "(x < 0) and ([ActivityName].LoopCounter <= 5)." |
See BPEL4WS Sample for a Standard Loop.See . displays sample BPEL4WS code that reflects the mapping of a Standard loop.
The loop mappings for Multi-Instance loops are described in the following table (these mappings extend the mappings of the Basic Loop Settings--See Basic Loop Setup.):
For a Multi-Instance Looping activity, the mapping of the BPMN activity will be placed within a BPEL4WS sequence that is within a while, and this will follow the assign described in the Basic Loop Setup (see See BPMN Depiction of BPEL4WS Pattern for a Standard loop, TestTime = Before. and See BPEL4WS Sample for a Standard Loop.). See Sub-Process Mappings. or the See Task Mappings. for details about how the base activity will be mapped to BPEL4WS. |
|
This applies to both Sequential and Parallel MI_Ordering (see below). The MI_Condition, which MUST be a numeric expression, will map to an assign activity. This will be the first activity of the generated sequence activity (as described in the row above). First, a BPEL4WS variable must be created with a derived name and will have a structure as follows: <variable name="[activity.Name]_forEachCount" messageType="forEachCounterMessage" /> Second, an assign activity will be used to generate the number of instances that will be required. The assign will be structured as follows: <assign name="[activity.Name]_determine_instances"> <copy><from expression="[MI_Condition Expression]"/> <to variable="[activity.Name]_forEachCount" </copy> |
|
A WSDL message element will have to be created to support the variable. This message can be used for multiple variables. The message will be structured as follows: <message name="forEachCounterMessage" > <part name="forEachCount" part="xsd:integer" /> |
|
The condition attribute of the while will be a derived expression that utilizes the loopCounter variable and compares it to the derived forEachCount (described in the row above). The while condition be structured as follows: bpws:getVariableData([activity.Name]_loopCounter, |
The loop mappings for Sequential Multi-Instance loops are described in the following table (these mappings extend the mappings of the Multi-Instance Setup--refer to the section above):
This type of looping utilizes both the Basic Loop Setup mappings and the above Multi-Instance mappings. No further mappings are necessary. See See BPMN Depiction of BPEL4WS Pattern for a Sequential Multi-Instance loop. and See BPEL4WS Sample for a Multi-Instance Loop with Sequential Ordering. for the complete mappings. |
See BPEL4WS Sample for a Multi-Instance Loop with Sequential Ordering.See . displays some sample BPEL4WS code that reflects the mapping of a Standard loop.
The loop mappings for Sequential Multi-Instance loops are described in the following table (these mappings extend the mappings of the Multi-Instance Setup--refer to the section above):
A BPEL4WS while activity will also be used for Parallel ordering. However, since the Task is to be performed in parallel, the mapping to the Tasks cannot be contained within the while. To get the parallel behavior, each copy of the multi-instance Task will be placed into a separate, derived BPEL4WS process1. A one-way invoke will be used to "spawn" each process and, thus, each instance of the Task. Since the invoke is only one-way, and doesn't wait for a response from the process, the invoke will complete quickly and the while will cycle through all of its iterations quick enough that the instantiations of the Task mappings will be effectively, if not literally, in parallel. The setting for the MI_FlowCondition attribute will determine what BPEL4WS elements will follow the while activity. These mappings will be described in the next four sections. |
|
The while condition will be the same as that of the Sequential ordering (see previous section). |
|
In the while activity, a one-way invoke activity will be created and used to "spawn" each of the derived processes. The name attribute for each derived invoke will be in the following format: <invoke name="Spawn_Process_For_[activity.Name]" ... > This invoke will replace the mappings of the original activity, which was in the while for Standard loops and Sequential Multi-Instance Loops. |
|
The derived process will start with a receive that accepts the message that is sent by the one-way invoke that is within the while loop of the original process. The name of the process will be "Spawned_Process_For_[activity.Name]." The original Task will be mapped and those BPEL4WS elements will follow the initial receive. After all the mapped elements have been completed, then a one-way invoke will be used to send a message back to the original process has a notification that the spawned process is completed. This will be the last element of the spawned process (see See Structure of Process to be Spawned for Parallel Multi-instance. and See BPEL4WS Sample of a derived process for Parallel Multi-Instance loops.). The name attribute for the derived invoke will be in the following format: |
|
Since the Parallel Multi-Instance Task mappings are going to be performed within the a different process instance, the variables of the original process will need to be passed to the spawned process through the inputVariable of the one-way invoke that spawns the process. Likewise, any variables that are updated in the spawned process will need to be passed back to the original process through the inputVariable of the one-way invoke that indicates that the spawned process has completed. Note: Once the individual derived processes are instantiated, they will be blind to any changes in process variables. From the BPMN point of view, all the multi-instance activities are within the same context as the original Process and, thus, should be able to utilize any dynamic changes to Process Properties (BPEL4WS variables) as they occur (this is especially true for multi-instance Sub-Processes). It is up to the BPEL4WS execution environment to provide a "virtual context" for all the derived processes to "share" the process variables. |
|
As mentioned above, the spawned processes will send a message back to the original process after it has completed performing the behavior of the original activity. A BPEL4WS receive activity will be used to receive the messages back from all the spawned processes. The settings of the MI_FlowCondition will determine The name attribute for each derived receive will be structured as follows: <receive name="[activity.Name]_Completed" ... > The setting of the MI_FlowCondition attribute will determine how many receive activities will be required. Once the appropriate number of messages have been received back from the spawned processes, the original process will continue. |
See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = One.See . displays some sample BPEL4WS code that reflects the mapping of a Multi-Instance loop that has Parallel ordering and must synchronize all the looped activities.
<process name="Spawned_Process_For_[activity.Name]" ... > <receive name="Spawn_Process_For_[activity.Name]" ... > <!--The mappings of the original activity are placed here.--> |
The loop mappings for Parallel Multi-Instance loops that have a MI_FlowCondition of All are described in the following table (these mappings extend the mappings of the Parallel Multi-Instance Setup--refer to the section above):
This setting utilizes the mechanisms described above for the Parallel ordering. The "All" setting requires that all of the spawned processes must be completed before the original process can continue (see See BPEL4WS Pattern of Parallel Multi-instance, MI_FlowCondition = All. and See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = All.). |
|
The synchronization from the spawned processes is managed through the messages sent by those processes when they have completed the behavior defined by the original activity. These messages will be received by the original process and when the messages from all the spawned processes are received, then the original process can continue. To ensure that all the messages are received, a second while activity will used. This while will contain a receive activity (for the completion messages) and an assign activity to increment the loop counter. The while condition attribute will be the same as the condition for the while that generated all the spawned processes, so that the same number of messages will be received as there were spawned processes. |
|
Prior to the second while activity, another assign will be required to reset the loop counter. The contents of the assign activity will be the same as the assign that originally initialized the loopCounter. The name attribute for the derived assign will be in the following format: |
The loop mappings for Parallel Multi-Instance loops that have a MI_FlowCondition of One are described in the following table (these mappings extend the mappings of the Parallel Multi-Instance Setup--refer to the section above):
This setting utilizes the mechanisms described above for the Parallel ordering. The "One" setting requires that only one of the spawned processes must be completed before the original process can continue (see See BPEL4WS Pattern of Parallel Multi-instance, MI_FlowCondition = One. and See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = One.). |
|
Only one message is required from any one of the spawned processes before the original process can continue. Thus, there will be a single receive activity following the while activity. The receive will be the last element of the sequence that was started for the mapping of the Multi-Instance activity. The other spawned processes will continue there activities in parallel, but their completion will have no direct impact on the flow of the main process (their messages won't be received). Note: As mentioned above, it is up to the BPEL4WS execution environment to provide a "virtual context" for all the derived processes to "share" the process variables that may be updated by the spawned processes with the original process, even if there are no specific BPEL4WS activities to manage this information. |
See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = One.See . displays some sample BPEL4WS code that reflects the mapping of a Multi-Instance loop that has Parallel ordering and must wait for only one of the looped activities.
The loop mappings for Parallel Multi-Instance loops that have a MI_FlowCondition of Complex are described in the following table (these mappings extend the mappings of the Parallel Multi-Instance Setup--refer to the section above):
The mapping for this setting is almost the same as the MI_FlowCondition of All mapping (as described above) and seen in See BPEL4WS Pattern of Parallel Multi-instance, MI_FlowCondition = All. and See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = All.). The difference is that the number of return messages required before the process flow will continue must be determined and the messages have been received. |
|
The second while in the sequence will be used to receive the appropriate number of completion messages. The ComplexMI_FlowCondition, which MUST be a boolean expression, will determine this number. The while condition be structured as follows: |
The loop mappings for Parallel Multi-Instance loops that have a MI_FlowCondition of None are described in the following table (these mappings extend the mappings of the Parallel Multi-Instance Setup--refer to the section above):
This means that there is not synchronization or control of the Tokens that are generated through the multi-instance activity. This means that each Token will continue on independently and each Token will create a separate instantiation of each activity they encounter. Basically, it means there is a separate copy of the whole process, for each copy of the Multi-Instance activity, after that point. Each copy of the remainder of the process will continue independently. To create this behavior, the remainder of the process will moved into a new, derived process. |
|
This process will be spawned through a one-way invoke that will be placed within the while activity, after the mappings of the original BPMN activity (see See . and See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = None.). The name attribute for the derived invoke will be in the following format: |
See BPEL4WS Sample of a Parallel Multi-Instance Loop, MI_FlowCondition = None.See . displays some sample BPEL4WS code that reflects the mapping of a Multi-Instance loop that has Parallel ordering and must wait for none of the looped activities.
The following table displays a set of mappings from the variations of a Sub-Process to BPEL4WS elements (This extends the mappings that are defined for all activities--See Common Activity Mappings.):
The SubProcessType attribute will determine the exact mapping of a Sub-Process. See the next two sub-sections for these mappings. |
|
The mapping of a Sub-Process set to a Transaction is an Open Issue (See Open Issues. for other Open Issues). Thus, there is no mapping defined when the IsATransaction is set to True, or the sub-attributes TransactionId, TransactionProtocol, and TransactionMethod. |
The following table displays a set of mappings from the variations of an Embedded Sub-Process to BPEL4WS elements (This extends the mappings that are defined for all activities--See Sub-Process Mappings.):
The following table displays a set of mappings from the variations of an Independent Sub-Process to BPEL4WS elements (This extends the mappings that are defined for all activities--See Sub-Process Mappings.):
BPEL4WS does not have a sub-process element. Thus, Independent Sub-Processes MUST map to a BPEL4WS process. That is, the contents of the Sub-Process, whether it is expanded or collapsed, will be contained within a separate process. The DiagramRef and ProcessRef attributes will identify the process that will be used for the mapping to the BPEL4WS process. The attributes of the other BPEL4WS process element will be filled from the mapping of the referenced Process. See Business Process Mappings. for the details of this mapping. The Sub-Process object itself maps to an invoke activity that "calls" the process. |
|
This attribute is actually a mapping of Process Properties to the Process Properties of the Process being referenced by the Sub-Process Object. The OutputPropertyMaps attribute maps to the inputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
This attribute is actually a mapping of Process Properties to the Process Properties of the Process being referenced by the Sub-Process Object. The InputPropertyMaps attribute maps to the outputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
The following table displays a set of mappings from the variations of a Reference Sub-Process to BPEL4WS elements:
The following table displays a set of mappings from the variations of a Task to BPEL4WS elements (This extends the mappings that are defined for all activities--See Common Activity Mappings.):
The following table displays a set of mappings from the variations of a Service Task to BPEL4WS elements:
The InMessage attribute maps to the inputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The OutMessage attribute maps to the outputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
This will map as defined in See Task Mappings to BPEL4WS.. |
The following table displays a set of mappings from the variations of a Receive Task to BPEL4WS elements (This extends the mappings that are defined for all Tasks--See Task Mappings.):
The Message attribute maps to the variable attribute of the receive activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
If the Instantiate attribute of the Task is set to False, then the createInstance attribute of the receive will not be included or it will be set to "no." If the Instantiate attribute of the Task is set to True, then the createInstance attribute of the receive will be set to "yes." |
|
This will map as defined in See Task Mappings to BPEL4WS.. |
The following table displays a set of mappings from the variations of a Send Task to BPEL4WS elements:
This type of Task maps to a reply or an invoke activity. The appropriate BPEL4WS activity will be determined by the implementation defined for the Task. That is, the portType and operation of the Task will be used to check to see if an upstream Receive Task have the same portType and operation. If these two attributes are matched, then the Send Task will map to a reply, if not, the Send Task will map to an invoke. |
|
The Message attribute maps to the variable attribute of the reply activity or it maps to the inputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
This will map as defined in See Task Mappings to BPEL4WS.. |
The following table displays a set of mappings from the variations of a User Task to BPEL4WS elements:
The Performers is information needed by the implementation. Thus, it will be included in the InMessage being sent to the Web service, through the inputVariable attribute of the invoke activity. |
|
The InMessage attribute maps to the inputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
The OutMessage attribute maps to the outputVariable attribute of the invoke activity. See Messages. for more information about how a BPMN Message maps to BPEL4WS and WSDL. |
|
This will map as defined in See Task Mappings to BPEL4WS.. |
The following table displays a set of mappings from the variations of a Script Task to BPEL4WS elements:
The Manual Task does not map to BPEL4WS. Thus, this type of Task should not be used in a Process that is intended to generate BPEL4WS code.
The following table displays a set of mappings from the variations of a Reference Task to BPEL4WS elements:
The following table displays a set of mappings are common for Gateways to BPEL4WS elements (these mappings extend the mappings common to objects -- See Common Flow Object Mappings.):
A Gateway will map to a variety of BPEL4WS elements (e.g., switch, pick, flow) and patterns of elements. |
|
A Gateway, as with activities, is a location where Sequence Flow can converge. The convergence of Sequence Flow potentially marks the end of a BPEL4WS structured element, if the correct number of flow converge. See Determining the Extent of a BPEL4WS Structured Element. for more details on converging of Sequence Flow and their mapping to BPEL4WS. |
|
The mapping will begin at the location of the Gateway. The BPMN elements that follow the Gateway, until all the outgoing paths have converged, will be contained within the extent of the mapping (e.g., they will be placed with in a sequence within a switch case). The end of the mapping will be determined by the convergence of the paths, through a variety of mechanisms (See Determining the Extent of a BPEL4WS Structured Element.). |
|
This will map to a BPEL4WS assign. See Assignment Mapping. for more details about the mappings associated with the assign element. |
The following table displays a set of mappings from the variations of a Data-Based Exclusive Gateway to BPEL4WS elements (these mappings extend the mappings common to objects -- See Common Gateway Mappings.):
The following table displays a set of mappings from the variations of a Event-Based Exclusive Gateway to BPEL4WS elements (these mappings extend the mappings common to objects -- See Common Gateway Mappings.):
This Gateway will map to a BPEL4WS pick. The elements of the pick will be determined by the targets of the outgoing Sequence Flow. The specific mappings are described in the rows below. |
|
If the Instantiate attribute of the Gateway is set to False, then the createInstance attribute of the pick MUST NOT be included OR it MUST be set to "no." If the Instantiate attribute of the Gateway is set to True, then the createInstance attribute of the pick MUST be set to "yes." |
|
The Receive Task will map to an onMessage element within the pick. The attributes of the Receive Task will map to the appropriate elements of the onMessage, such as operation and portType. See Receive Task. for the mapping of the Receive Task. Note that the name of the Task does not have a corresponding attribute within the onMessage element. |
|
A Message Intermediate Event will map to an onMessage element within the pick. The attributes of the Message Intermediate Event will map to the appropriate elements of the onMessage, such as operation and portType. See Intermediate Event Mappings. for the mapping of the Message Intermediate Event. |
|
A Timer Intermediate Event, which is the Target of a Sequence Flow associated with the Gate, will map to an onAlarm element within the pick. The Timedate attribute of the Event will map to the until element of the onAlarm element. The Timecycle attribute of the Event will map to the for element of the onAlarm element. |
|
A Rule Intermediate Event, in this situation, will be considered as the same as receiving a message from a process. Thus, this will map to an onMessage element within the pick. The attributes of the Message Intermediate Event will map to the appropriate elements of the onMessage, such as operation and portType. See Intermediate Event Mappings. for the mapping of the Message Intermediate Event. |
|
A Rule Intermediate Event, in this situation, will be considered as the same as receiving a message from a system that tracks and generates Rule events. Thus, this will map to an onMessage element within the pick. The attributes of the Message Intermediate Event will map to the appropriate elements of the onMessage, such as operation and portType. See Intermediate Event Mappings. for the mapping of the Message Intermediate Event. |
|
If there is more than one element that follows the first target of a Gate, and this includes Assignments for the Gate, then these elements will be placed inside a sequence activity after these elements have been mapped. |
The following table displays a set of mappings from the variations of a Inclusive Gateway to BPEL4WS elements (these mappings extend the mappings common to objects -- See Common Gateway Mappings.):
The Gateway will map to a set of BPEL4WS switches within a BPEL4WS flow. An additional switch will be required if the DefaultGate is used (see below) |
|
Each Gate will map to a switch. Each switch will binary in nature. That is, each switch will have exactly one case and one otherwise. |
|
If there is more than one element that follows the Gate, and this includes Assignments for the Gate, then these elements will be placed inside a sequence activity after these elements have been mapped. If a DefaultGate is used, then an assign activity will follow all the other mappings (see below for details). |
|
The otherwise element for each switch will contain an empty activity. However, if the DefaultGate is used, then |
|
The DefaultGate will map to a switch. However, by using the DefaultGate, the mapping to BPEL4WS is more complicated (see See BPEL4WS Pattern of Inclusive Decision with two (2) Gates and a DefaultGate. and See BPEL4WS Sample for the Pattern for an Inclusive Decision with a DefaultGate.). This is the path that is taken if none of the other paths are taken. Thus, the decision about whether the Default Gate should be taken will occur after all the other Gate decisions have been determined. This means that the switch for the DefaultGate will follow the flow activity generated for all the Gates of the Gateway. Also, a sequence activity must encompass the flow and the switch. |
|
A variable must be used so that the switch for the DefaultGate will know whether or not the Default BPMN path should be taken. To do this, a BPEL4WS variable must be created with a derived name and will have a structure as follows: |
|
A WSDL message element will have to be created to support this variable. This message can be used for multiple variables. The message will be structured as follows: <message name="noDefaultRequired" > |
|
An assign activity will be created to initialize the variable before the start of the loop. This assign precede the flow activity that contains all the switches derived from the Gates. This will be the first activity within the sequence activity. The assign will be structured as follows: <assign name="[Gateway.Name]_initialize_noDefault"> <copy><to variable="[Gateway.Name]_noDefaultRequired" </copy> |
|
The condition for the switch case will used the noDefaultRequired variable and will structured as follows: <case condition="bpws:getVariableProperty( [Gateway.Name]_noDefaultRequired,noDefault)=true"> <!--The mappings of the original activity are placed here.--> |
|
If there is more than one element that follows the DefaultGate, and this includes Assignments for the Gate, then these elements will be placed inside a sequence activity after these elements have been mapped. An assign activity will be placed in the sequence after all the other mappings (see next row). |
|
If any of the switches within the flow passes the condition of the switch case, then the noDefaultRequired must be set to True. This will ensure that the DefaultGate switch will bypass the mapped activities for the BPMN Default Gate. An assign activity will be created to set the variable to True. This will be the last activity within the sequence activity within the switch. The assign will be structured as follows: <assign name="[Gateway.Name]_set_noDefault"> <copy><to variable="[Gateway.Name]_noDefaultRequired" </copy> |
See BPEL4WS Sample for the Pattern for an Inclusive Decision with a DefaultGate.See . displays some sample BPEL4WS code that reflects the mapping of a Multi-Instance loop that has Parallel ordering and must synchronize all the looped activities.
The behavior and usage of Complex Gateways have not been well enough established for a mapping to BPEL4WS to be defined.
The following table displays a set of mappings from the variations of a Parallel Gateway to BPEL4WS elements (these mappings extend the mappings common to objects -- See Common Gateway Mappings.):
Pools do not have any specific Mapping to Execution Languages. However, a Pool is associated with a mapping to a specific lower level language. For example, one Pool may encompass a BPEL4WS document while another Pool might encompass B2B Collaboration process.
Lanes do not have any specific Mapping to Execution Languages. They are designed to help organize and communicate how activities are grouped in a business process.
As a general rule, Artifacts do not map to BPEL4WS elements. They provide detailed information about how data will interact with the Flow Objects and Flow of Processes.
However, Text Annotations can map to the documentation element of BPM execution languages. If the Annotation is associated with a Flow Object and that object has a straight-forward mapping to a BPM execution language element, then the text of the Annotation will be placed in the documentation element of that object. If there is no straight-forward mapping to a BPM execution language element, then the text of the Annotation will be appended to the documentation element of the process.
For any new Artifact that is added to a BPD through a modeling tool, it will have to be determined whether or not that Artifact maps to any BPEL4WS element.
A Sequence Flow may not have a specific mapping to a BPEL4WS in most situations. However, when there is a section of the Diagram that contains parallel activities, then Sequence Flow may map to the link element. Details of this mapping are TBD. In general, the set of Sequence Flow within a Pool will determine how BPEL4WS elements are derived and the boundaries of those elements.
The following table displays a set of mappings from Sequence Flow to BPEL4WS elements:
This MAY map to a BPEL4WS link element. The location of the Sequence Flow within the Process will determine how or if it is mapped to a link. Even if the Sequence Flow is not mapped to a link, attributes, such as Condition, will be mapped to BPEL4WS elements, as described below. |
|
These Elements do not map to any BPEL4WS elements or attributes. |
|
If the Sequence is not being mapped to a link: This attribute does not map to any BPEL4WS elements or attributes. If the Sequence is being mapped to a link: The Name attribute of the Process SHALL map to name attribute of the link. The extra spaces and non-alphanumeric characters MUST be stripped from the Name to fit with the XML specification of the name attribute. Note that there may be two or more elements with the same name after the BPMN name has been stripped. |
|
If the Sequence is not being mapped to a link: This attribute does not map to any BPEL4WS elements or attributes. |
|
The mapping of the source activity will now include a source element. The Name of the Sequence Flow will map to linkName attribute of the source element.The extra spaces and non-alphanumeric characters MUST be stripped from the Name to fit with the XML specification of the name attribute. Note that there may be two or more elements with the same name after the BPMN name has been stripped. For an exception to the location of the source element, see the description of the mapping for a ConditionExpression when the Source object is an Activity below. |
|
This mapping is the same as if the source object is an activity (see above). |
|
This Sequence Flow will be essentially combined with one of the Gateway's incoming Sequence Flow. (There will be a separate link for each of the incoming Sequence Flow). The Source of the second Sequence will be used at the Source for the original Sequence Flow. Then, this mapping is the same as if the Source object is an activity (see above). |
|
If the Sequence is not being mapped to a link: This attribute does not map to any BPEL4WS elements or attributes. |
|
The mapping of the target activity will now include a target element. The Name of the Sequence Flow will map to linkName attribute of the target element.The extra spaces and non-alphanumeric characters MUST be stripped from the Name to fit with the XML specification of the name attribute. Note that there may be two or more elements with the same name after the BPMN name has been stripped. |
|
This mapping is the same as if the target object is an activity (see above). |
|
This Sequence Flow will be essentially combined with one of the Gateway's outgoing Sequence Flow. (There will be a separate link for each of the outgoing Sequence Flow). The Target of the second Sequence will be used at the Target for the original Sequence Flow. Then, this mapping is the same as if the target object is an activity (see above). |
|
If the Sequence is not being mapped to a link: This attribute does not map to any BPEL4WS elements or attributes. If the Sequence is being mapped to a link: This means that there is no condition placed on the transition between elements (through the link). Thus, there is nothing to be mapped to BPEL4WS. |
|
The mapping of the Sequence Flow in this situation is described See Exclusive., See Inclusive., See Complex.. |
|
Since a Sequence Flow MUST NOT have a Condition if the Source is an activity, unless there are multiple outgoing Sequence Flow, a BPEL4WS flow will be required and the Sequence Flow will map to a link element. An empty activity will be placed in the flow and will contain all the source elements. The ConditionExpression will then map to the transitionCondition attribute of the source element that is contained in the appropriate BPEL4WS activity (see a description of locating the source above). |
|
The mapping of the Sequence Flow in this situation is described See Exclusive., See Inclusive., See Complex.. |
|
The mapping of the Quantity attribute, if its value is greater than one (1), BPEL4WS is an open issue. See Open Issues. for other Open Issues. |
The ordering of the list in the sequence provides the direction of flow (see See Example: Sequence Flow that are not used for BPEL4WS links.).
However, it is only the Sequence Flow that are completely contained within the boundaries of the flow will be mapped to a link (see See Example: A Sequence Flow that is used for a BPEL4WS link.). It should be noted that if another structured activity (e.g., a switch) is contained within the flow, then the Sequence Flow that would be appropriate for the contents of the structured activity, would not be mapped to a link.
A Message Flow does not have a specific mapping to a BPEL4WS element. It represents a message that is sent through a WSDL operation that is referenced in a BPEL4WS receive, reply, or invoke.
An Association does not have a specific mapping to an execution language element. These objects and the Artifacts they connect to provide additional information for the reader of the BPMN Diagram, but do not directly affect the execution of the Process.
BPMN Exception Flow is all the activities, connected by Sequence Flow, which flow from an Intermediate Event attached to the boundary of an activity, until the flow merges back into the Normal Flow (sometimes at the point of an End Event).
BPEL4WS handles exceptions in a much more structured and programmatic manner. If triggered through a fault, the activities in an faultHandlers will be performed and completed, and then the process will continue from the point where the interrupted activity would have completed normally. Thus, the faultHandlers element is a completely contained structured element.
Since BPMN handles Exception Flow with much more flexibility, so that the modeler can have the Exception Flow go wherever it is appropriate, there are different challenges to the BPEL4WS mapping, depending on the configuration of the BPMN model.
The following table displays the mapping Exception Flow to BPEL4WS:
Additional BPEL4WS mapping patterns for Exception Flow will be described in the next three (3) sections.
In this situation, the Exception Flow may contain one or more activities, but will merge back into the Normal Flow at the same object that follows the activity that is the source of the Exception Flow (see See Exception Flow Merging back into Normal Flow Immediately after Interrupted Activity.). This situation maps closely to the BPEL4WS mechanism for exception handling. Thus, no special mapping mechanisms are required.
In this situation, the activities in the Exception Flow substitute for some of the Normal Flow activities and, thus, the Exception Flow will skip these activities and merge into the Normal Flow further downstream (see See Exception Flow Merging back into the Normal Flow Further Downstream.). Alternatively, the exception may create a situation where the Process must end prematurely, which means that the Exception Flow will merge with the Normal Flow at an End Event (see See Exception Flow Merging back into the Normal Flow at the End Event.). In either situation, special BPEL4WS patterns will have to appended to the basic Exception Flow mappings.
The following table displays the mapping Exception Flow to BPEL4WS (these mappings extend the mappings common to Exception Flow -- see above):
In this situation, the Exception Flow will loop back into the Normal Flow prior to the completion of the activity that is the source of the Exception Flow (see See Example of Exception Flow Looping Back into the Normal Flow Upstream.). This is a particularly challenging mapping and cannot be done entirely within the confines of the original BPEL4WS process. Another process will need to be derived and then "spawned" until the original activity can be completed normally.
This part of the Process will be modified at the BPEL4WS level so that the loop can be performed (through calling another process). If the flow moves to the faultHandlers activity, this means that the original activity will need to be performed again. Thus, the original activity will be duplicated in another process and the faultHandlers will contain a one-way invoke to "spawn" this other process (see See Example of Modification at BPEL4WS level to Handle the Loop.). In addition, the original process will wait with a receive activity for a message from the derived process that the original activity has completed normally.
The derived process will be structure much like the corresponding section of the original process (see See Example of a Derived Process to Handle the Looping.). The mappings of the original activities, from the point of the BPMN Process where the Exception Flow loops into the Normal Flow to the point of the source of the Exception Flow, will be in the derived process. The same faultHandlers will be attached to the scope around the original activity. The faultHandlers will also contain a one-way invoke to "spawn" itself if the fault occurs again.
When the original activity finally completes normally, one-way invoke will be used to send a message back to the original process so that normal activities can continue.
The following table displays a set of mappings from a Compensation Association to BPEL4WS elements:
A Compensation Intermediate Event attached to an activity boundary |
The mapping of the Compensation Event is described See Compensation Intermediate Events.. The mapping of the activity Associated with the Intermediate Event will follow the mapping rules defined See Task Mappings. or See Sub-Process Mappings. will be placed within the compensationHandler element. |
The following table displays a set of mappings from the variations of an Assignment expression to BPEL4WS elements:
This section describes the mapping to BPEL4WS of a non-graphical elements that are part of BPMN. Messages, which are linked with Message Flow, do have impact on how many other BPMN elements are mapped to BPEL4WS.
The following are the mappings of a Message. These mappings are used to create a BPEL4WSE4WS XML file, plus a supporting WSDL supporting file. These mappings are used for a Start Event, End Event, Intermediate Event, and Task:
The structure and vocabulary of BPMN differs from BPEL4WS. BPMN allows flexible, and free-form methods of connecting activities through Sequence Flow. Furthermore, BPMN is cyclical in that it allows Sequence Flow to connect to upstream objects so that a modeler can easily visualize looping situations. BPEL4WS has a much more structured form of creating a process flow. The flow activity in BPEL4WS does allow some flexibility with its link elements, but is acyclical. Thus, there is not going to be a one-to-one mapping of the BPMN elements to the BPEL4WS elements, without restricting the connection capability of BPMN.
This is particularly true of the BPEL4WS. In BPEL4WS, structure elements, such as switch, pick, and while, have a clear beginning and end. BPMN does not provide specific markers for the start and end of these elements. The exact configuration of the Sequence Flow connections will determine how the Process will be mapped to the BPEL4WS elements.
To determine the appropriate merging and joining points that are needed to construct the structured elements, the configuration of the Process needs to be analyzed. The mechanism we are proposing is called Token Analysis. This involves the creation of a conceptual Token that will "traverse" all the Sequence Flow of the Process. The Token will have a hierarchical TokenId set that will expand/or contract based on the forking and joining and/or splitting and merging that occurs throughout the Process. By matching the TokenId set of Tokens that arrive at objects that have multiple incoming Sequence Flow, it will be possible to determine the boundaries of execution language structured activities.
A BPMN Gateway will usually indicate the start of a BPEL4WS structured element, but even this may not be one-to-one if there are loops involved. The end of the BPEL4WS structured element is even less obvious, since it could be marked by the convergence of Sequence Flow into most types of BPMN elements.
The following sections will describe how different BPMN configurations will map to the BPEL4WS structure elements and show how conceptual Tokens can be used to determine the extent of the BPEL4WS elements.
The most basic structured element of BPEL4WS is the sequence.
For the other types of BPEL4WS elements, their extend is determined by tracing through the Process with conceptual Tokens:
The end of a BPEL4WS structured element will be found when all the paths, which were identified at the start of the element, have converged.
Another structured element may occur before the first structure element is closed.
Loops are created when the flow of the Process moves from a downstream object to an upstream object.
The following sections will describe the mapping for the different type of loop configurations.
This type of loop is created by a Gateway that has only two outgoing Sequence Flow. One Sequence Flow continues downstream and the other loops back upstream (see See Example of a Loop from a Decision with Two Alternative Paths.). Note that there might be intervening activities prior to when the Sequence Flow loops back upstream.
This type of loop is created by a Gateway that has three or more outgoing Sequence Flow. One Sequence Flow loops back upstream while the others continue downstream (see See Example of a Loop from a Decision with more than Two Alternative Paths.). Note that there might be intervening activities prior to when the Sequence Flow loops back upstream.
This is a situation where there at least two loops involved and they are not nested (see See Example of Interleaved Loops.). Multiple looping situations can map, as described above, if they are in a sequence or are fully nested (e.g., one while inside another while). However, if the loops overlap in a non-nested fashion, as shown in See Example of Interleaved Loops., then the structured element while cannot be used to handle the situation. Also, since a flow is acyclic, it cannot handle the behavior either.
To handle this type of behavior, parts of the BPEL4WS process will have to be separated into one or more derived processes that are spawned from the main process and will also spawn or call each other (note that the examples below are using a spawning technique). Through this mechanism, the linear and structured elements of BPEL4WS can provide the same behavior that is shown through a set of cycles in a single BPMN diagram. To do this:
This type of loop is created by a Sequence Flow that loops back without an intervening Gateway to create alternative paths (see See Example: An Infinite Loop.). While this may be a modeling error most of the time, there may be situations where this type of loop is desired, especially if it is placed within a larger activity that will eventually be interrupted.
As was seen in See Process with Long Sequence Flow., See Process with Link Intermediate Events Used as Go To Objects., and See Link Intermediate Event Used for Looping., Link Intermediate Events can be used as Go To Objects. The basic impact of using them in such a way is that they are a substitute using a single, longer Sequence Flow to make the same connection between two objects. Thus, the mapping to BPEL4WS should be done by considering them as just a single Sequence Flow. This means that the Intermediate Events are not mapped to any BPEL4WS element. Instead a conceptual Sequence Flow will be used, with the Source and Target of that Sequence Flow being the Source of the Sequence Flow going into the Source Link Event and the Target of the Sequence Flow coming out of the Target Link Event (see See Example: A Pair of Go To Link Events are Treated as a Single Sequence Flow.). The mapping at this point can done using all the mapping consideration described in this Chapter.
See Example of Partial Recombination of Tokens. is repeated below in See Example: Activity that spans two paths of a BPEL4WS Structured Element. to illustrate how BPMN objects may exist in two separate sub-elements of a BPEL4WS structured element at the same time. Since BPMN allows free form connections of activities and Sequence Flow, it is possible that two (or more) Sequence Flow will merge before all the Sequence Flow that map to a BPEL4WS structure element have merged. The sub-elements of a BPEL4WS structured elements are also self contained and there is no cross sub-element flow. For example, the cases of a switch cannot interact; that is, they cannot share activities. Thus, one BPMN activity will need to appear in two (or more) BPEL4WS structured elements.
There are two possible mechanisms to deal with the situation.
In See Example: Activity that spans two paths of a BPEL4WS Structured Element. displays this issue with an example. In that example, two Sequence Flow merge into the "Include History of Transactions" Task. However, the Decision that precedes the Task has three (3) alternatives. Thus, the Decision maps to a BPEL4WS switch with three (3) cases. The three cases are not closed until the "Include Standard Text" Task, downstream. This means that the "Include History of Transactions" Task will actually appear in two (2) of the three (3) cases of the switch.
Note: the use of a BPEL4WS flow will be able to handle the behavior without duplicating activities, but a flow will not always be available for use in these situations, particularly if a BPEL4WS pick is required.
See Example: BPMN Elements that Span Multiple BPEL4WS Sub-Elements.See . displays some sample BPEL4WS code that reflects the portion of the Process that was just discussed and is shown in See Example: Activity that spans two paths of a BPEL4WS Structured Element.. Note that there are two invoke elements that have the same name attribute ("IncludeHistoryofTransactions").