（产业经济学专业论文）基于WEB的工作流管理系统研究与设计.pdf

序言 f 随着计算机与网络技术的迅速发展，特别是在i n t e r n e t 应用日益普及的情 况下，现代企业的信息系统的分布性、异构性和自治性的特征越来越显著，相应 的企业信息资源也分布在异构的计算机环境中，信息源之间的连接表现出松散耦 合的特点。企业物理位置的分散性和决策制定过程的分散性特征日益明显。对日 常业务活动详细信息的需求日益提高，b r o w s e r s e r v e r 体系结构和分布式处理 技术( c o r b a 、w w w 、o l e 、j a v a ) 的广泛应用，都说明了这样一个事实：集中式 信息处理的时代即将成为过去，取而代之的将是大规模的异构分布式信息处理与 应用执行环境。在这种大规模的分布式环境下高效运转相互关联的任务，并且对 执行的任务进行密切监控已成为- $ p 发展趋势。在这种技术背景下，由最初的 c s 体系结构的集中式工作流管理系统也逐渐向基于w e b ，构架于 b r o w s e r s e r v e r 体系结构的分布式工作流管理系统转化。 基于w e b 的工作流管理系统相对于原有的工作流管理系统有非常大的优势。 在本文将要研究的基于w e b 的工作流管理系统中，客户端采用统一的浏览器界 面，缩短用户学习时间，方便用户使用服务器端采用j 2 e e 技术( j a v a2 e n t e r p r i s ee d i t i o n ) ，其拥有的优势( 面向对象的编程语言、平台独立的特性、 可扩展性、高性能的服务器端编程语言、标准的系统框架和服务、可控性好、与 其它资源的集成) 使之成为适合于当今以及以后企业信息化的主要开发平台，在 此平台上开发的工作流管理系统能更好地与以后的企业信息系统互联互通，适应 企业未来的发展口广一l 本篇论文讨论了工作流管理系统的基本理论，结合j 2 e e 平台中的各项技术 设计了基于w e b 的工作流管理系统的框架，对框架中的重要模块的设计做了详细 的讨论。并且针对框架中工作流过程定义和工作流的处理模式做了归纳总结。 。0 本文的结构是这样安排的：) 第一章对工作流管理系统的定义及工作流管理联 盟所作自虹作做了大致的介 酿第二章从不同使用者的角度，对基于w e b 的工作 流管理系统进行功能上需求分析，并分析了j 2 e e 技术在分布式系统中的作用。 第三章重点论述了基于w e b 的工作流管理系统的架构设计，并对框架中的重要模 块进行了分析。第四章介绍了过程建模，以及如何利用x o l 来描述工作流过程定 义中常用的实体。第五章对工作流中常见的模式进行归纳总结并提出相应的解 决方案，这也是实际的工作流系统的处理方法。最后，对此篇论文所作的工作进 行了总结。 f 在本文的写作过程中，得到了我的导师陈恭和教授的悉心指导，他在论文选 题、结构方面提供了很多宝贵的意见，并在百忙之中对论文进行仔细审稿，没有 他的帮助和监督，论文不可能如期顺利的完成，在此对陈老师表示衷心的感谢! 其次，在过去的三年罩授课的教师们( 篇幅原吲，不能一一指名) 。使我对信息 系统各个部分的内容有了更加深刻的认识，没有他们的辛勤工作，这篇论文的完 成也是不可想象的。 最后，我要把论文献给我的父母和女友，他们的支持和鼓励永远是我前进的 触jv 1 1 引子 第一章工作流管理系统概论 传统的企业计算机管理信息系统的主要功能有三个：信息处理、事务处理、 决策支持。信息传递和信息处理构成了企业和行政管理部门的业务工作中的主要 内容之一，也是计算机管理信息系统的主要功能之一，它是企业进行事务处理( 如 销售定单处理、经营计划、物料采购计划生成、车间作业分配、库存管理等) 和 经营决策的基础。在信息传递和信息处理结果的基础上，各级领导进行相应的决 策活动，这些决策决定了企业业务的开展方式和经营战略。 如何方便地在不同的业务部门和业务人员之问高效地进行信息传递是企业 领导、业务人员，包括现在的计算机软件开发人员十分关心的问题。由于信息需 要定的载体和方法才能够有效的传递，在计算机软件没有成为主要的业务支持 工具前，实现信息传递最好方式是通过纸张作为载体，利用通知、文件、信函、 传真、报告等方式同的业务部门、业务人员之间进行。这种以传统的纸张为载体 的信息传递与处理方式的效率很低，需要花费大量的人力、物力来完成信息的处 理、组织、存储以及查询检索。在各种方式的信息系统普遍应用前，这些工作是 由人工来完成的。在计算机网络技术和分布式数据库技术迅速发展，多机协同工 作技术日臻成熟的基础上，于2 0 世纪8 0 年代中期发展起来的工作流技术为企业 更好地实现这些经营目标提供了先进的手段。至今工作流管理技术己成功地运用 到图书馆、医院、保险公司、银行等行业。 2 0 世纪9 0 年代，随着计算机与网络技术的迅速发展，特别是在n t e m e t 应用 闩益普及的情况下，现代企业的信息系统的分布性、异构性和自治性的特征越来 越显著，相应的企业信息资源也分布在异构的计算机环境中，信息源之间的连接 表现出松散耦合的特点，企业物理位置的分散性和决策制定过程的分散性特征日 益明显对日常业务活动详细信息的需求日益提高，b r o w s e r s e r v e r 体系结构 和分布式处理技术( c o r b a 、w w w 、o l e 、：a v a ) 的广泛应用，都说明了这 样个事实：集中式信息处理的时代即将成为过去，取丽代之的将是大规模的异 构分们式信息处理与应用执行环境。在这种大规模的分布式环境下高效运转相互 关联的任务，并且对执行的任务进行密切监控已成为一种发展趋势。在这种技术 背景下，由最初的c s 体系结构的集中式工作流管理系统也逐渐向基于w e b ， 掏架于b r o w s e r s e r v e r 体系结构的分布式工作流管理系统转化。 本文将研究基于w e b 的分布式工作流管理系统。首先我们讨论工作流和 【：作流管理系统的概念，以及它们之间的联系。 1 2 工作流以及工作流管理系统 工作流的概念起源于生产组织和办公自动化领域。它是针对日常工作中具有 固定程序的活动而提出的一个概念。目的是通过将工作分解成定义良好的任务、 角色，按照一定的规则和过程来执行这些任务并对它们进行监控，以提高办事效 率、降低生产成本、提高企业生产经营管理水平和企业竞争力。 但是在学术界对工作流的认识领域以及研发机构对工作流的实现领域，由于 各自出发点不同，看问题的角度不同，都存在着很多的争议，由此带来的问题是 不同工作流管理系统的巨大差异以及它们之间交互的困难，不利于工作流管理系 统的发展，必须有相关规范和标准。 为此，国际上成立了一个称为“工作流管理联盟”( 简称w f m c l ：w o r k f l o w m a n a g e m e n tc o a l i t i o n ) 的国际组织，它主要的职责就是确定工作流产品功能范 围，并且为工作流产品的实现制定适当的规范和标准，以使工作流技术能被更有 效的使用。 工作流管理联盟给出的工作流定义2 是：工作流是一类能够完全或者部分自动 执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行 者之问进行传递与执行。 工作流管理联盟对工作流管理系统3 的定义是：工作流管理系统是一个软件系 统，它完成工作流的定义和管理并按照在计算机中预先定义好的工作流逻辑推 进工作流实例的执行。 由以上的定义，我们可以看出：我们可以利用计算机来实现工作流表示的经 营过程，而工作流管理系统则是这一实现的软件环境。使用工作流管理系统来作 为经营过程的实现技术，首先要求工作流管理系统能够反映经营过程的如下几个 方面的问题，即经营过程是什么( 由哪些活动、任务组成，也就是结构上的定义) ， 怎么做( 活动间的执行条件、规则以及所交互的信息，也就是控制流与信息流的 定义) ，出谁来做( 人或者计算机应用程序，也就是组织角色的定义) ，做得怎样 ( 通过工作流管理系统对执行过程进行监控) 。而工作流管理系统为企业的业务 系统运行提供一个软件支撑环境。在工作流管理系统的支撑下，通过集成具体的 业务应用软件和操作人员的界面操作，才能够良好地完成对企业经营过程运行的 支持。 工作流管理联盟提出了有关工作流管理系统的一些规范和标准，定义了工作 流管理系统的结构及其与应用、管理工具和其他工作流管理系统之间的应用编程 接口，形成了自己的工作流参考模型。 1 3 i 作流参考模型 图11 为工作流管理联盟提出了工作流参考模型的体系结构图4 。 图i 1工作流管理系统体系结构 工作城应 用数据 这个参考模型的体系结构给出了抽象的工作流管理系统的功能组成部件和 接口，它能够满足工作流管理系统和产品应该具有的主要功能特征。可为实现工 作流产品之间的互操作提供公共的基础。实践中，组成工作流管理系统的每个功 能部件可以在不同的软硬件平台上采用不同的方法实现同样接口也可以在不同 的软硬件平台上采用不同的设计技术和编程语言进行编程。一般说来，工作流产 品的提供商也不会将这些部件之间的所有接口完全对外开放。但是，为了实现不 同工作流产品之间的集成，它们会按照互操作和掷作的不同要求，在一定层次上 开放其接口。 图1 i 中可以看出，工作流管理系统主要由三类构件组成： 软件构件：完成工作流管理系统不同组成部分功能的实现： 系统控制数据：工作流管理系统中的一个或多个软件构件使用的数据； 应用与应用数据：对于工作流管理系统来说，它们不是工作流管理系统 的组成部分，而是属于外部系统和数据，它们被工作流系统调用来完成 整个和部分工作流管理的功能。 图1 2 为工作流管理联盟提出的工作流参考模型5 。 图1 2 工作流参考模型 在此参考模型中，主要涉及了三类数据： 工作流控制数据：工作流执行服务工作流机通过内部的工作流控制数 据来辨别每个过程或活动实例的状态。这些数据由工作流执行服务工 作流机进行控制。用户、应用程序或其他的工作流机工作流执行服务 不能对其直接进行读写操作，它们可以通过向工作流执行服务工作流 机发消息请求来获得工作流控制数据的内容。 工作流相关数据：工作流管理系统通过工作流相关数据来确定过程实例 状态转换的条件并选择下一个将执行的活动。这些数据可以被工作流 应用程序访问并修改。因此工作流管理软件需要在活动实例之间传递 工作流相关数据。 工作流应用数据：这种数据是指那些由应用程序操作的数据。它们是针 对应用程序的，是企业完成具体的业务功能所需要的数据，如产品结构 数据、定单数据、生产作业计划数据等。工作流管理系统无法也不需要 对它们进行访问。 14 基于w e b 的工作流管理系统 l 作流管理系统是一种非常复杂的软件，必须在分布异构的环境下支持一些 高级的功能，例如：安全性，可靠性高性能以及事务处理。随着w e b 技术的发 展和成熟基于w e b 的工作流管理系统有着非常明显的优势： w e b 浏览器一致的本质使w e b 浏览器成为人机交互的自然界面。w e b 浏览 器满足应用开发中备受关注的需求。即它使任何一个用户，无论他使用 何种计算机平台，不用添加其他的硬件就可以参与工作流。很多对计算 机使用不熟练的用户，在平时的i n t e r n e t 浏览中，已经熟悉了易于使用 的浏览器界面，利用w e b 浏览器界面，用户可以获取各种类型的信息， 并且还可以处理简单的流程任务。统一的界面，随处可获得，以及简单 操作性，使得w e b 浏览器成为工作流应用中理想的用户界面。 w e b 技术为实现工作流管理系统提供了牢固可信的通信架构。之前的分 布式应用多采用c o r b a 作为底层支持技术。然而，由于其维护性较差， 参与到工作流中的组织和个人不一定愿意购买c o r b a 产品，他们宁愿采 用w e b 服务器来统一管理。在此基础上，w e b 技术实现的系统同时还具 有良好的灵活性，方便系统扩展。 但我们应当注意区别目前提供w e b 功能的工作流管理系统。很多工作流管理 系统只是提供了w 朗接e 1 ，其底层依然是套接字，远过程调用或c o r b a ，通常把 这种系统成为w e b e n a b l e d 的系统：而完全利用w e b 技术构建，不仅提供用户界 面，还支持通信和分布式部署的系统称为基于w e b 的系统。 本文将要研究并设计的工作流管理系统建构在j a v a 6 技术平台上，是一个基 于w e b 的系统。 15 小结 以上的是对工作流管理系统的简要介绍，工作流管理联盟提出的参考模型 粗略地定义和描述了工作流体系结构中的主要部件和接口，并没有涉及到它们的 具体设计和实现。本篇论文的工作就是结合j a v a 技术，对基于w e b 的工作流 管理系统的设计和实现进行研究和讨论。下一章，本文将对基于w e b 工作流管 理系统的功能需求及平台需求进行详细分析。 第二章基于w e b 的工作流管理系统功能需求 以及系统平台需求分析 2 1 概述 工作流自动化涉及了大量员工、应用软件与作业程序的主动、交互式群体工 作，同时随着现代企业组织日趋复杂且大型化即便是最简单的流程都可能被复 杂化。一套完善的工作流程自动化系统必需提供图形化接口设计、测试、仿真、 导入与评估任何企业流程，并且提供弹性化与扩展性架构，以适应企业未来的快 速成长及调整。 因此，本章主要着重从系统使用者角度，分析此系统应该提供的功能。由于 此系统是一个分布式系统，对服务平台有特殊的要求，在分析平台需求的基础上， 同时也大概介绍了j 2 e e 7 系统平台及其特点。 2 2 基于w e b 的工作流系统功能需求分析 我们可以从用户，系统开发人员、流程管理人员和系统管理人员的角度来说 明系统的功能。 用户通过、v m f 浏览器可以注册、登录、访问自己拥有的资源以及公共资源、 提交新的工作流程、流程反向回转、取消运行的工作流程，完成流程中制定的任 务。 用户注册：用户可以通过m m f 测览器申请新用户注册，其注册信息包 括姓名，所属部门，职位级别，日常工作内容，常用资源，个人信息等。 系统管理员审批后，通知用户其用户名和密码并将用户信息保留到用 户愤源权限数据库中。同时会同系统开发人员确认此用户在系统中可以 履行的职责，如果目前系统还不能够提供此指责对应的操作，系统开发 人员应当定义并开发出这一操作，并把使用此操作的权限赋予给此用户。 用户登录：当用户通过v 、m m 俐览器首次访问系统时，需要登录，输入 注册的用户名和密码，经过系统的身份验证后，返回皱省的页面，随页 面返回的还有s e s s i o n l d ，随后用户就可以访问权限范围之内的资源。如 果没有通过身份验证，则返回错误页面，需重新登录。错误的原因有三： 一是用户没有注册；二是该用户的用户名或密码输入有错误；三是该用 户登录后，在规定的时间内无操作，导致s e s s i o n 超时。 访问资源：用户登录后，可以看到两个资源库，自己私有的资源库以及 公共资源库。私有资源库直接统一管理用户需要加入流程中的数据，表 单，文档，图片等资源。而公共资源库则归纳整理了现有流程类型及其 中包含的通用资源。用户可以对资源库中的资源分类，分级别，对于自 6 己私有的资镢库，用户可以建立、删除、更新，提交某一资源给管理员 成为公共资源库，而对于公共资源库。用户可以在工作流程中直接提取。 察看流程：用户登录获得权限后，可以察看权限范围内自己可访问的流 程实例，可访问的含义包括：对于某些流程实例，用户可以察看，但不 能参与或修改；对于另外一些流程实例，用户可以参与并对其操作( 如 取消此流程) 。 提交流程：用户登录后，系统通过查询用户，资源权限数据库，可以分类 列出用户有权提交的流程类型。用户此时所处的是一种流程类型所产生 的新实例起点。此时用户有可能由于其它原因，没有完成第一步的任务， 流程还只是处于启动状态，并没有被提交运行，在用户完成流程第一步 ( 指定流程中各个任务的具体执彳亍实体、填充流程需要的数据等一系列 操作) 后，流程被提交，处于运行状态，等候流程中下一步处理。 反向流程：在工作流执行过程中，执行到某一步时，此时用户有可能对 之前步奏的流程处理结果不满意，此时，用户向系统发出反向流程请求， 系统查询用户，资源权限数据库后，如果用户对此类流程有足够的权限 那么，用户可以将流程反向到他之前的任意一步重新继续执行。 取消流程：工作流执行过程中，当用户发现自己提交或者参与的某一流 程实例已经没有继续执行的必要或者之前的流程定义已经错误，流程继 续执行会带来不可预料的错误时，用户可以取消在自己权限范围内的流 程实例。 执行任务：用户登录后，如果自己生成并执行一个新流程实例，在流程 第一步所指定的任务中，流程设计人员已经设置了一些常用的缺省值， 在此基础上，用户可以设置此任务执行时需要的资源，以满足此任务结 束的条件，使此流程实例能够继续运行。如果用户登录后，在系统提示 的任务列表中，发现已经运行的流程实例需要自己的参与，则依据流程 优先级依次执行任务。 2 2 2 系统开发人员 系统开发人员可以对系统的功能进行程序级上的开发及扩充。 测试系统功能：系统正式运行后，必然会出现各种各样的错误。这些错 误有的时候是程序上的错误，有的时候是逻辑上的错误，系统开发人员 通过分析系统管理人员提供的系统运行日志，解决系统中存在的问题。 开发实体功能：即使每个行业应用也许有通用的流程，但每个企业的流 程都不会完全相同，而且，业务流程自动化的实施是需要循序渐进的， 需要参与者逐步适应新的操作方式。以办公流程自动化为例，参与者的 操作，一般也就是察看，同意，退回等简单化操作，但是随着流程自动 化应用的深入，也许会出现新的需求，如对文件加盖自己的电子印章， 此时，系统开发人员应该在系统框架下，进行组件功能的开发，实现即 插即用，以满足需要。 第三方对象开发：企业流程有时非常复杂，甚至会牵涉不同类型的工作。 没有家软件厂商可以一次提供满足企业所有需求的软件，因此所有软 件商在开发企业级应用时都会考虑到和其他软件的接口，并为将来可能 的配台留下足够的空闯。工作流自动化软件作为企业级逻辑层平台解决 方案必须允许用户轻易地整合现有第三方应用程序。随着工作流的普及， 具体的应用( 如办公自动化) ，必将和其它系统( 如客户关系关系，企 业资源计划) 进行无缝连接，系统开发人员则要进行第三方对象的开发， 以适应系统的扩张。 2 2 3 流程设计人员 流程设计人员可以对企业中的流程类型，以及流程中需要的资源进行设计及 设置。 设计流程：以直观人性化的图形化方式设计企业工作流程图，已成为现 今工作流自动化软件必备的基本功能。流程设计人员设计的每一张流程 图代表了一个业务流程，同时流程设计人员可定义此流程的意义描述， 个别步骤的意义、条件判断与工作处理顺序和路由等，荠将流程图分类 存入流程类型数据库中，便于用户使用。 设计资源：企业的资源包括数据、订单、发票、图片等一系列信息。要 使整个企业自动化系统正常运行，就必须要有一个一体化的大型信息系 统，在多变的组织结构中获取到关于重要信息实体的通用定义及内容。 通用，高质量的信息资源需要流程设计人员对企业的业务数据，业务流 程等非常熟悉。还要判定企业中的信息是否在不同的经营单位、部门和 职能中可能发生变化。流程设计人员所起的作用就是确保特定流程实例 携带的信息不会被用户误解，产生难以预料的逻辑错误。 流程仿真测试：业务流程牵涉了大量用户与设备环境，把新完成的工作 流系统安装到现实环境中进行测试，是非常不切实际和低效率的。流程 设计人员需要准备测试用例，在模拟环境中直接仿真测试，及早发现问 题并解决，避免实施过程中会出现的损失。 2 2 4 系统管理人员 系统管理人员负责维护系统整体的运行，包括管理用户，权限资源库、监控 流程运行状况、管理系统只志、统计流程运行信息等管理功能。 管理用户，权限资源数据库：用户新注册时，需要系统管理人员的审核， 内容包括确认此用户是否合法用户、隶属于哪个部门、担任何种职务， 具有哪些技能等一系列相关信息，审核无误后，系统管理人员则将此用 户信息添加到用户，权限资源数据库中，除了用户所处角色的技能及资源 外，还将赋予用户所需的特定权限，使用户能够访问其它的技能及资源 的权限。 监控流程运行状况：系统运行期间， 程实例的运行状态及其上下文信息， 系统管理人员可以查询任意一个流 即其流程实例的执行过程，每步 的处理结果，涉及流程的用户信息，并对系统中恶意流程实例处理，例 如系统中设置了“客人”这角色供非正式用户来了解学习系统的使 用，但是如果在特定时间( 业务繁忙时) ，大量非正式用户登录并执行 特定流程，只会使系统负荷增加，降低系统稳定性，此时，系统管理人 员可以将“客人”角色临时禁止，将正在执行的客人流程取消。 管理系统日志：工作流系必须保存系统日志文件，作为系统异常诊断与 除错之用。对于某些在规定时间内依然没有得到处理的流程步奏，系统 也会将相关信息记录到系统日志中，系统管理人员必须定期对这些日志 进行分析，并对系统日志进行维护。 统计流程运行信息：工作流系统不仅仅只是为了将工作流程自动化，更 深的一层在于通过计算机的处理，流程运行的所有信息都可以被保存并 分析。对于企业，每个参加工作流程的员工都是有成本的，这些费用应 该被计算至项目成本或部门成本。而且，对于流程中每一步的处理也 都涉及到这一步的处理时间，流程执行者的效率等具有经济统计价值的 信息，通过专业化地分析，企业管理者能够宏观及微观的看到企业整个 运行的状况，并对不完善有缺陷的地方进行改进。 23 基于w e b 的工作流系统对系统平台的需求分析 可处理大量流程工作 最近的统计分析指出，对工作流管理系统软件最多的要求是安全性、稳定性 与支持大任务量处理。当流程中任一步骤完成时，便会反馈服务器，以决定下一 步骤，并且必须确保信息能正确传递给后续处理者( 或应用程序) 。当用户与流 程的数量增加后，工作处理的数量也是等比增加，因此对工作流服务器的要求会 较高。 稳定的信息传递架构 完善的工作流管理系统软件，必需提供可信赖、零风险的技术将重要的工 作流信息在不同系统组件之间传递。如果流程信息传递不稳定，则绝对无法适应 流量频繁的企业环境。很多所谓支持工作流的软件其实只提供了一套内部电子邮 件系统。虽然e m a i l 是很好的信息传递工具，但用来承载重要的企业流程信息， 则风险与可信赖度均值得怀疑。通用的可信度较高的方式包括：t c p i i p 、 c o m d c o m 、m i c r o s o f tm e s s a g eq u e u i n gs e r v i c e ( m m q s ) 、j a v am e s s a g e s e r v i c e ( j m s ) 等。 高可靠性 基于w e b 的工作流系统是一种特定形式的分布式系统，而分布式系统培重 要的特征之一是建立高可靠性的系统。一般说的可靠性是指错误容忍和错误恢复 两个特性。错误容忍是指在发生一定的错误，包括硬件错误、软件错误和网络错 误的情况下，系统对外仍然可以正常工作。错误容忍有两个等级，一个比较初步 的等级是发生错误时正在处理的请求将不能被正确处理，当然用户可以重发请 求，此外可能由另一个f 常的服务器处理完成。比较完善的等级是将这些处理了 一部分的请求转给其他服务器来继续处理，用户端感觉不到任何区别。 9 良好的可扩展性 企业工作流程本身就具有复杂多样的特点，而且，随着时间推移以及企业业 务范围的扩大企业工作流程会不断的增加，工作流管理系统的负荷加大，如果 系统本身不具有良好的可扩展性，系统处理效率将会不断下降，最终不可用。 支持l d a p 目录服务 企业信息系统的目录内储存了大量的使用者标识与存取权限资料，但如何维 护与同步更新这些资料，往往成为信息人员最头痛的问题。这也就是为何轻量级 目录访问协议( l d a p ：l i g h t w e i g h td i r e c t o r ya c c e s sp r o t o c 0 1 ) 能快速崛起成为 业界标准，且主要软件厂商都支持的主要原因。l d a p 提供了应用软件与不同目 录服务沟通的标准因为工作流程自动化需要大量的使用者信息，故支持l d a p 也成为一项必各的基本功能。 支持企业级数据库 工作流程软件必需支持目前企业最常用的商用数据库系统。例如：o r a c l e 、 m i c r o s o f ts q ls e r v e r 等。而m i c r o s o f t h c c e s s 则可作为开发与仿真模拟时的 小型数据库。而且，因为数据库处理往往是整个业务处理中最耗时的步骤。各种 数据库操作的步骤中数据库的连接和释放往往又特别耗时。服务器应当采用数 据库连接池的技术即在系统初起，或者初次使用时，完成数据库的连接，而后 不再释放此连接，而是在处理后面的请求时，反复使用这些已经建立的连接。这 种方式可以大大减少数据库的处理时间，有利于提高系统的整体性能。 2 4 为什么选择j 2 e e 平台? 基于以上的对平台的需求分析。我选择了现在非常流行的j 2 e e 平台。下面 对j 2 e e 做一个全面的概括，以解释选择选择此平台的原因。 2 4 1j 2 e e 的概念 j 2 e e 是一种利用j a v a2 平台来简化企业解决方案的开发、部署和管理相关 的复杂问题的体系结构。j 2 e e 技术的基础就是c o r ej a v a 平台或j a v a2 平台 的标准版j 2 e e 不仅巩固了标准版中的许多优点，例如“编写一次、随处运行” 的特性、方便存取数据库的j d b ca p i 、c o r b a 技术以及能够在i n t e r n e t 应用 中保护数据的安全模式等等，同时还提供了对e j b ( e n t e r p r i s ej a v a b e a n s ) 、 j a v as e r v l e t s a p i 、j s p ( j a v as e r v e rp a g e s ) 以及x m l 技术的全面支持。其 最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。 j 2 e e 体系结构提供中间层集成框架用来满足无需太多费用而又需要高可用 性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台ij 2 e e 降 低了丌发多层应用的费用和复杂性，同时提供对现有应用程序集成强有力支持， 完全支持e n t e r p r i s ej a v a b e a n s ，有良好的向导支持打包和部署应用，添加目 录支持，增强了安全机制，提高了性能。 1 0 2 4 2j 2 e e 的四层模型 j 2 e e 使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组 件根据他们所在的层分布在不同的机器上。事实上，s u n 设计j 2 e e 的初衷正是 为了解决两层模式( e l i e n t s e r v e r ) 的弊端，在传统模式中，客户端担当了过多 的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或 改进，可伸展性也不理想，而且经常基于某种专有的协议一一通常是某种数据库 协议。它使得重用业务逻辑和界面逻辑非常困难。现在j 2 e e 的多层企业级应用 模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每 种服务提供一个独立的层，以下是j 2 e e 典型的四层结构8 ： j 2 1 1 e j 2 腿 应用程序i 虚用程序2 圜圈 曰 囤固 客户一瓣 圈曰膦司 教据牟 厦务器 图2 ij 2 e e 四层结构 运行在客户端机器上的客户层组件 j 2 e e 应用程序可以是基于w e b 方式的，也可以是基于传统方式的。 运行在j 2 e e 服务器上的w e b 层组件 w e b 层组件j 2 e ew e b 层组件可以是j s f f 页面或s e r v l e t s ”。按照j 2 e e 规范， 静态的h t m l “页面和a p p l e l s ”不算是w e b 层组件。 正如下图所示的客户层那样，w e b 层可能包含某些j a v a b e a n ”对象来处理用 户输入，并把输入发送给运行在业务层上的e n t e r p r i s eb e a n “来进行处理。 b 嚣嬲 一 m 蚴 | e b 层 图2 2 w e b 层组件 运行在j 2 e e 服务器上的业务逻辑层组件 j 2 疆服务器 业务层代码的逻辑用来满足银行零售，金融等特殊商务领域的需要，由运 行在业务层上的e n t e r p r i s eb e a n 进行处理。下图表明了一个e n t e r p r i s eb e a n 是如何从客户端程序接收数据，进行处理( 如果必要的话) ，并发送到e i s 层储 存的，这个过程也可以逆向进行。 有三种企业级的b e a n ”：会话( s e s s i o n ) b e a n s ，实体( e n t i t y ) b e a n s ，和消 息驱动( m e s s a g e d r i y e n ) b e a n s 。会话b e a n 表示与客户端程序的临时交互。当 客户端程序执行完后，会话b e a n 和相关数据就会消失。相反，实体b e a n 表示 数据库的表中一行永久的记录。当客户端程序中止或服务器关闭时，就会有潜 在的服务保证实体b e a n 的数据得以保存。消息驱动b e a n 结合了会话b e a n 和 肺”的消息监听器的特性，允许一个业务层组件异步接收j m s 消息。 w e h 浏览器 b 页丽a p p l e 和可选的 j a v a b e a n 炎 应用程序客户端 和可造的 a v a b e a n 娄 韭务层b i g 层 j s p 页面 s e r v l e t z v a b e a n 类 ( 可选) e 晡b b 鹏 s b 墨b n b e a n w u _ 口e d f h n e k a f e 数据库 _ 和 旧有 j 2 e b 服务爨 图2 3 业务逻辑层组件 运行在e i s 服务器上的企业信息系统层软件 企业信息系统层处理企业信息系统软件包括企业基础建设系统( 例如：企业 资源计划( e r p ) ，大型机事务处理，数据库系统) 和其它的遗留信息系统。 ( 例如：j 2 e e 应用组件可能为了数据库连接需要访问企业信息系统) 。 2 4 3j 2 e e 的结构 这种基于组件，具有平台无关性的j 2 e e 结构使得j 2 e e 程序的编写十分简 单，因为业务逻辑被封装成可复用的组件，并且j 2 e e 服务器以容器的形式为所 有的组件类型提供后台服务。不需要自己开发这种服务，所以可以集中精力解 决手头的业务问题。 容器和服务 容器设置定制了j 2 e e 服务器所提供得内在支持，包括安全，事务管理， j n d i ( j a v an a m i n ga n dd i r e c t o r yi n t e r f a c e ) 寻址，远程连接等服务。以下列 出最重要的几种服务： a j 2 e e 安全”( s e c u r i t y ) 模型可毗让你配置w e b 组件或e n t e r p r i s eb e a n ， 这样只有被授权的用户才能访问系统资源。每一客户属于一个特别的角色， 而每个角色只允许激活特定的方法。你应在e n t e r p r i s eb e a n 的布置描述中 声明角色和可被激活的方法。由于这种声明性的方法，你不必编写加强安全 性的规则。 b j 2 e e 事务管理”( t r a n s a c t i o nm a n a g e m e n t ) 模型让你指定组成一个事 务中所有方法间的关系，这样一个事务中的所有方法被当成一个单一的单 元。当客户端激活一个e n t e r p r is eb e a n 中的方法，容器介入一管理事务。 因有容器管理事务，在e n t e r p r i s eb e a n 中不必对事务的边界进行编码。要 求控制分布式事务的代码会非常复杂。你只需在布置描述文件中声明 e n t e r p r i s eb e a n 的事务属性，而不用编写并调试复杂的代码。容器将读此 文件并为你处理此e n t e r p r i s eb e a n 的事务。 c j n d i 寻址”( j n d il o o k u p ) 服务向企业内的多重名字和目录服务提供了一 个统一的接口，这样应用程序组件可以访问名字和目录服务。 d j 2 e e 远程连接”( r e m o t ec l l e n tc o n n e c t i v i t y ) 模型管理客户端和 e n t e r p r i s eb e a n 间的低层交互。当一个e n t e r p r i s eb e a n 创建后，一个 客户端可以调用它的方法就象它和客户端位于同一虚拟机上一样。 e 生存周期管理2 1 ( l i f ec y c l em a n a g e m e n t ) 模型管理e n t e r p r i s eb e a n 的创建和移除，一个e n t e r p r i s eb e a n 在其生存周期中将会历经几种状态。 容器创建e n t e r p r i s eb e a n ，并在可用实例池与活动状态中移动他而最终 将其从容器中移除。即使可以调用e n t e r p r i s eb e a n 的c r e a t e 及r e m o v e 方 法，容器也将会在后台执行这些任务。 f 数据库连接池2 2 ( d a t a b a s ec o n n e c t i o np o o l i n g ) 模型是一个有价值的 资源。获取数据库连接是一项耗时的工作，而且连接数非常有限。，容器通过 管理连接池来缓和这些问题。e n t e r p r i s eb e a n 可从池中迅速获取连接。在 b e a n 释放连接之可为其他b e a n 使用。 容器类型 图2 4j 2 e e 容器 j 2 e e 应用组件可以安装部署到以下几种容器中去 a e j b 容器管理所有j 2 e e 应用程序中企业级b e a n 的执行。e n t e r p r i s e b e a n 和它们的容器运行在j 2 e e 服务器上。 b w e b 容器管理所有j 2 e e 应用程序中j s p 页面和s e r v l e t 组件的执行。 w e b 组件和它们的容器运行在j 2 e e 服务器上。 c 应用程序客户端容器管理所有j 2 e e 应用程序中应用程序客户端组件的执 行。应用程序客户端和它们的容器运行在j 2 e e 服务器上。 d a p p l e t 容器是运行在客户端机器上的w e b 浏览器和j a v a 插件的结合。 2 4 4j 2 e e 的优势2 3 j 2 e e 为搭建具有可伸缩性、灵活性、易维护性的商务系统提供了良好的机制。 a 保留现存的i t 资产：由于企业必须适应新的商业需求，利用已有的企业 信息系统方面的投资，而不是重新制定全盘方案就变得很重要。这样， 一个以渐进的( 而不是激进的全盘否定的) 方式建立在已有系统之上 的服务器端平台机制是企业所需求的。j z e e 架构可以充分利用用户原有 的投资，如一些公司使用的b e at u x e d o 、i b m c i c s ，i b me n c i n a ，、i n p r i s e v i s i b r o k e r 以及n e t s c a p ea p p l i c a t i o ns e r v e r 。这之所以成为可能是 因为j 2 e e 拥有广泛的业界支持和一些重要的企业计算领域供应商的 参与。每一个供应商都对现有的客户提供了不用废弃已有投资，进入可 移植的3 2 e e 领域的升级途径。由于基于j 2 e e 平台的产品几乎能够在任 何操作系统和硬件配置上运行，现有的操作系统和硬件也能被保留使用。 b 高效的开发：j 2 e e 允许公司把一些通用的、很繁琐的服务端任务交给中 间件供应商去完成。这样开发人员可以集中精力在如何创建商业逻辑上， 相应地缩短了开发时间。高级中间件供应商提供以下这些复杂的中间件 服务 状态管理服务一让开发人员写更少的代码，不用关心如何管理状 态这样能够更快地完成程序开发。 持续性服务让开发人员不用对数据访问逻辑进行编码就能编写 应用程序，能生成更轻巧与数据库无关的应用程序，这种应用程 序更易于开发与维护。 分布式共享数据对象c a c h e 服务一让开发人员编制高性能的系统， 极大提高整体部署的伸缩性。 c 支持异构环境：j 2 e e 能够开发部署在异构环境中的可移植程序。基于 j 2 e e 的应用程序不依赖任何特定操作系统、中间件、硬件。因此设计合 理的基于j 2 e e 的程序只需开发一次就可部署到各种平台。这在典型的异 构企业计算环境中是十分关键的。j 2 e e 标准也允许客户订购与j 2 e e 兼 容的第三方的现成的组件，把他们部署到异构环境中，节省了由自己制 订整个方案所需的费用。 d 可伸缩性：企业必须要选择一种服务器端平台，这种平台应能提供极佳 的可伸缩性去满足那些在他们系统上进行商业运作的大批新客户。基于 j 2 e e 平台的应用程序可被部署到各种操作系统上。例如可被部署到高端 u n i x 与大型机系统，这种系统单机可支持6 4 至2 5 6 个处理器。( 这是n t 服务器所望尘莫及的) j 2 e e 领域的供应商提供了更为广泛的负载平衡策 略。能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数 千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。 e 稳定的可用性：一个服务器端平台必须能全天候运转以满足企业客户、 合作伙伴的需要。因为i n t e r n e t 是全球化的、无处不在的，即使在夜间 按计划停机也可能造成严重损失。若是意外停机，那会有灾难性后果。 j 2 e e 部署到可靠的操作环境中，他们支持长期的可用性。一些j 2 e e 部 署在w i n d o w s 环境中，客户也可选择健壮性能更好的操作系统如s u n s o l a r i s 、i b m0 s 3 9 0 。最健壮的操作系统可达到9 9 9 9 9 的可用性或每 年只需5 分钟停机时间。这是实时性很强商业系统理想的选择。 2 5 小结 作为一个工作流管理系统，最主要的功能就是对流程的定义和执行。当然， 我们要设计的这个系统所能做的不仅仅是这些。本章对基于w 朗的工作流管理系 统所应该提供的功能，以及结合j 2 e e 平台的优势所能提供的功能作了一个详细的 分析，接下来的工作，主要是设计整个系统的架构，并对其中重要的组件在系统 中的作用、以及它们之间如何相互协作等问题，进行详细分析。 第三章基于w e b 的工作流管理系统设计 3 1 工作流模型 圈3 1 工作流模型 3 1 ，1 过程模型 过程模型用来定义工作流的过程逻辑，包括组成工作流的所有活动以及活动 之间的依赖关系。它是整个工作流模型的基础与核心，其他模型均为其提供支持。 在过程模型中，有以下两个关键概念： 模式块 工作流可以抽象地看作由一个个模式块所组成的链式顺序结构。每一个 模式块都具有输入，处理，输出的功能。模式块输入的是此模式块中节点执 行所需要的数据，工作流引擎根据输入的数据，路由到模式块中的节点，节 点处理具体的任务，直到模式块中的所有逻辑相关的节点全部结束完各自任 务，模式块输出的是此模式块是否完成的标示以及以后模式块需要输入的参 数，以供工作流引擎判断是否执行后继模式块，这些数据都在过程定义中设 置。模式块只是作为节点的逻辑容器，具体任务的执行依然在节点上处理。 模式块中最重要的属性为模式标识，前一模式块标识，后一模式块标识，输 入数据输出数据，当前处理节点标识，模式块状态。 a 模式块类型：参照第五章介绍的工作流模式，我们可以将大多数的企业 工作流程归纳到这些模式当中，在模式块中指明了此模式块是什么类型 的模式( 缺省是“顺序”模式) ，同时也就指示了工作流系统利用自带的 模式处理组件来处理此模式块。而各个模式所特有的逻辑处理过程已经 封装到组件中。 b 前一模式块标识：此标识指明了在此模式块之前的模式块。在回退的情 况下，可以将流程实例中当前执行模式块标识定位到前一模式块标识。 c 后一模式块标识：此标识指明了在此模式块之后的模式块。在此模式块 内所有逻辑相关节点都完成任务后，流程实例中当前执行模式块标识定 位到后一模式块标识。 d 输入输出数据：模式块的输入，输出数据是在过程类型定义时指定，除了 路由数据，还包括此流程实例公共数据集中的数据。模式块的执行，也 许需要前一模式块处理过的数据，整个流程实例的数据也有可能是相互 关联的。缺少了某一数据，也许后一模式块就不能够执行。 e 当前处理节点标识：一个过程实例运行过程中经常需要判定其运行至 哪一模式块，在此模式块中，系统又处理到哪些节点。这个标识指明的 也许不知是一个节点，也许有多个节点。节点当前的运行状态也就是系 统当前的运行状态。 模式块状态：模式块有着和节点一样的状态类型，但是其模式块状态由 模式块的类型及其中各当前处理节点的状态联合决定。模式块的状态被 系统用来判断是否应该将当前模式块标识指到下一模式块。 节点 节点代表了组成一个工作流的各种类型的活动与任务。是工作流过程模 型中的原子级组成部分。节点最重要的属性有节点类型、节点状态、节点条 件、需要被处理的数据。 a 节点类型 人工型活动：“人工型活动”是指需要人的参与来完成的工作任务，通 常由工作流执彳亍者从自己的工作项列表中来选择执行。当执行者完成 任务以后，通过w e b 页面进行提交，包括返回某些必要的活动处理结 果等。工作流管理系统并不负责此类活动的执行，而是密切监视活动的 状态，并管理由活动产生的工作流相关数据。 + 自动应用：“自动应用”是指不需要人的参与，直接由工作流管理系统 激活相关应用来执