On the surface modeling a workflow in software might seem like a very straight forward task.

After all according to wikipedia "A workflow is a depiction of a sequence of operations…". This sounds like a great match for a computer program modeling the workflow.

You could then use the software workflow to

1. Guide you through the workflow process.
   
2. Perform actions through the software such as send email, operate equipment or perform a computational process such as adjust a photograph.
   
3. Facilitate approvals
   
4. Record activity especially when actions were taken.
   
5. Roll up the results and status in other documents
   

However there are issues (you didn't think it could be quite this simple). All of these issues are resolvable, but add an extra layer complexity to modeling a workflow in software.

1. Workflow programs must be able to operate for days, weeks or even years. The implication is that the workflow program must automatically preserve its status. The status must be automatically restored if the computer is restarted.
   
2. Workflows go through states when the operations occur. Operations, or commands, need to work only in the appropriate state. For example a "Complete" command may only valid once the workflow is 'started'.
   
3. Workflows are performed by more than one person. This means that the workflow must be able to support simultaneous users working on different computers or devices.
   
4. Workflows need to be shared, but also be protected from incorrect usage. For an expense workflow the user may need to be a manager to approve it. The workflow program needs support different roles for different users.
   
5. Not everyone who uses a workflow sees the same data. For example an approver's comments may need to be hidden from the applicant.
   
6. Workflows change over time. For example an 'approval' process may change while there are requests in the system. The workflow software must be able to handle 'grandfathering' the process for requests already in the system or optionally support upgrading them.
   
7. Workflow programs need to be simple to design and build.
   

This is rational behind the dynamic language
Jetfire. Jetfire is domain specific language that handles all these issues with ease. Applications can be built quickly. Application code isn't obscured by reams of infrastructure code. With Jetfire the designer of workflow software can concentrate on the application, not the infrastructure. All this makes the workflow program more reliable and much easier to maintain.

Links

• Jetfire Site
  
• Download Jetfire
  
• Jetfire Technical wiki
  

Related Articles

• Writing Jetfire programs
  
• Why use a Language vs a Framework
  
• Workflow Ecosystem
  
• Displaying Workflows