OMG created a page as a follow up to the information provided at the Think Tank workshop held on May 23-25th 2006. From the keynote “BPM Market Overview” presented by Connie Moore, Vice President and Research Director of Forrester Information Delivery Research Group, I picked the following slides:
I expected that the transformation of a BPMN diagram to a WF workflow would be accomplished by mapping each BPMN Process to a Sequential Workflow. But, there is a structural difference between the BPMN diagram and the Sequential Workflow. The difference is that the Sequential Workflow is block-structured (i.e. all paths from a split or branch reconverge at a single node), while the BPMN diagram is a free form graph. The arbitrary sequence flows allowed in BPMN are similar to GOTO statements. Given that Sequential Workflows does not have a GOTO activity (see a related thread from MSDN forums), the transformation is not possible without redrawing (re-engineering) a semantically equivalent block diagram.
The problem is equivalent with the problem of transforming BPMN to BPEL. Bruce Silver wrote a useful post on the topic and Yi Gao (Chief Architect of eClarus Software) wrote an interesting white paper. From these sources I copied an example BPMN diagram that presents the problem of block-oriented representations (like Sequential WF and BPEL).
But, what if we map the BPMN diagram to a State Machine Workflow? Then we can solve at least the GOTO problem. We can map each task and each gateway of the BPMN to a State activity, which contains a single StateInitializationActivity, which executes its contained activities when entering the state. The State Machine Workflow diagram is the following:
Each StateInitializationActivity which corresponds to a BPMN task contains two childs activities: one for the implementation of the task and a SetStateActivity which causes the transition to the next state. Each StateInitializationActivity which corresponds to a BPMN gateway also contains two child activities: an IfElseActivity to evaluate conditions and again a SetStateActivity which causes the transition.
(Draft, to-be-updated post)
Activities
| BPMN | Windows Workflow Foundation |
| Process | |
| Sub-Process | Maps to any CompositeActivity. |
| Loop Sub-Process | Maps to a WhileActivity. |
| Multiple Instance Sub-Process | Maps to a ReplicatorActivity. |
| Ad-Hoc Sub-Process | |
| Compensation Sub-Process | Maps to a CompensateHandlerActivity. |
| Task | Maps to any atomic Activity that has only implementation semantics (e.g. CodeActivity or InvokeWebServiceActivity) |
Events
| BPMN | Windows Workflow Foundation |
| Start Event [None] | |
| Start Event [Message] | |
| Start Event [Timer] | |
| Start Event [Rule] | |
| Start Event [Link] | |
| Start Event [Multiple] | |
| End Event [None] | |
| End Event [Message] | |
| End Event [Error] | Maps to a ThrowActivity. |
| End Event [Cancel] | This type of End is used within a Transaction Sub-Process (aka inside a TransactionScopeActivity). Maps to a ThrowActivity. |
| End Event [Compensation] | Maps to a CompensateActivity. The attribute Activity:object maps to property TargetActivityName:string. |
| End Event [Link] | |
| End Event [Terminate] | Maps to a TerminateActivity. BPMN does not has an equivalent of the property Error:string. |
| End Event [Multiple] | |
| Intermediate Event [None] | |
| Intermediate Event [Message] | |
| Intermediate Event [Timer] | When used within the main flow, acts as a delay mechanism: Maps to DelayActivity.When used for exception handling it will change the Normal Flow into an Exception Flow.Either the attribute TimeDate:Date or the attribute TimeCycle:string are mapped to the property TimeoutDuration:TimeSpan |
| Intermediate Event [Error] | When used within the main flow, maps to ThrowActivity.The attribute ErrorCode:string maps to properties FaultType:Type and Fault:Exception.When attached to the boundary of an activity maps to FaultHandlerActivity. |
| Intermediate Event [Cancel] | This type of Event MUST be attached to the boundary of a Sub-Process. Maps to CancellationHandlerActivity. |
| Intermediate Event [Compensation] | When used within the main flow maps to CompensateActivity. The attribute Activity:object maps to property TargetActivityName:string.When attached to the boundary of an activity maps to CompensateHandlerActivity. The attribute Activity:object is ignored. |
| Intermediate Event [Rule] | Maps to a PolicyActivity. The attribute RuleName:Rule maps to property RuleSetReference:RuleSet. |
| Intermediate Event [Link] | |
| Intermediate Event [Multiple] |
Gateways
| BPMN | Windows Workflow Foundation |
| Exclusive (XOR) Gateway [Data-Based] | Maps to a IfElseActivity. |
| Exclusive (XOR) Gateway [Event-Based] | |
| Inclusive (OR) Gateway | |
| Parallel (AND) Gateway | Maps to a ParallelActivity. |
| Complex Gateway |
John Evdemon (Microsoft Architect) notes in a recent forums post:
Regarding WF, the underlying XML representation is XAML. Why did we choose XAML instead of BPEL or some other standard? Simple – XAML enables us to avoid the constraints imposed by a focusing on a single standard (e.g. BPEL lacks human workflow and sub-processes). WF is capable of supporting multiple standards
- A BPEL 1.1 import/export tool is currently being tested and will be released later this year.
- We are in talks with partners to add BPMN modeling for WF
- I am aware of a couple of projects looking at XPDL and BPSS for WF
- The custom loader (I believe it becomes available in Beta 2.1) enables us to directly transform a BP standard to an executable representation, possibly enabling support for executable BPEL.
Scott Guthrie on Continuous Integrations.
Source: Scott Guthrie's Blog
Some resources on the new localization features for ASP.NET 2.0:
The Development Abstraction Layer: An excellent piece from Joel Spolsky.
Two posts on WWF services: The Persistence Service and The Transaction Service.
Sandy Kemsley blogs her notes for the BPMN Technology Roundtable of the BPM Think Tank 2006. Two important quotes:
OMG is not recommending XPDL for serialization of BPMN, but recommends the use of BPDM.
[There are] some ideas about defining aspects of a process, such as security, escalation and exception handling, in order to simplify the primary representation. The aspects would be invoked whenever an activity is executed, but represented on separate diagrams. In that way, an aspect would effectively be a template for activities that could be overlaid on any of the activities in the main diagram and extend the meaning of the main diagram. Each activity in the main diagram would need a mechanism for passing some number of parameters to the instance of each aspect that may execute for that activity, for example, some measure of the time-criticality of an activity in order to trigger an escalation at the approriate time.
Sources:
Swenson [Fujitsu] came back to the issue of XPDL versus BPEL, which he doesn't see as competing. XPDL is about process design, about serializing and saving what you drew in BPMN, and not so much about execution. He sees XPDL as a way of moving a process from one design/simulation/analysis tool to another (about 30 tools support it today), whereas BPEL is about the nuts and bolts of sending messages from one location/service/system to another. As Evdemon [Microsoft] said, XPDL is like XMI for business processes. Swenson states that XPDL will continue to track and adjust to any changes to BPMN.
