【走出工作流困局】 走出困局
编者按：当面对一个完整的工作流系统时，你可能会被它众多的功能所困惑，但是如果我们转换一种思路，首先从用户使用的角度来进行分析，工作流系统的组成就会变得异常清晰。实际在现实开发中，整个系统也是由用户的业务需求一步步迭代而来。
近两年随着业务流程管理概念的兴起，流程引擎受到了越来越多的关注。
对于很多应用系统来说，流程引擎已经成为了必备的基础设施。市面上的流程引擎产品按名称分为两种：BPM和workflow。
BPM更多倾向于对企业系统的EAI、web服务编排和集成。Work_flow则倾向于对需要多人协同处理的业务处理。
但是随着BPEL4People和WS-HumanTask规范的发布，以及Workflow对各种远程调用服务的支持，BPM和Workflow之间的差别正变得越来越小。
但是，从业务流程的意义上说，不管是BPM还是Workflow，都存在着某种困境。
由于流程的业务描述和可执行的过程描述之间存在差异，导致它们都不能直接对最终用户产生具有重要意义的价值。
用户眼中的工作流
这里的用户分为两类。一类是应用系统开发人员(以后简称开发人员)，一类是应用系统的最终用户(以后简称最终用户)。
对于最终用户而言，工作流系统往往是不能直接使用的，它需要由IT部门的开发人员嵌入到应用系统中。开发人员才是工作流系统的直接使用者，这造成了问题；工作流系统更多关注于开发人员的需求，例如如何快速开发、如何更好的嵌入业务逻辑等等，而最终用户的需求被或多或少的忽略了。
面向开发人员的流程设计器
最终用户通过流程设计器对业务流程进行描述，实际是一个流程建模的过程。
理论上，业务分析师完成这个业务流程建模的过程，并且业务分析师往往被假定为非技术人员。
对于业务分析而言，流程建模通常是抽象的，一定程度上是模糊的，建模的目的在于通过图形的形式向其他人解释一个业务的过程，图形只是一种方式，采用它只是它更易于理解和易于沟通，实际类似于DSL。
工作项列表
即任务列表。工作流系统通过工作项列表进行人工任务的分配。最终用户通过该列表签收、处理每天的工作，工作以工作项的形式展现。对于工作项，用户有着多种业务操作签收、完成提交、收回、回退等等。对于分配给他人的工作项，也存在着多种业务操作：催办、提醒、时间限定等等。
流程追踪
用户在处理工作项时，对该工作在流程中所处的位置进行查看，了解当前流程的状态和执行情况。一般情况下，流程追踪以图形化的方式展现。
流程实例管理
包括流程实例、节点实例、工作项实例的管理。改变状态，包括了挂起、重新启动、终止、跳转等等。主要目的在于对流程人为执行错误进行人工干预以及对流程信息的监控。
系统架构
整个工作流的整体构成如图1，各模块分层组织，位于上层的模块依赖于底层的模块。正如你所看到的，流程定义模型位于整个工作流系统的最低层，因为它是整个工作流系统的基础。
流程定义模型定义对流程进行描述的所有对象。因为对流程进行描述的本质就是利用这些模型进行建模，所以这些模型对象的实现直接决定着工作流系统对流程的描述能力。
组织结构适配器工作流系统在与业务系统进行集成时，需要进行组织适配，通过这一过程将业务系统里的组织机构导入到工作流系统里。具体实现时，工作流系统需要建立起自己的组织机构模型(包含在流程定义模型里)，要适应多种业务系统，往往需要建立多套模型，根据具体情况进行切换。有多种方式完成这个适配，最简单的方式是利用SQL配置读取数据进行语义转换。
流程设计器供用户使用的可视化图形工具。每种图形都对应着一种流程定义模型。具体的实现有Swing、SWT，但是基于AJAX的WEB设计器无疑会提供更好的可用性。
流程执行引擎将流程定义模型解释为流程实例模型。利用这些流程实例模型完成流程的调度和执行。在工作流系统里，执行引擎是整个系统的核心。实现时不仅需要考虑各种流程调度的实现，还要考虑执行的效率、缓存、日志等等。
工作项引擎解析参与者定义模型和工作项定义模型，生成相应的工作项，对用户对工作项的操作作出响应。
WEB应用 工作流系统的WEB展现。包括了工作项列表、流程追踪以及流程实例管理的操作和显示。
流程仿真对建立好的流程模型进行运行仿真，模拟流程模型的执行过程。目的在于发现流程建模过程中的疏漏，发现由此导致的流程不能运行。
时间服务提供对整个流程实例执行时间和任务执行时间的控制，根据规则触发相应的时间事件，例如任务超时、任务预警等等。根据规则自动触发启动新的流程实例。
业务集成提供工作流系统与业务系统的契合方式。典型的实现包括通过注册事件监听器和提供接口抽象类调用业务系统代码、提供API给业务系统调用、工作项驱动业务表单和脚本引擎执行业务逻辑脚本等等。特定于工作项驱动业务表单，为方便开发，绝大多数的工作流厂商都提供了电子表单的实现。
困境和前景
工作流系统现在面临很多困境。其一，工作流应用的层次太低，即工作流系统实际面向的是开发人员，它无法对最终用户产生直接的价值。究其根本原因在于：业务流程描述和可执行的过程描述之间的差异。
最终用户所梳理的业务流程往往是抽象的，工作流引擎无法执行。工作流引擎所描述的流程太细粒度，涉及到太多业务系统集成的逻辑细节，最终用户无法调整。
其二，工作流系统对业务系统的支持并不友好，它关注的仅仅是业务逻辑的一个切面，即业务里需要多人协同的部分。脱离开业务协同，工作流无法对业务系统的开发和灵活适应变化的业务产生价值。
关于工作流的发展有两种途径：一种是向上进行抽象，建立起面向最终用户的分层次的流程管理体系，另一种是作为开发平台的基础设置，为领域模型提供生命周期管理(市场上现有的开发平台大部分都内置有工作流引擎，但遗憾的是，一部分还局限于利用工作流处理协同逻辑的范围，另一部分则偏执到利用图形来描述业务逻辑的地步)。面向最终用户的流程层次管理
业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由宏观到微观、由抽象到具体的逻辑关系。
例如，一个典型的软件项目的业务处理流程如图3所示。
对应于流程图里的每 一个节点，都有一个具体业务流程与之对应。以软件开发这个节点为例，存在图3的具体实施流程。
同样，该流程图里的每一个节点也都对应有一个低一层次的业务流程。
业务流程之间的层次关系一定程度上也反映了企业部门之间的层次关系。不同层级的部门有着对业务流程不同的分级管理权限。决策层、管理者、使用者可以清晰的查看到下属和下属部门的业务流程。
例如，在软件项目的业务处理流程里，每一个具体节点的执行就对应着不同部门的具体职责，对于软件开发存在着软件开发部门，而具体到软件开发的业务流程，则分别对应着管理部门、开发部门、测试部门。
这样一个层次关系符合人们的思维习惯，具体到如何利用工作流系统对该业务提供IT支撑，可以这样分步实施。
首先，业务分析人员对企业的业务流程进行梳理，建立起企业的业务模型。
一般来说，我们可以先建立主要业务流程的总体运行过程(其中包括了整个企业的大的战略)，然后对其中的每项活动进行细化，落实到各个部门的业务过程，建立相对独立的子业务流程以及为其服务的辅助业务流程。
业务流程使用工作流的模型定义进行描述，此时建立起的业务流程是不可执行的，其目的在于更好的协助人员之间的沟通。此时，工作流的定义模型需要建立贴近业务的属性，例如附件、规则约束等等。同时，子流程的概念相当重要，需要支持多层嵌套。
接下来，对建立完成的业务流程划分部门职责和权限。不同层级的部门有着对业务流程不同的分级管理权限。每个人员都能查看到属于自己职责范围内的业务流程，并能够通过工作流系统在流程运行期对流程定义进行反馈，根据权限向上级提出修改意见或直接修改。
一定程度上，这个过程能够指导企业组织机构的调整。
明确流程修改的权限有助于建立企业的规章，一个灵活的业务流程是可快速变化的，容许在规章范围内迅速调整以适应外部商业环境的变化。这对业务流程定义的管理提出了更高要求，目前这个管理只是针对开发人员，是单向的，单一的流程设计器即可满足需求，但是此时他面向所有企业人员，并分层次分权限管理。
最后是流程的执行，对于高层次的流程定义，由于其的抽象性，往往是不可执行的(IT系统无法完全有效的支撑)。对于最底层IT系统可以支撑的业务流程，由业务分析人员交予开发人员，目前的工作流系统可以介入发挥作用。
工作流系统在各个层次之间的业务流程建立起信息通知机制，低层次流程的完成触发对高一层次流程节点的通知。对于IT系统无法支撑实现的业务流程，通过手动触发。
向下与开发紧耦合的领域对象生命周期管理
工作流系统实际解决的是领域模型状态等待的问题。在没有应用工作流系统的业务系统里，业务对象往往需要内置一个状态位来标示当前业务对象被人工处理的状态。工作流将业务对象从任务状态��里解脱出来。实际工作流可以做的更多，流程实例可以与业务对象紧耦合起来，管理业务领域对象的生命周期。