Styles and Scenarios

  • Article

I believe there are three styles of workflow:

  1. Sequential
  2. State Machines
  3. Rule-based (Data-Driven)

These styles are not mutually exclusive and are quite likely to intersect with one another (e.g. a State within a State Machine may contain a sequential workflow that uses business rules). There are some pretty good guidelines for which to use when - Dave Green did a great job of documenting some of these guidelines. 

Its also intertesting is to think about the different scenarios in which one might use workflow. Listed below are some that I'm working on but I'm sure there are more. For each of these I'm interested in identifying the patterns, best practices and general guidelines associated with each (code samples coming soon). 

  • High transaction throughput: Involves a high number of messages and instances of the workflow, numbering in the thousands to hundreds of thousands per second. May involve simple or complex workflow. May exclude human intervention due to high transaction volume. 
  • High frequency of change in process: Workflow would be changed frequently based on changing business rules, changing order of operations or change of infrastructure or environmental conditions. This change may be at an analyst or programmer level.
  • Incorporates flexible business rules: In many respects relates to frequency of change, but more specifically related to the business rules. May not need frequent change, but would need to be flexible in the ability to change along the lines of business rules, perhaps based on business or data conditions at run time.
  • Page Flow: Controls user experiences by serving up UI "pages" - can be used within a web-based or rich UI environment.
  • Control Flow: Uses MVC with the state of the workflow to affect the state, appearance or availability of UI controls. May be used with both web-based or rich UI environments.
  • High volume of data: Characterized by a large chunk of data that flows from beginning to end or is assembled as a result of the workflow. This data could be in binary, XML or other format but would typically be several hundred MB or GB in size.
  • Heavy use of web services: This workflow has a high dependency on web services for integration, messaging and orchestration.
  • Process externalization: Characterized by the dependency on external processes that are shared or need to be spawned or joined to process the workflow. While many times a specific workflow step may be a black box process, this characteristic is meant to focus on external processes as white boxes that need to be integrated with. 
  • Long running processes (LRPs): These processes may last for days, weeks, months or even years. They may need to be started, held and restarted again in longer timeframes with no loss of fidelity. May make use of WS-BA.
  • Need for audit trail or analytics: This may be a common characteristic across all of these, but specifically denotes where audit trails, activity tracking and analytics of the workflow model and performance are dominant needs in the solution.
  • Human intervention likely during flow: Where it is likely that a human will need to take action during a workflow, this includes those scenarios. It is likely that a human may initiate a workflow process most of the time; however this denotes processes where a human must intervene during a process in order for it to move forward and complete.
  • Event driven architectures: The workflow is the "heart" of the EDA, providing or calling the business logic to catch and handle events. May make use of WS-Eventing.