上篇文章介绍了工作流的概念和作用。这篇文章继续介绍根据工作流运转原理产生的具体工作流管理系统。
因为有许多软件开发商都有工作流产品，并且不断有新的工作流产品走入市场。市场上可选择的产品范围很大，因此每个开发商只关注产品的特殊功能，而用户可以采用不同的产品来满足不同的需求。
然而，由于各个厂商不兼容的流程控制方式，导致没有统一的规范使得不同的工作流产品协同工作。对于这个问题，业界一直认为，所有的工作流产品都有一些相同的特性，只要其各种功能遵循公共的标准，就可以实现不同工作流产品间的协同工作。
因此WfMC（Workflow Management Coalition）工作流管理联盟应运而生，它是由一些公司联合在一起成立的组织，从事工作流问题的研究和指导。
下图就是WfMC提出的工作流管理系统参考模型（Reference Model of the Workflow ManagementCoalition）。作为工作流技术标准化的工业组织，WfMC的这个参考模型为各家工作流管理软件提供者的系统设计规划给出了权威的参考，乃至标准。
首先，最重要的部分就是中间的工作流引擎，可以说它就是整个工作流管理系统的心脏，因为所有的工作流管理系统都要使用工作流引擎：
1）为执行的流程实例解释流程定义——这些流程定义一般都是由接口1获得的。
2）组织调度流程的实例，推进工作流程的前进，这包括条件流转、分支聚合、父子流程等
3）处理工作任务的分配、接受、提交等行为—–无论是人工干预或自动执行的任务，都需要经过工作流引擎计算和持久化（如果需要的话）。
4）管理调用其他的4个接口——这可能包括执行工作流程定义中的一些外部脚本。
工作流引擎做的工作就像心脏把血液不断地送到身体的各个部分一样。
然后是工作流管理系统“身体”的5个组成部分吧，也就是上图中的示的5个接口。
先总结一下，工作流管理系统参考模型的5大接口各自强调了什么。
接口1——提供流程定义。
接口2—提供工作任务列表等客户端应用程序，实现使用者与工作流引擎的沟通。
接口3——支持外部应用程序参与工作流程。
接口4——支持不同工作流引擎系统间的连接。
接口5——提供监控工具，搜集管理信息。
使用工作流管理系统大概的来说是分两步：定义流程和使用流程。接口1就是后台的定义过程，而接口2就是前台的使用流程定义的表单使用过程。
详细介绍这两个接口：
(1)流程定义工具
前面提到过我们使用它来设计业务流程定义供工作流引擎来实例化运行。所谓的“业务流程定义”一般来说就是一段XML，它一般遵循XPDL（XML Process Define Language）标准、BPEL（Business Process Execution Language）标准或其他厂商自定义的标准（例如jBPM的流程定义语言就是jPDL）。
事实上可以把流程定义工具理解为一个产生XML的图形化设计建模软件。这种软件各个厂商的技术实现可谓五花八门，仅基于Web的就有很多种技术实现，例如Java Swing，Flash，ActiveX，flex等，这次我们的项目使用的就是flex作为流程定义的可视化工具。
当然，很多开源项目采用的还是基于客户端的实现，例如jBPM使用的是基于Eclipse图形化插件的实现，Shark Workflow使用的则是JAWE（一种基于Java技术实现的XPDL建模工具）。当然，它们的最终目的都是统一的——产生XML格式的流程定义。
举个jpbm图形插件的例子例子。下图是用jbpm的Eclipse的可视化designer插件做出的流程定义图。
使用可视化的工具就是方便且容易理解，但最终流程引擎能够解析的还是xml文件。所以最终图形会生成xml文件。
（2）工作流客户端应用。
当业务流程设计好了、运行起来了，那么我们使用者就需要与工作流引擎交互了,这就要用到工作流引擎就通过接口2，为我们提供各种各样的工作任务列表、工作表单、流程列表以及一些查询功能。
我们通过这些接口应用，就可以填写表单、处理任务..从而实现人与工作流引擎的沟通。
工作流管理联盟给出的关于工作流管理系统的定义是：
工作流管理系统是一个软件系统，它完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。
工作流管理系统并不包括企业的内部业务逻辑，而是为企业的业务系统的运行提供了一个软件的支撑环境,相当于是底层基础。并不参与具体业务。
工作流管理系统的意义：工作流管理系统的出现，是独立，零散的办公自动化走向综合和集成化，改进和优化了业务流程，提高了业务工作效率。同时实现了业务过程控制，提高了顾客服务质量。此外，由于作为底层，不涉及具体逻辑，就增强了系统的灵活性，提高了业务流程的柔性。