工作流现状 OSWorkflow教程教案.pptVIP

* Workflow vs. RDBMS positioned in the hype-curve  内容 什么是工作流管理系统 业务流程管理的优点 流程定义的四个层次 为什么工作流市场乍看起来如此混乱。 什么是工作流管理系统（WFMS） 定义 为什么应当禁止使用术语“活动（activity）”... 目标领域（Target usage） 定义 工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。 流程定义（process definition）和流程实例（process instance） 目标领域（Target usage） 作为企业应用系统集成（EAI）的平台。 协助涉及多人相关任务工作流软件的开发。 将工作流引擎嵌入到其他应用中。 EAI 专门应用（ dedicated applications） 专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中 企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。 工作流系统将业务流程描述作为输入并管理流程实例的执行， 工作流系统可以用来管理全局的业务流程。 在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。 协助涉及多人相关任务工作流软件的开发。 大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。 将工作流引擎嵌入到其他应用中。 在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。 业务流程管理的优点 提高效率 较好的流程控制 改进客户服务 灵活 业务流程改进 流程定义的四个层次 状态（state） 上下文（context） 程序逻辑（programming logic） 用户界面（UI）。 状态层 所有状态和控制流的表述，都属于业务流程的状态层。 在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。 流程定义中的状态也指定了执行依赖于哪个参与者。 流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。 上下文层 简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。 变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。 程序逻辑层 程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。 程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。 程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。 用户界面层 一个参与者通过向流程变量中填充数据的事件，来触发结束一个状态。 某些工作流系统允许指定哪些数据可以填充到流程中，以及它们如何在流程变量中存储。通过这些信息，可以生成从用户收集信息的UI表单。 工作流全景 可执行流程与工作流管理系统的比较（Executional processes versus a WFMS 开放源代码项目 商业软件提供商 工具目录 规范 可执行流程与工作流管理系统的比较 当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。 三点区别 基于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这样的可执行流程以对输入消息响应的定义为中心。 流程实例ID与消息相关处理：可执行业务流程的复杂性之一来自消息相关性的处理。 工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户