计昨天学习工作流 今天继续学习工作流
[网摘:]
工作流引擎(Workflow Engine)
什么是工作流引擎？所谓工作流引擎是指 workflow 作为应用系统的一部分，并为之提供对各应用系统有决定作用的根据角色、分工和条件的不同决定信息传递路由、内容等级等核心解决方案。开发一个业务系统最关键的部分不是系统的界面，也不是和数据库之间的信息交换，而是如何根据业务逻辑开发出符合实际需要的程序逻辑并确保其稳定性、易维护性（模块化和结构化）和弹性（容易根据实际业务逻辑的变化作出程序上的变动，例如决策权的改变、组织结构的变动和由于业务方向的变化产生的全新业务逻辑等等）。 Workflow 引擎解决的就是这个问题：如果应用程序缺乏强大的逻辑层，势必变得容易出错（信息的路由错误、死循环等等）。就好比一辆汽车，外表做得再漂亮，如果发动机有问题就只是一个摆设。应用系统的弹性就好比引擎转速方面的性能，加速到 100 公里需要 1 个小时（业务流程发生变动需要进行半年的程序修改）还能叫好车吗？引擎动不动就熄火（程序因为逻辑的问题陷入死循环）的车还敢开吗？
工作流引擎结构
工作流引擎是整个工作流产品的核心部分。
工作流引擎结构
工作流引擎的结构一般分为：
1、引擎内核
2、业务逻辑
3、封装
4、接口应用管理
工作流解决方案与传统管理软件的关系
传统的管理软件注重解决企业应用层现存的问题（例如提高企业的资源配置率或提高单一员工的生产效率）。例如：EXCEL 可以提高员工画表格的效率、财务软件可以规范财务人员的工作并提高 目查询的效率、 CRM 可以规范客户管理从而使客户资源掌握在公司手中而不是被一部分业务人员把持并提高客户响应时间、ERP 解决的是如何配置企业资源：使企业的人力资源、财力资源和物资资源能够根据业务的需求实现最大化配置。 workflow 关注的是如何缩短流程闲置时间，从而提高企业的业务处理能力并使企业能够关注于真正对企业有意义的增值业务上。从建立企业神经系统的角度也许更能理解两者的区别。传统软件不能解决工作流的问题，例如 ERP 关注的是企业的资源配置，但不可能解决资源传输过程中的损耗和降低传输（流程）的成本；同样 workflow 也不能完全解决传统管理软件所能解决的问题，例如对生产管理的 MRP 系统所能解决的生产过程控制通过 workflow 很难实现。但一个好的传统软件如果希望能自动化地在整个企业中应用起来，必须有一个强大的逻辑层，用以解决信息传递的逻辑判断和自动流转，这个时候就需要 workflow 的平台。
workflow 的优势
1.workflow 和传统管理软件不是同一种软件，不具可比性； 2.workflow 对于已经有传统管理软件的企业的作用非常明显，可以籍此平台整合企业的各种应用系统，使之成为一个完整的企业级应用，也就是通常所说的 EAI. 3. 具备 workflow 功能的管理软件（workflow 与传统管理软件的结合）对于传统管理软件有绝对的优势； 4.workflow 可以根据企业的需要开发解决信息传递问题的流程以及帮助企业开发与现有应用系统的接口。
常规的业务流程
工作流自动化并不复杂因为下述几个原因，工作流自动化业界有" 适合处理复杂业务流程" 的名声。常规工作流自动化软件包及其部署相当昂贵。通常，伴随产品的是长时期的咨询关系。所以为了非常简单的业务流程购买和部署软件是被不被采纳的。这些软件通常只被用于复杂、 关键和控制成本相对较高而工作流自动化带来的效益明显的量产型工作流应用。因此经销商和用户都会不自觉地关注于将复杂的业务问题自动化。
复杂的业务流程
出于类似原因，工作流研究人士首先会关注解决了哪些复杂的业务流程问题.而对于大多数案例而言，为解决简单工作流程问题部署自动化软件的成本显然是不经济的。这里遵循一条简单的道理：走之前必须先会爬，跑之前必须先会走。
解决复杂问题的能力
最后一条原因，也是"IT 业的尴尬".总经理对 IT 部门经理工作衡量的标准就是：能够解决复杂问题的能力。自然，IT 经理就会不遗余力地解决些复杂的问题，他们的方案通常也就复杂而且昂贵。所有这些目前都在改变。针对桌面电脑的应用方案快速发展以及工作流解决方案的发展使解决日
常工作流程问题成为可能。费用不再昂贵，部署更为简便。事实上，企业越来越意识到工作流的重要性，
同时在部署复杂关键的流程自动化之前，愿意从一些简单的流程入手积累经验。
工作流自动化
工作流自动化的主要成分工作流自动化如今成了管理的一句时髦话。市面上也有很多号称能激工作流的自动化产品。只要他们的应用程序支持基本的 E-mail 功能，卖主就会随意地把" 激活工作流"作为标签贴在产品上。然而，这类产品和真正工作流自动化软件之间的差别就如同写字版和 Word 之间的差别。
工作流自动化解决方案
我们相信，应用程序只有具备了下列主要特征，才能称其为工作流自动化解决方案：能够画出工作流程图，当然以图形化界面设计的为佳；能为每个步骤设计电子表格；能将外部应用程序结合为工作流自动化的一部分；能与电子表格及企业数据库相连接；能设计基于复杂业务规则的条件型路由的工作流程图，最好无须编程；能根据功能、用户名称或上下级关系按规则传递信息；能够监控工作流执行状况；能够对工作流进行调节；能够模拟并测试工作流的行为；工作流的应用必须支持多用户并具高度可靠性；工作流的应用必须支持内部网或英特网及跨多种平台。
工作流所处的位置
网友讨论工作流应该是一个中间件而不应该是一个完整的系统。工作流应该整合到其他系统中而不是单独使用。
我觉得工作流与其说是中间件，还不如说是一个应用整合和集成的框架。类似在 j2ee 规范下各产商开发的应用服务器，工作流也应当是在 wfmc 标准下开发出来的" 容器" ，只要是满足了标准的应用程序或组件都能够在这个" 容器" 中按照预定的规则被调度和执行。我认为理想情况下工作流系统不应该提供 API 作二次开发，工作流的内部对基于工作流的应用程序应当是完全不透明的，工作流应当提供给开发者的是一个类似于 J2EE 那样的标准，一套编程模型和接口模型。开发者在这个模型下去实现那些接口，开发出应用组件，再利用工作流提供的管理器进行" 注册".总而言之，对开发者而言，工作流是黑箱，他需要做的事情是开发标准组件，在工作流提供的 UI 管理工具中配置业务流程，包括业务过程、资源、权限、时间、规则等等。
1. j2ee 应用服务器也是中间件的一种。
2. 工作流要做成 j2ee 哪样的标准还是比较困难的,j2ee重点在于提供开发全新系统的能力， 所以可以制定比较好的容器- 组件标准，而工作流的重点是整合已经存在的系统，要在这些各式各样的老系统上强加标准是不现实的。
3.工作流应该提供 api ，因为其他系统中的一些事件可能会启动一个流程，或者触发其他与流程相关的东西。
工作流的柔性
这是因为随着企业角色、业务、场景等的多样化，企业对工作流的适用就提出了要求，一个缺乏变通性、灵活性也就是柔性的工作流软件是不足以满足企业使用的。这样必然导致企业有可能花了大价钱却无法得到回报或者仅仅在前期得到回报，一旦业务发生了改变可能就无法再继续使用同一款软件了。我认为在工作流管理系统在设计和实施中，都必须提供足够的柔性，来满足不同应用的需要。在与不同的应用系统进行交互时，要提供足够的灵活性。可以建立应用接口规范和提供标准的 API 函数在不同的系统间进行交互；可以建立灵活的调用通道，直接调用各种应用系统中的应用进行事务处理，并且这种调用可以在分布和异构的系统间进行。这样的工作流软件才具备柔性的话。典型莫过于工作流软件方正的飞鸿 ES2007 柔性定制平台，是具备柔性的，它的所有应用都是可以定制的，不但可以自己在平台配置也可以交给方正去定制特殊应用。也许在国内很多工作流软件还没认识到柔性的重要性，但更多的工作流软件都是应该意识到了。以后的企业应用之后越来越灵活、越复杂。不具备柔性的功能是无法再以后使用的。
工作流要完成的核心功能
工作流要完成的核心功能有流程设计，流程执行，流程和线程的调度，任务的分派与通知，集成已有信息系统（很多人忘了）。工作流应该提供对组织机构，用户，权限管理，流程，任务的管理能力，但是对这些管理能力最基本实现方式是提供 API ，而不是一个管理系统，即使把这些管理作为一个管理系统来实现（A ），也要是用于演示，因为当工作流用于其它系统（B ），因为 B 需要一个统一的管理界面，所以通常不会直接使用 A.而表单设计，报表之类根本就是外围功能，是二次开发商的任务。
工作流的分类
工作流分为两种类型，一种是嵌入式的，另一种是非嵌入式的。这在 WFMC 的文档中已经有所介绍，大家可以找找看一下。按照工作流管理联盟的文档，大家说的都没有什么错误，只是侧重点不同。我的看法并不是趋向于嵌入式工作流。我理解的工作流提供的 api 并不是一般软件包的 API ，而是一种服务方式的 API ，类似于操作系统中的系统调用。我们在软件中大量使用了操作系统提供的系统调用 API ，但是操作系统并不是嵌入到我们软件系统中的。我认为工作流系统与操作系统有很强的可比性，只是工作流层次更高。比如流程设计相当于编程，模型相当于程序，流程实例相当于进程，流程分支相当于线程， 操作系统要对进程和线程进行调度，工作流引擎要对流程实例和分支进行调度，操作系统和工作流系统都应该对内存进行管理避免耗尽系统
内存，操作系统提供系统调用 API 而工作流引擎提供工作流 API.何其相似。
工作流的功能
从功能的角度看：工作流系统的本职工作就是管理和控制业务流程，例如：流程实例的启动、停止；环节实例的启动、结束；任务的分配等等。从工作流系统的组成看：工作流系统应该包括流程引擎、流程定义工具、运行管理工具、api 系统。工作流系统应该不包括表单定义、组织机构定义及其管理、权限管理、数据流管理等等。
工作流与传统管理软件的交互关系
工作流系统虽然不包括上述功能，但是工作流系统一定会和上述功能发生交互关系，所以好的工作流产品并不是一个包办上述功能的产品，而是一个设计良好的能够和上述功能交互的系统。从和其他系统的关系看待工作流：如果站在基础业务平台的角度，那么，工作流系统、组织机构管理系统、自定义系统、权限管理系统、数据流管理系统、报表系统都是这个基础业务平台的服务。业务功能系统在运行的过程中会调用这些服务，这些服务之间本身也可能互相调用。例如：工作流服务和组织机构管理服务之间的关系就非常密切，尽管如此，如果认为工作流系统一定包含组织机构管理系统应该是不正确的。在 oa 系统中，表单自定义好像比较重要，而且流程常常需要引用表单上的数据，但是表单自定义绝对不是工作流系统的组成部分。流程在运行的过程中可能跨多个数据库系统，任务在流转的过程中需要“携带”大量的业务数据，但是这些也不是工作流要做的事情，完成这些工作的系统我称之为“数据流管理系统”。总之：从功能的角度，所有的功能都是必要的，但是从技术的角度，这些功能不可以做到一个“铁板一块”的所谓的“ 工作流” 里面去。从技术发展的趋势看：工作流系统很可能发展成为一个类似关系型数据库管理系统的专职的系统。
预备知识总结
以上是综合的简介了工作流的概念和工作流的主要功能、特点、难点与业界的普遍理解。那么，究竟如何设计一套既独立于业务系统，又可以在需要的时候与业务紧密协作的工作流平台呢？这是一个较为复杂的课题。
-----------------------------------------------------
转载请注明来源此处
原地址：#
发表