]]>
Z么要收回Q?br />
参与者完成Q务后Q发现自己办理有错误{情况后Q需要将此Q务收回重新办理?br />
工作的参与方式
目前有四U方式：共同参与、竞争参与、顺序参与、基于角色的共同参与?br />
下面会针对这四种方式q行讨论?br />
工作Ҏ回模?br />
1、未触发下一节点的工作项的收?br /> 卛_前Q务节点ƈ未完成，依旧处于执行状?br />
1.1共同参与
如图Q在节点A未结束之前，workitem1、workitem2和workitem3正常完成后可以Q意收回。在只生一个workitem的情况下Q不存在未触发下一节点的收回情c?br />
1.2序参与
如图Qworkitem1、workitem2和workitem3序完成Qworkitem1在workitem2{收Q包括挂起和手工l止Q前可以收回Q同Pworkitem2在workitem3{收Q包括挂起和手工l止Q前也可以收回。在只生一个workitem的情况下Q不存在未触发下一节点的收回情c?br />
1.3竞争参与
因ؓ只会产生一个workitemQ该workitem完成后会立刻触发下一节点Q所以不存在未触发下一节点的收回情c?br />
1.4Z角色的共同参?br />
?.1相同?br />
2、已触发下一节点的工作项的收?br />
2.1共同参与
问题1Q多个工作项时谁可以执行收回操作Q?br /> workitem1、workitem2和workitem3都可以执行收回操作。第一个工作项的收回将会导致节点B实例的删除，同时节点A重新恢复执行状态?br />
问题2Q节点B处于什么状态节点A的工作项可以执行收回操作Q?br /> 由A触发的节点B处于正在执行的状态，节点B所产生的工作项Q?br /> a共同参与 工作均未签收、挂h手工l止
b序参与 W一个工作项未签收、挂h手工l止
c 竞争参与 工作均未签收、挂h手工l止
d角色
同共同参?br />
问题3Q工作项收回产生的媄响？
节点A重新执行Q收回的工作w新执行。节点B重新恢复未触发状态，B所产生的工作项全部删除?br />
2.2序参与
问题1Q多个工作项时谁可以执行收回操作Q?br /> workitem1、workitem2和workitem3Ҏ序可以依次执行收回操作?br />
2.3竞争参与
情况单，只有一个工作项Q所以可以直接收回?br />
2.4Z角色的共同参?br /> ?.1
工作收回模?br /> 后箋触发节点只能是h工节点（可以是多个，臛_一个）Q否则不支持收回。目前不支持父子程之间的收回?br /> 一个典型的同步汇聚情况Q?br />
节点1首先执行完毕Q但是因为是同步汇聚Q所以它不会触发实际的流转；而节?的完成则会触发节?的执行。在q种情况下，节点2的工作项可以执行收回操作Q而节?的工作项因ؓ后箋没有触发节点而不能收回?/div>
]]>
在谈?BPM 相关标准之后Q这ơ我惌读者谈 BPMS 的架构、组成模块及其各自功能，让读者有全盘性的了解Q希望能破除一般h?BPMS 的迷思?
关于 BPM Q业界有些迷思。例如，常听到有 BPM = EAI + Workflow Q?PBMS 只不q?Workflow 厂商的旧瓶新酒，换汤不换药，只要原来 WfMS 加上pȝ整合?Adaptors 变?BPMS Q或?EAI 厂商加上 Activity Modeling 的工h者是 Routing Engine 重新包装一下，也可以称?BPMS ?br /> 我认?BPMS 不只是如此，而是一个生命周期。顺着 BPM 生命周期了解用户的操作场?(Scenario) Q是理解 BPMS 的组成全貌最好且最直觉的方式。在本文中，我首先介l完?BPM 生命周期Qƈ从其中的每一步骤接着介绍工作内容、用到的工具及其功能、与用户的角艌Ӏ最后，我会以一张完整的 BPMS 架构图，详细介绍其中l成的模块功能?
BPM Q也要谈生命周期 (Life Cycle)
BPMS 让企业可以灵敏反应外部环境的变动q快速变动企业内部的程作业Q所以生命周期所的是持箋性改善与周而复始的循环?BPM 生命周期另一个含意就是，它是 BPMS 工具导入的方法论 (Methodology) ?BPMS 解决Ҏ最重要的核心就是方法论Q它臛_要包含思考哲?(Philosophy) 、方?/ 步骤 (Methods / Steps ) 、与伴随的工?(Tools/Utilities) 。因为没有Q何两家的程Q组l，{略目标是全然一LQ因此怎样才能从策略目标规划到最后系l导入执行连贯一体，成功而有效地完成建置所依赖的才是合适的Ҏ论?
目前各家 BPM 厂商所提出的生命周期不相同，乃是因ؓ解决Ҏ所面对的业或应用领域不同Q所以有了各自强调与专注的重炏V例如， IBM HoloSofx 提出的是Q徏?(Create) 、管?(Manage) 、自?(Automate) 、协?(Collaborate) Q?Howard Smith & Peter Fingar ??BPM - The Third Wave 』一书所提出的是Q徏?(Model) 、布|?(Deploy) 、与理 (Manage) Q?Italio 提出的是发掘 (Discovery) 、徏?(Modeling) 、支?(Supporting) ?Monitoring ( 监控 ) 、及 Improvement ( 改善 ) 。在此我会提为完整的程步骤Q但不见得每?BPM 厂商的都W合Q读者可参考下图－ BPM 生命周期?
图一?BPM 生命周期
·阶段一?程发掘 (Discovery) :
要导?BPM W一步骤当然要先清楚知道现行程的作业方式与状况Q尤其是程内的信息?(Message flow) 、事件流 (Event flow) 、或控制?(Control flow) 。哪些流E可以自动化Q哪些是人工程Q有哪些人参与？程是在l织内部或外部被执行Q?BPMS 在此步骤的主要特征是如何 自动扑ևpȝ的商业逻辑 。通常企业会聘请外部顾问师或领域专家来协助辅导Q这个动作有人称?程评估 (BPA, Business Process Assessment) Q评估范围可能涵盖策略与理目标与流E的q结。同时企业也会配合导入一些管理的主题而作 程再?(BPR, Business Process Reengineering) Q例如评分计分卡 (BSC, Balance Score Card) 、六个标准差 (Six Sigma) 、或 ISO 9000 品质理pȝ?
· 阶段二?程设计 (Design) Q?/strong>
此阶D|一个包含四几个步骤的反复式的小循环 (Iterative mini-cycle) Q徏?(Modeling) ?( 分析 Analyzing) 、模?(Simulation) 、重?(Redesigning) 程。如前所qͼ面对外部的竞争压力与商机Qؓ了让企业可以快速重构流E， 因此一些细致的程变革 (Fine-grained process change) 只需利用此阶D늚步骤p作出实时的反应?br /> 程 建模 所q用的工L?Process Designer 通常包含三个模块Q组l?(Organization Chart) 、流E图 (Activity Diagram) 、与H体 (e-Form) 设计工具。它们分别对应流E中三个最重要的元素：人、活动与文g ( 有兴的读者可参阅 Process Modeling Conceptual Framework 有关的资料，后箋Ҏ在适当Z再做介绍 ) 。徏模之后可以作执行动作前的 分析与仿?来验证设计的程是否正确合适或最佛_Q此外它能还提供现行程可能遇到的瓶颈信息，以避免执行后才发现问题进而导致很大的营运损失。如果分析模拟出来的l果q不满意Q可以反?重构 程直到产出满意的结果。分析指的是从流E定义的语意与理Z的推论分析，仿真则可讑֮机率变量与行为假设让pȝ自动跑出期望值或变异差数据，有些则仅提供自动执行 (Animation) 或手动逐步执行以观流E行为?
此阶D?BPMS 的主要特征是 囑Ş化的接口 Q让?IT 背景的用户可藉由拖曳方式也能Ll装或分解流E；此外q用程资 (Process assets) 的观念，让流E定义隐含业界的最佛_?(Best practices) 或流E样?(Process Pattern) Qƈ且储存于程仓储 (Process Repository) 以供随时再利?(reuse) ?
· 阶段三、流E执?(Execution) Q?
意指CU的程能被参与者顺利执行完成。负责控制执行的模块可称为工作流E引?(Workflow Engine) 或流E服务器 (Process Server) 。在此阶D?BPMS 主要的诉求是分布式交?(Distributed transaction) 的管理，因ؓq些交易可能是复杂度高的跨l状流E?(Nested process) 而且交织着新旧pȝQ甚臛_既有的应用系l当成流E组件来执行。至于流E的执行者通常多是应用pȝQ可以不用h的参?(human intervention) 而自动执行，也就是一般所U?程自动?(BPA, Business Process Automation) ?
此外Q排E工?(Scheduler) 可以应用来设定自动启动流E的旉与周期频率。有?BPMS 的品会提供规则引擎 (Rule Engine) 来负责商业规则判别与推理。此阶段另一个重要的特点是在不用技术h员的参与下，依然可以让流E用戯行编辑与修改商业逻辑。例如，代理人的指派规则通常相当复杂Q背后就需要有 Rule-based 的机制来支持?
程布v (Deployment) Q?/strong>意指设计好的流E推ZU让所有参与?(Participant Q可能是人，应用pȝQ或其它程 ) 来执行。这个步骤的主要特征是能以最的力气H?effort H达成运资?(Computing Resource) 与组lh员的l合 (binding) Q如事先整合应用pȝlg (Application components) ?
与h互动 (Interaction) Q?/strong>在流E的执行中很重要的就是与人的互动。ƈ非所有流E都可以自动化，所?BPMS 让h能管理自动流E与人工程之间的接口。负责与Z动的接口UCؓ工作目的处理程?(Workitem Handler) 。有时候流E接口本w也是一个流E，例如动态加会签或在H体输入下一步流E的分派。过?Workitem Handler 相当单，然而现在有們丰富化与l致化的势。必要的时候还能让用户客制化或整合在不同系l的接口中。由于这个需求有快速提升的势Q所以各家厂商纷UhZ富且个h化的程入口|站 (Personalized process Portal) ?
W四阶段、管理维?(Administration) Q?/strong>
当流E上U后伴随产生了管理维护的问题Q如例外状况的介入处理、组lh员的变更、流E重新分z、或程版本升的媄响。在此，有个重要的模块称作流E活动监?(BAM, Business Activity Monitoring) Q它可以随时回报程的执行状态与q程Q而且用户也可以设定流E要q踪的关卡ƈd回报Q具有预警功能ƈ能随时掌握问题处理的时效。另外服务器的流量与执行监控及流E仓储的数据l护的效能也相当重要?
W五阶段、流E最佛_ (Optimization) Q?/strong>
程改善 (Improvement) 是个持箋性的zdQ不断反复朝向最佛_q进。流E测?(Measurement) 能提供流E的执行l效 (Performance) Q?BPMS 的报表工?(Reporting Tools) 能让企业对自ql织行ؓ充分了解作ؓ持箋改善的依据，如此方能{划出改善与最佛_的策略。流E分?/ 仿真着重在执行前的分析Q例如自动侦瓶?(bottleneck) 、死l?(deadlock) 与流E定义的不一?(Consistence) Q而流E测量则是执行后实际资料的分析，可以清楚知道程消耗时间与资源。这个阶D跟商业智慧 (BI, Business Intelligence) 的技术与主题怼性很高的Q差异在 BPMS 可以自动U录与收集流E相关的数据。尤?BPMS 所附含的流EW效A表版 (Dashboard) Q它提供一个全面式的概观让ȝ单掌握且一目了然哪些流E是在标准差内，哪些是在失控状态。当然这些报表，都是用户可以自行定义或查询的Q不?IT 人员的参与?
BPM Q?Workflow +EAI
怿从上q的介绍Q读者可以清楚认识到 BPM l对大于 Workflow ?EAI ?BPM 的主要精在于企业流E的理Q且主要的焦点在于业务性用?(business users) 而非技术性用?(technical users) Q在于流E弹性实时调整而非数据与应用系l的整合。所以仅是工作流E自动化加上 EAI 企业应用软g的{换机制是不以的늛企业理程中所有必要的环节。例如尚有让理ȝ能实时掌握流E成本效?(cost/effective) 评量与流EW?(Performance) 理Q业务性用户可以轻易调整组装流E以提供客户最佳业务服务，{等?
我将上述中的工具整合hQ架构如图二所qͼ
BPMS pȝ架构 (System Architecture)
图二?BPMS pȝ架构?
一个完整的 BPMS pȝ需由流E设计环?(Process Design Environment) 、流E仓储或储存?(Process Repository) 、流E服务器 (Process Server) 、用h行环?(User Execution Environment) {主要元素所架构而成?
· 程设计环境 (Process Design Environment)
程设计环境扮演着程设计阶段中最重要的流E徏模工作，通常包含了「组l图?(Organization chart) 、「电子化H体?(e-form) 、活动图 (Activity Diagram) 、与商业规则 (Business Rule) {相兛_素，q可透过直觉囑Ş化的接口Q协助流E设计者进行企业流E的建构?
l织N份大多与l织目录服务pȝ (Directory system) 相结合，以协助企业进行组l的调整与管理，如支?LDAP ?AD {相关目录服务。而电子窗体指的是信息呈现的接口，一般而言可将应用pȝ的数据与程相关的数据，透过所谓的电子H体来展玎ͼ便于处理与h互动的部分，而呈现的方式可透过特定的工具快速的订制。在了解程整体q作与规划中Q透过zd囑֏清楚地规划与了解程中的各个zd彼此的先后顺序与兌Qƈ订定程的运作条件与事g触发的相兛_作，再透过l合商业逻辑Q?Business Rule Q的方式Q让企业更清楚流E的q作方式且易于修改，在采购流E中Q若采购金额大于 100,000 台币者需{核臛_理，其余仅需{至l理Q就是个明显的例子?
程仿真Q?Simulator Q与程设计分析Q?Analyzer Q，则是透过程数据的仿真得以事先验证流E执行时的结果与程设计兌的分析（如在复杂的流E中Q重要的程元素或关联未建立Q，辑ֈ程执行前事先的预防Qƈ认设计的流E是否正合适或最佛_?
· 程数据储存?(Process Repository)
程仓储包含了流E定?(Process Definition) 、流E执行纪?(Execution Log) 、与应用数据 (Application Data) 。流E定义包括了程q作所有相关的数据Q最明显的就是流E三要素Qh、活动与文gQ都U录在流E定义中Q藉由流E的规则引擎 (Rule Engine) 的参数即数据的变异数或是各个节点所制定的活动时间限制等定出合适的程定义Q最后透过程服务器执行定义好的流E；程执行U录指的是流E执行过E中所有的U录Q有?BPMS 此部䆾内徏于系l中Q有的则是需另行所需U录抄写到数据库中；应用数据则是指在程执行的过E中Q所使用到其它系l的相关数据q着程U录下来或有所兌Q如请采购流E执行中Q需依照既有 ERP pȝ的相x据进行逻辑判断Q甚至需其抄写xE窗体中。而在此所指的应用性数据ƈ没有只局限在内部数据库，也包含了Ҏ程的定义向l织外可能以 web service 的方式呼叫外部数据来应用?
· 程引擎 / 服务?(Process Engine/Server)
程引擎是整?BPMS 中最重要的一环，它负责正无误地流E在正确的时间传送给正确的h或系l，而由于流E的q作Z业营q的核心Q因此能处理复杂且大量的程工作是流E引擎所必备的条件。分布式交易 (Distributed transaction) 的管理与负蝲qQ?Load Balancing Q将是考量的重炏V?
· 用户执行环境 (User Execution Environment )
q边所说的用户环境指的是用户与流E沟通的接口。一般简易的用户接口多藉由待办事（ Work lists Q让用户使用程工作。而由于企业入口网站的风行Q一个面面俱到的 BPM 产品通常透过 Web-based 接口Qƈ加入口网站（ Portal Q的概念Q提供所谓的程入口|站接口Q?Process Portal Q作为用户用流E的沟通接口。如此除了可清楚地看到透过程引擎指派而生的的各Q务或工作事项 (work items) 外，q可l合其它入口|站与应用系l整合的机制Q如使用协同工作功能促进员工彼此沟通与交流Q像是公布栏、行事历或讨论区{。另外也可透过待办事项的启?(trigger) 能够呼叫 (invoke) 与之相关的应用程?(applications) 甚至Ҏ各清楚定义的个别兛_ (activity) 自动?web service 的方式来跨组l地呼叫 (invoke) 外部数据作交?(transaction) 辑ֈ名副其实?SOA 技术架构概c?
此外藉由程|站接口用户 ( 通常指中阶以上主或部门ȝ ) 可利用行政管理工?(Administrator Tools) 与报表工?(Reporting Tool) 。就行政理工具来说Q进入流E数据储存库捞取程定义的信息所作出的制式化报表可以清楚的知道员工的工作负荷量的轻重E度Q而各U的l计量表包含热门排行、单位时间工作量l计、单位工作量l计、部门工作量l计、流E工作量l计、项目工作量l计提供理者用，使管理h员随时了解企业流E运作的各种情况。用户也能以 web service 的方式捞取应用数据作出动态分析。而流E的监控与管?(Activity Monitor) Q亦可让用户或管理者透过 Web 的方式，实时地追t目前流E的q度或进行例外的处理以能做到修正或变动的因应。也是说活动的监控ҎE范例的执行提供了一个W效量的准则。最后透过上述工具使流E作到实时的修正辑ֈ最佛_让工作更有效率?br />
]]>
在部|上Q嵌入式工作引擎是不能单独q行的，它是以一个Y件组Ӟ或者说构gQ的形式q行在用它的业务应用中。因为工作流技术主要是解决复杂业务程灉|定制和方便更改的问题Q因此在应用逻辑层次上，我们可以把嵌入式工作引擎看作是业务逻辑层的一部分?br /> 在与业务应用的交互方式上Q嵌入式工作引擎通过提供WAPIQWorkflow APIQؓ展现层或业务逻辑层的其他部分提供服务Q如启动指定工作程、查询工作Q务、设|流E运行业务数据）。另一斚wQ工作流引擎l常需要业务相关的数据或逻辑来决定流E流转，或者需要在不同d之间传递业务数据，q时候，程引擎会调用业务应用中业务逻辑或数据访问模块提供的API接口来完成相应操作?br /> 独立q行工作引?/strong>
独立q行工作引擎本w就是一个单独的应用。作为服务应用如果又没有Z某个中间件技术的话，独立q行工作引擎必自己实现多U程同步、网路通讯处理、资源池{服务端技术，因此实现的成本高、技术复杂?br /> 在与业务应用的交互方式上Q独立运行工作流引擎会以q过E调用的方式提供WAPIQWorkflow APIQ。对于用Java技术的独立q行工作引擎，q过E调用方式可以是RMI、JMSQ或者能够跨异构系l的Web Service?br /> 另外Q独立运行工作流引擎也必Mؓ反过来如何调用业务应用提供解军_法。一般情况下Q独立运行工作流引擎应该能够直接调用外部业务应用提供的远E接口（如基于RMI、JMS或者Web Service的业务接口）Q另一斚wQ业务应用也必须为独立运行工作流引擎提供q过E调用业务方法?br /> 当然也有省事而走捷径的方法，比如国内市场占有率比较高的一ƾJava独立q行工作品，虽然提供了基于RMI/JMS的WAPIQ却没有提供工作引擎直接调用外部业务远E接口的Ҏ。如果要让工作流引擎调用外部业务逻辑Q你必须~写一个实现厂商特有接口的Javac，然后它上传q注册到工作引擎中?br />
像上图这U方式是可以解决实际业务问题Q你自己~写的javacd以做M事情Q比如远E调用或者访问数据库Q。但很明显，本来很多不该二次开发做的工作现在必d二次开发时做了。同Ӟ业务应用逻辑分散在多个应用（你的应用和工作流引擎Q中q且某些业务应用逻辑Q上传到引擎的Javac）反过来要依赖厂家的接口，q些都是良好的架构设计要避免的情c一旦系l后期要做一些变动就会带来很大麻烦?br /> Ҏ
下面我们部|Ӏ二ơ开发的难易E度、性能、是否支持分布和EAIQ对q两cd作流引擎做一个对比?br /> 1、部|? 对于一个基于Java技术的嵌入式工作流引擎Q在部v旉常简单，你只要将对应的jar文g加到classpath中就可以了。独立运行工作流引擎因ؓ是独立的应用Qƈ且必通过RMI/JMS/Web service{远E调用技术与业务应用交互Q所以部|v来要ȝ得多Q?br /> 2、二ơ开? ׃大部分独立运行工作流引擎也会在客LQ提供方便远E调用的本地调用APIQ所以在二次开发时Q程序员大部分时间都可以不大x引擎是本地的q是q程的。但在传递某些业务参数和例外处理中，q程调用q是有些Ҏ的要求和限制的。因此ȝ来说Q在二次开发上独立q行工作引擎对E序员要求高一些；
3、性能Q毫无疑问，因ؓ没有q过E调用，嵌入式工作流引擎要占明显优势Q?br /> 4、分布和EAIQ独立运行工作流引擎能够和多个业务系l打交道Q嵌入式工作不能直接和宿主pȝ以外的系l交互。因此只有独立运行工作流引擎支持分布式应用，和支持通过业务程做企业应用集成（EAIQ?br /> 如何选择
通过上面的对比已l很清楚了。如果你需要工作流E在多个pȝ中流转，那么选择独立q行工作引擎。在其他情况下，选择嵌入式工作流引擎?br /> 同时Q即使你因ؓ分布或EAI而准备选择独立q行工作引擎，你也应当选择在业务与引擎两个调用方向上，都直接支持远q程调用的工作流产品。如果独立运行工作流引擎在某个调用方向上Q比如回调业务应用）没有提供ҎQ需要用户在二次开发时自己解决Q这U情况下请选择嵌入式工作流引擎?br /> 发展方向
一般国内独立运行工作流产品历史会比较长Q大部分是在7-8q前开始立开发的Q那时候正是分布式应用理论最火热的时候。可随着Z在实践中的经验教训和U篏Q发现很多情况下我们不需要复杂的分布式应用。这也是q几q来在Java世界里，许多人提?#8220;轻量U?#8221;?#8220;no-EJB”的原因?br /> 事实上，嵌入式工作流引擎l过一定的扩展也能够处理跨pȝ的流E交互：
在上图中Q新的嵌入式工作引擎通过附加工具能够为外部业务接口（不管是RIM/JMS/Web ServiceQ自动生成适配器（AdapterQ供引擎使用Q另外引擎会对外提供q程WAPIQ包括客L适配器）。具备了q程交互能力的嵌入式引擎仍然可以作ؓlg在主要的业务应用中用，从而得大部分业务逻辑和引擎之间的交互为本地调用，不会造成性能的损失?br /> 国际著名工作专家Michael zur Muehlen 在其 “Workflow-based Process Controlling”一书中谈到Q?#8220;在上个世U?0-90q代Q大部分工作应用采用第一U应用方式（独立Q。现在，对于包含复杂程的应用系l，许多软g提供商重新定位和设计它们的工作流产品Q其成为应用系l的构g模块Q即嵌入式）”。你的看法呢Q?/div>
]]>
首先了解一下信息技术演化的q程是有助于我们地更好的了解业务程理pȝ的相关知识。从?中，我们可以看到当今信息pȝ发展的趋势[3]。该图表明当今的信息pȝ包含了几个层。中心层是直接和g打交道d操作pȝQ第二层是通用的应用程序，q些应用E序在企业中有广泛用，比如Microsoft OfficeQ第三层是ؓ某些特定领域所开发的软gQ这些Y件局限于专业的企业或者部门内部用，比如人力资源理pȝQCall Centerpȝ{；W四层是专业定制软gQ这些Y件仅仅ؓ特定的公司组l开发，通用性较，专业化程度很高?
? 信息pȝ技术演化趋?
在二十世U六十年代，信息pȝ中不包含W二层和W三层。信息系l徏立在一个小型的操作pȝ上，仅仅有特别局限的功能。因为那时没有通用软g也没有行业专用YӞ当时的信息系l仅仅包含专业定制Y件。从那时开始，W二层和W三层Y仉渐发展hQ此外第四层软g的种c逐渐增多Q同时增加了更多的功能。当今，操作pȝ更加强大Q存在于W二层的数据库管理系lؓW四层Y件的发展提供了更多的功能上的支持。这U趋势导_软g的发展的重点由单U的~程转向以组件的形式l成更加复杂的系l。当前对软g供应商的挑战不再是某一模块的代码编E，而是把第四层软g的功能协调整合在一赗?
另外一个趋势是软g发展的重点从数据处理转向程理。二十世U?0q代?0q代QY件主要以数据驱动的应用程序ؓ丅R信息技术的重点存储和提取信息数据，因此数据建模是当时徏立一个信息系l首先要做的工作。业务流E徏模经常被忽视Qƈ且流E经常要适应当时的信息技术。管理趋势，如业务流E重l，则越来越重视程理。因此，pȝ工程师们开始{向基于流E的pȝ得开发方法的研究?
最后一个趋势是事前详细设计转向q程重设计及lg重组。由于Internet的发展，信息pȝ发生了巨大的变化Q越来越的信息pȝ是从零开始徏造。在很多案例中，我们可以看到很多应用E序中的某些lg和功能被UL到新的系l中。尽基于组件的软g开发方式仍然存在一些问题，但是我们可以看到软g的开发方式变得越来越多样化、更加动态化?
业务程理pȝ或是存在于第二层独立的YӞ或是集成在第三层软g中的lg。存在与W二层体pM的业务流E管理系l的例子是工作流理[11Q?2Q?3Q?4Q?5]Q比如StaffWareQMQSeriesQ和COSA。在d的ERPpȝQ第三层Q中Q工作流理l常作ؓ一个组件出现。SAP、Baan、PeopleSoft、Oracle的工作流引擎可以看作是集成的业务程理pȝ。将业务程理分离出来作ؓ一个独立的lg的想法和W三UY件发展趋势相d。业务流E管理系l避免将工作程编入专业Y件的J杂工作Q同时提供了对从编E到重组lg的支持。比如，C的工作流理pȝ可以用来集成到已l存在的软g中去Q支持当业务程改变的时候，只需要更改工作流E图Q而不必重新编E。将业务程理作ؓ一个独立的lg的想法也和Web Service的创意一_Web Service语言Q比如，BPEL4WSQBPMLQWSCIQXLANG和WSFL可以被用于从使用WSDL定义的系l中提取出服务?
从科学的观点来看Q上q观Ҏ在早期的办公信息pȝ中即有体现。在二十世纪70q代QSkip Ellis[16], Anatol Holt[23], Michael Zisman[18]已经开始了研究所谓的办公信息pȝ的工作，q种pȝ以流E模型ؓ驱动。这三位先驱都是利用Petri|ؓ工具对办公流E徏模的?0世纪70q代?0q代之间Q是发展办公信息pȝ的大好时机，不幸的是Q很真正的软g成功开发出来。因此，该技术和软g的研I几乎停滞了十年之久Q结果是Q在80q代几乎毫无q展。在20世纪90q代Q研I界重新对该领域产生了浓厚的兴趣Q一些工作流理pȝ?0q代的后五年中开发出来，q且学者们发表了大量关于工作流技术的论文。现今，工作管理系l基本有了雏形[13]。然而，q些软g仅仅局限于特定的领域，比如银行业和保险业。就像Skip Ellis指出的，从上q的盛衰沉Q的发展进E中学习到宝늚l验是非帔R要的[24]。在80q代的失败可以归咎于技术和理论的不成熟。当Ӟ|络不发达或者某些地区根本不存在Q没有合适的囑Ş界面Qƈ且没有合适的开发工兗然而，最Ҏ的问题在于，没有l一的流E徏模模型，q且那些pȝ太过于刚性，以至于不能h们不能真正将之应用到实践中。上q大多数技术问题现今已l解冻I然而概念上的问题依旧存在：没有l一的业务流E徏模标准，以及当今的工作流理pȝ在过E逻辑上增加了许多不必要的限制Q比如流E大多被订制成顺序执行?
1Q业务流E管理的需求与产生的背?/strong>
业务程(也叫做经营流E?是ؓ了实C定的l营目的而执行的一pd逻辑相关的活动的集合Q业务流E的输出是满_场需要的产品或服务。根据功能、管理范围等的不同，企业的流E管理一般分为生产流E层、运作层、计划层和战略层四个层次[3]。表1对各个层ơ做了比较?
? 程理的四个层?/p>
程理的各层次均有相对独立的、特定的ҎQ但层次之间也有着密切的联pR首先，高层的管理目标最l要通过低层的业务活动来实现Q其ơ，当低层的理解决不了实际问题Ӟ需要引入高层的理Q例如当q作层的调度无法解决资源的配|问题时Q就说明分配l该程的资源数目需要修改，此时需要引入计划层的管理，重新q行资源能力计划的计；最后，低层的数据ؓ高层的管理决{提供依据，企业的策略管理和战略理中的模型和参数来自对企业实际l营zdl计数据的积累。因此，从整个企业流E管理的角度来看Q有必要这四个层面上的程理l一C个框架下Qƈ和企业的信息pȝ联系h?
从企业信息系l的角度来看Q办公自动化pȝ、事务处理系l和决策支持pȝ{都是常见的企业信息pȝQ但q些pȝq没有加入流E的因素Q只是用来帮助员工更好地完成某些特定的Q务。工作流pȝ的出C得整个流E的自动{或自动执行成为可能，但是工作一般只解决生程层的问题Q与企业的计划和战略决策q存在一定的p。另外，随着企业业务程向企业外?供应商和客户)延Q传l的工作系l无力解册企业的流E集成问题。基于以上原因，面向企业的业务流E管理解x案由此应q而生?
业务程是把一个或多个输入转化为对֮有h值的输出的活动。简而言之，业务程是以涉及为顾客提供品或服务为最l目标的l织zd的集合。一个典型的业务程应该包括下面六大要素Q流E目的（它存在的理由Q；输入资源Q按一定秩序执行的zdQ这些活动之间的l构Q相互关pd作用Q；输出l果Q该程创造的价倹{?
一家企业成功的基础Q就是通过业务程协调各种资源来达成企业目标。无论是向顾客交付品，与合作伙伴协同，q是引导员工的努力，业务程能够企业的产品、品牌和价值有机地~织CP例如下面q些业务zd都是业务程Q根据生产所需Q安排原材料的检验、入库和供应Q回{客L咨询Q从供应商那里采购；向市场投放新产品。事实上Q业务流E集成了企业内各U业务的特征Q业务流E也因此成ؓ企业q作Ҏ的核心?
2QBPM和BPMS的基本概?br> 2.1 BPM的基本概?br> 业务程理QBusiness Process Management, BPMQ不是一个新概念Q甚至不是一个新名词。它是从相关的业务流E变革领域，如业务流E改q（BPIQ、业务流E重l（BPRQ、业务流E革C发展h的。流E管理技术也是从早期的工作流理、EAI、流E自动化、流E集成、流E徏模、流E优化等技术中发展h的?
很多Z务流E管理（Business Process Management BPMQ是90q代工作管理系l的扩展。因此，我们使用工作的术语来定义BPM。工作流理联盟QWfMCQ定义工作流为：“工作是一c能够完全或者部分自动执行的l营q程Q它Ҏ一pdq程规则、文档、信息或d能够在不同的执行者之间进行传递与执行?#8221;[13]。工作流理pȝQWFMSQ的定义是：“工作管理系l是一个Y件系l，它完成工作流的定义和理Qƈ按照在计机中预先定义好的工作流逻辑推进工作实例的执行?#8221;[13]。上qC个定义的重点都在于工作流的执行，也就是用Y件支持操作流E的执行。在q去的几十年里，很多研究学者开始意识到仅仅把重Ҏ在工作流执行上过于局限，于是新的术语BPM诞生了。现今存在很多BPM的定义，但是从中我们可以看到大多数定义都包含了工作流理的内宏V?
从管理理论或战略的层面看Q业务流E管理（BPMQ就是在一个存在内部事件和外部事g的环境中Q由一l相互依赖的业务程出发Q对业务q行描述、理解、表C、组l和l护。从具体实施的层面看QBPM q可分ؓ程分析、流E定义与重定义、资源分配、时间安排、流E管理、流E质量与效率评、流E优化等?
Gartner IncQ给出的BPM 的定义[17]是：BPM是一个描qCl服务和工具的一般名词，q些服务和工具ؓ昑ּ的流E管?如流E的分析、定义、执行、监视和理)提供支持?
? BPM和WFM的生命周?/p>
?表明WFM和BPM生命周期上的联系。在设计阶段Q业务流E被定义或者是重新定义Q在配置阶段Q定义的程在基于流E的信息pȝ中实施；在实施阶D，业务程开始利用在配置阶段的内容开始实施；在诊断阶D，pȝ开始分析业务流E以发现其中的问题和需要改q的地方Q在程设计阶段重新定义Q往q@环不断地优化业务程。相Ҏ而言Q传l的WFM的重点仅仅存在于BPM的下半部分。所以WFM在诊断阶D基本上没有什么支持。此外，WFM对于设计阶段的支持很，仅仅提供了一个编辑器Q而对实时的设计分析没有支持。因此，几乎没有WFM支持程设计的仿真，验证Q确认以及对实时数据的收集、解释。从理论上说Q可以从工作日志中可以挖掘业务程Q然而现今没有Y件能够真正做到这一炏V?
从图2中我们也可以很清晰地看到BPM的研I范围以及BPM和工作管理（WFMQ的在其他方面的区别和联p[1]?
1Q从产生的背景来看，工作的概念h于生产组l和文档自动化领域，它十分强调Q务和文档的概c而BPM 是在EAI、工作流和BPR{一pd技术或理念的基上发展v来的QBPM 中流E的概念已经出了Q务的集合q一范畴?
2Q从对业务流E的理来看Q工作流侧重于业务流E的自动化。从WFMCl出的工作流的概念中可以看出Q工作流业务程的自动或部分自动的执行。自动化是业务流E管理很重要的部分，但不是全部。从q个意义上说Q工作流ҎE的理应该处于?所C的q作理和部分计划管理层面。而BPM 是业务流E管理的整体解决ҎQ它늛了业务流E的建模、运行、监控、分析等多个斚wQ以及从生理到战略管理的各个层次?
3Q从对业务流E类型的理解来看Q工作流侧重于管理结构化的流E，q些程从一个参与者流转到另一个参与者。工作流在银行、保险、税务等领域应用比较q泛Q其原因是q些领域的流E往往十分l构化。而BPM ҎE的q行、协同和分布的支持能力更强?
CQ很多工作流供应商开始把他们的系l定位BPMSQBPM systemsQ上。BPAQBusiness Process AnalysisQ是其中很重要的一个方面[25]。BPA主要覆盖了传l的工作品所忽略的方面（例如Q诊断，仿真Q等Q。BAMQBusiness Activity MonitoringQ是BPA中的一个方面，BAM工具的目的在于用信息系l日志中的数据来诊断业务程。例如，ARIS程性能理QARIS PPMQY件[26]从日志细节中提取Z息，q把q些信息以图形的方式表示出来。BAM也能q行程挖掘Q比如从日志中挖掘出程模型[27]?
在流E重设计阶段Q现今有两种势QSTPQStraight Through ProcessQ和CH(Case Handing).STP是指业务程执行的完全自动化Q即不需要h工参与。STP仅仅适用于一部分案例Q因Z可能所有的q程都是W合STP的要求，有时要h工参与才能完成工作。而CH案例分ZU：Q?Q可以被自动执行的案例（2Q需要h工参与的案例。STP目的在于更多的程自动化，而CH则认为很多流E过于动态和复杂而不能完全自动化[11]?
2.2 BPMS的基本概?br> 关系数据库分M应用E序使用的数据和具体的应用逻辑。数据库作ؓ数据持久的存储集合，使用实体关系模型和诸如两阶段提交q样的协议来保证数据的完整性和正确性。数据库的理论基和实现机制十分复杂，但是Ҏ据的各种操作却可以通过相对单的接口(SQL)加以实现?
业务程理pȝ(Business Process Management SystemQBPMS)的提Z是基于这一思想。BPMS使企业能够对核心程q行建模Q部|和理。企业信息系l所处理的业务流E越来越复杂Q需要不断调整才能适应市场Q这对企业信息系l的灉|性提Z更高的要求。工作流pȝ完成了业务逻辑与应用程序的分离Q提高了程的灵zL，但工作流通常侧重于结构化程的自动化执行Q还不以支持整个企业的业务q{Q在此背景下提出了BPMS的概c与DBMS的思想cMQBPMS的思想以一U统一、中性的表示Ҏ描述业务程模型Q业务程模型从实现逻辑中抽取出来，被各个企业应用程序所使用Q从而灵zd构徏Z程的信息系l。业务流E逻辑、业务流E的完整性和正确性可以由BPMS保证Q企业信息系l的开发可以基于BPMSq行[4]?
一般而言QBPMS应具有以下功能模块：
1)程仓库 为流E以及与程有关的知识提供集中的存储场所Q提供目录服务以便于程的查询和发布?
2)程设计 设计程的模块、逻辑、规则和执行角色Q提供流E模板和重用机制?
3)程配置 为流E实例的q行l定参与者，分配资源Q以及设|其他特定的参数?
4)程引擎 驱动程的运行ƈ负责程数据的维护；理程的状态，实现程的事务管理。对于分布式程Q要与其他流E引擎进行交互和协调?
5)程l护 程的监控和异常处理?
6)程入口 为流E的用户提供l一的流E访问机Ӟ包括工作d列表、报告等Q提供企业联盟的程讉K规则?
7)程优化对资源利用进行优化，保证程的一致性，防止死锁?
8)程分析 对关键性能指标q行分析和流E仿真；ҎE的旉和资源性能q行分析?
3QBPM的框架研I?/strong>
有关BPM 的学术研I散见于工作、Y件工E和理U学{领域，对BPM 整体框架的研I较，目前较有影响的是EDL-BP提出的BPM建模软g技术框Ӟ业务程理联盟(Business Process Management InitiativeQBPMI)提出的一pd标准和框架。另外，IBM Z其企业应用YӞ提出了持l业务流E管?Continuous Business Process ManagementQCBPM)框架?
EDL-BP(Eindhoven Digital Laboratory for Business Processes)ҎBPM的生命周期提ZBPM建模所需技术的框架Q如?所C?
? BPM建模所需的技术框?
从图2中我们可以看C同的建模阶段需要不同的技术（包括软gQ，以及q些技术之间的联系。业务流E通过业务程建模分析技术徏立模型然后以信息pȝ的Ş式表C出来。MOD模块使用BBDP技术把现有的实际的BP抽象成ؓ囑Ş化和形式化的业务程Q在通过ANA模块中VAL和VER来校验业务流E是否合理和正确Q随后用PERF工具对业务流E进行性能分析Q用OPT技术对业务程q行优化。在得出了正合理优化后的业务流E后Q用CG技术将业务程模型集成到现有的产品中去Q用IS的Ş式反映出来?
BPMI的主要发赯Intalio公司ZBPMI的系列标准提ZBPM 框架[18]在这个框架中QBPMIpȝ介于企业已有的信息系l和B2B电子商务pȝ之间Q包含流E部|和程执行两个模块。流E部|模块可以利用目录协议与企业ITpȝ的目录服务进行联p，另外Q还可通过UDDI协议流E发布ؓWeb服务。在程执行模块中，程可以被其他的高语言包装成不同的形式Q或者直接提供给工作系l执行。对于跨企业程Q流E的公共部分q可以被装为Web服务Q或者遵照电子商务协议与其他企业的流E进行交互?
CBPM 是IBM提出的BPM 框架[22],其思想和CPI十分cM。该框架的特Ҏ很好地整合了Holosofx BPM Suite和IBM MQ Series工作YӞh很强的实用性。CBPM 分ؓ创徏、协作、自动化和管理四个步骤，每个步骤又可l分q个阶段。这些步骤和阶段都严格对应于Holosofx BPM Suite或IBM MQ Series中的软g模块Q四个流E首联，构成一个闭环流E?
BPMI框架目前局限于程建模和操作的语言规范Q没有涉及从低层到高层的程理的集成问题。CBPM从已有的软gpȝ中来Q其程建模、运行和应用集成方式不具有普遍性，而且没有解决跨企业流E集成问题。文献中的其他框架往往也仅从BPM 的理念出发，其功能模块往往只是概念性的Q缺乏与具体应用pȝ的对应?
4QBPM的Ş式化Ҏ
业务程理模型应该有一个Ş式化描述基础Q因为：1QŞ式化的方法能够清晰的描述描述问题Q不存在含糊不清的表q[6]Q?QŞ式化模型为分析流E提供了数学化基[28]?
l典Petri|是德国U学家Carl Adam Petri在六十年代提出来的，在此后的几十q中。Petri|理论得C极大的丰富．q被q泛地应用于许多研究领域Q如协议工程、柔性制造系l、业务处理等{．使用Petri |描qC务流E主要有以下原因Q?
1Q直观的囑Ş表示 Petri|是一UŞ式化语言Q经典的Petri周有两种元素Q变q元?用方框表C?、库所元素(用圆圈表C?Q而有向边表示选两U元素之同的关系Q?
2QŞ式化的语?Petri |?包括各种高|系l?都有形式化的语义定义Q一个Petri|模型加上相应的语义p描述一个业务流E．
3)状志和事件的正式表示 有些程建模方甚侧重于描q系l状态的变化Q如状态自动机I有些建模Ҏ是基于系l中事g的发生，如流E代说、数据流E?
Petri同能够同时显式地描述pȝ状态和事gQ选样便于对系l的理解和分析?
4Q丰富的分析技?Petri|模型一个很重要的特点在于它提供了丰富的pȝ分析技术，如对pȝ不变?invariance)、活?liveness)、有界?boundness)、安全?safety){分析计，也可以计系l的性能Q如响应旉、等待时间、资源利用率Q?
在文献[6]中说明了使用Petri|作为分析工作流分析工具的三个理由。Petri|是Z状态而不是基于事件的一U分析技术，它成为分析业务流E模型的一UŞ式化的正式方法。通过使用库所W号QPetri|能够很自然地描q流E之间的阶段状态，Z状态的模式比如延期选择Q交叉^行\q状态可以很Ҏ的表C出来了。这些模式的描述可以在文献[7]中找到。然而，当涉及描q某些控制流依赖关系的时候，Petri|也有其不Q见文献[8]。因此，q就DYAMLQYet Another Workflow LanguageQ的发展[9]Q它正确的描qC变迁pȝ的语义?
通过观察我们可以发现Q用Petri|可以很Ҏ的描qg期选择的概念，而这正是在传l的l典工作管理系l中很难支持的，见文献[10]。在web servicelg领域Q两U新提出的标准BPEL4WS和BPML提供了对上述概念有力的支持。在web service中，捕获各种服务和例如象π-calculusq些公式之间的交互是十分重要的。然而现今没有够的证据证明BPEL4WS是基于一UŞ式化语义的，所以能够把如上关系完全形式化是当前应该做的工作?
形式化定义业务流E管理模型语aҎ其表现力q行比较。对于某些工作流建模语言Q其比较可以在文献[29Q?0]中找到。通过q些Ҏl果Q我们可以知道哪些方法能表达什么样的表现力Q同时也看到该领域需要更多的研究以提供更多更好的形式化描q语a?
5QBPM的徏模语a
BPMI[19]最q推Z业务程建模语言(Business Process Modeling LanguageQBPML)[20] 和业务流E查询语a(Business Process Query LanguageQBPQL)[19]两个标准Q分别作为流E徏模和程模型讉K的标准接口，q在此基上提ZBPM 框架?
BPML是基于XML语言的模型描q语aQ它业务流E描q成控制、数据流和事件流的结合，在此基础上还可以在业务流E中d业务规则、安全规则和事务理{特性。与传统的流E徏模语a相比Q它h描述“端到?#8221;程(end-to-
end)的能力，q样Q可以从多个参与者的角度来审视流E模型。另外，BPML以Pi-Calculus[21]作ؓ其数学基Q这UŞ式化描述赋予了BPML在一致性检查、防止死锁、瓶颈检和程优化斚w的较力。虽然BPML现在q不成熟Q但是其官方l织描绘了BPML的美好前景，它具有如下特征[5]Q?
1Q?nbsp; BPML是业务流E徏模的原语aQ就像XML是业务数据的原语a一栗?
2Q?nbsp; BPMLq程跨越多种应用E序和企业，不受M防火墙限制?
3Q?nbsp; BPML提供了中间g的特性：它可以独立开发，实现q程处理监控Q发布和订阅和消息队列等功能?
4Q?nbsp; BPML能够处理不同的应用程序，比如数据库管理系l，软glg{等?
5Q?nbsp; BPML能够用进E定义业务事务和pȝ事务Q业务事务经常包括两个以上的参与者，而系l事务能够包括多个应用程序?
6Q?nbsp; l一业务程和技?q程是BPML的关键目标?
BPQL是BPMS的访问接口，用于ҎE实例运行状态的查询、控制和程模型的部|Ӏ类g不同的编E语a用SQL或其他关联工具可以访问到数据理pȝ那样Q流E管理系l同样如此。DBMSQ数据库理服务器）是一U通用?#8220;数据服务?#8221;Q而BPMS 则是一U通用?#8220;程服务?#8221;。Y件开发者准备采用流E查询语aQBusiness Process Query Language, BPQLQ和程服务器的原因是两者简化了程环境中应用系l的开发。在传统的开发中Q流E的环节四处散落Q一个环节是q个应用pȝ的，一个环节是其他pȝ的。此外，程式应用系l要能看到所有流E和所有流E数据。有了BPQLQ写软gE序ȝ控、中断、交互和协调端到端流E变得轻而易举。如果以程Z心，“电子?#8221;事实上就已经内徏在每个流E中Q不需要专门ؓ每个程~写“电子?#8221;Q就像积木本来就是设计好Q随时可以搭h一栗?
l论
本文l出了业务过E管理的概念和功能，描述了业务过E管理框Ӟ讨论了业务流EŞ式化表述Ҏ和徏模语aQ对比了业务q程理和工作流的区别和联系。比较的l果表明Q业务过E管理是C代企业信息系l体pȝ构的重要发展方向。该文献lD对我进一步展开对基于Petri|的业务程理模型研究有着重要的指g用?
参考文?br> [1]W.M.P.van der Aalst et al. Business Process Management: A Survey .(Eds.):BPM 2003, LNCS 2678, pp. 1–12, 2003. Springer-Verlag Berlin Heidelberg 2003
[2]J. Desel, W. Reisig, and G. Rosenberg. Business Process Management Demystified: A Tutorial on Models, Systems and Standards for Workflow Management. (Eds.): ACPN 2003, LNCS 3098, pp.1-65,2004. Springer-Verlag Berlin Heidelberg 2004
[3]W.M.P. van der Aalst. Making Work Flow: On the Application of Petri nets to Business Process Management. In J. Esparza and C. Lakos, editors, Application and Theory of Petri Nets 2002, volume 2360 of Lecture Notes in Computer Science, pages 1-22. Springer-Verlag, Berlin, 2002.
[4]谭伟,范玉?业务程理框架与关键技术研I? 计算机集成制造系l?W?0L7期，2004q_2-6.
[5] Howard Smith. Business process management-the third wave: business process modelling language (bpml) and its pi-calculus foundations. Information and Software Technology 45 (2003) 1065–1069.
[6]W.M.P. van der Aalst. Three Good Reasons for Using a Petri-net-based Workflow
Management System. In S. Navathe and T. Wakayama, editors, Proceedings of the International Working Conference on Information and Process Integration in Enterprises (IPIC’96), pages 179–201, Cambridge, Massachusetts, Nov 1996.
[7] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros.
Workflow Patterns. QUT Technical report, FIT-TR-2002-02, Queensland University
of Technology, Brisbane, 2002.
[8]W.M.P. van der Aalst and A.H.M. ter Hofstede. Workflow Patterns: On the Expressive
Power of (Petri-net-based) Workflow Languages. In K. Jensen, editor,Proceedings of the Fourth Workshop on the Practical Use of Coloured Petri Nets and CPN Tools (CPN 2002), volume 560 of DAIMI, pages 1–20, Aarhus, Denmark,August 2002. University of Aarhus.
[9]W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workflow Language. QUT Technical report, FIT-TR-2002-06, Queensland University of Technology, Brisbane, 2002.
[10] W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and
A.J.M.M. Weijters. Workflow Mining: A Survey of Issues and Approaches. Data and Knowledge Engineering, 2003 (to appear).
[11] W.M.P. van der Aalst and P.J.S. Berens. Beyond Workflow Management: Product-Driven Case Handling. In S. Ellis, T. Rodden, and I. Zigurs, editors, International ACM SIGGROUP Conference on Supporting Group Work (GROUP 2001), pages 42–51. ACM Press, New York, 2001.
[12]S. Jablonski and C. Bussler. Workflow Management: Modeling Concepts, Architecture,and Implementation. International Thomson Computer Press, London, UK,1996.
[13] P. Lawrence, editor. Workflow Handbook 1997, Workflow Management Coalition. John Wiley and Sons, New York, 1997.
[14]F. Leymann and D. Roller. Production Workflow: Concepts and Techniques. Prentice-Hall PTR, Upper Saddle River, New Jersey, USA, 1999.
[15]D.C. Marinescu. Internet-Based Workflow Management: Towards a Semantic Web, volume 40 of Wiley Series on Parallel and Distributed Computing. Wiley- Interscience, New York, 2002.
[16] C.A. Ellis. Information Control Nets: A Mathematical Model of Office Information Flow. In Proceedings of the Conference on Simulation, Measurement and Modeling of Computer Systems, pages 225–240, Boulder, Colorado, 1979. ACM Press.
[17]BISCOTTI FQFULTON RQInfrastructure and applications worldwide software market definitions(Gartner Dataquest Guide)[EB/OL]Q?a >http://www.gartner.com/ DisplayDocument?doc-ed-106528Q?002-06-10Q?
[18] M.D. Zisman. Representation, Specification and Automation of Office Procedures. PhD thesis, University of Pennsylvania, Warton School of Business, 1977.
[19]BPMIQorgQBPMI initiative[EBQOL]Q?a >http://www.bpmi.org.2001-03-12Q?
[20]BPMI.Org. Business process modeling language[EBQOL]Q?a >http://www.bpmi.orgQ?bpml-spec.esp,2002?1?0Q?
[21]SANGIORGI DQW ALKER DQThe pi-calculusQa theory of mobile processes[M]QCambridge U.K.:Cambridge University PressQ?001Q?
[22]IBM RedbookQContinuous business process management with HOLOSOFX BPM suite and IBM MQSeries workflow[EB/OL].http://www.redbook.ibm.com/pubs/pdfs/red—books/sg24659O.pdf,2002?5Q?
[23]A. W. Holt. Coordination Technology and Petri Nets. In G. Rozenberg, editor, Advances in Petri Nets 1985, volume 222 of Lecture Notes in Computer Science,pages 278–296. Springer-Verlag, Berlin, 1985.
[24]C.A. Ellis and G. Nutt. Workflow: The Process Spectrum. In A. Sheth, editor, Proceedings of the NSF Workshop on Workflow and Process Automation in Information Systems, pages 140–145, Athens, Georgia, May 1996.
[25]Gartner. Gartner’s Application Development and Maintenance Research Note M-16-8153, The BPA Market Cathes another Major Updraft.
http://www.gartner.com, 2002.
[26]IDS Scheer. ARIS Process Performance Manager (ARIS PPM). http://www.idsscheer.com, 2002.
[27]W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and A.J.M.M. Weijters. Workflow Mining: A Survey of Issues and Approaches. Data and Knowledge Engineering, 2003 .
[28]Dirk Wodtke and Gerhard Weikum. A formal foundation for distributed workflow execution based on state charts. In Foto N. Afrati and Phokion G. Kolaitis, editors, Proceedings of the 6th International Conference on Database Theory – ICDT ’97,Delphi, Greece, January 8–10, 1997, volume 1186 of Lecture Notes in Computer Science, pages 230–246. Springer, 1997.
[29] B. Kiepuszewski, A.H.M. ter Hofstede, and W.M.P. van der Aalst. Fundamentals of Control Flow in Workflows (Revised version). QUT Technical report, FIT-TR-2002-03, Queensland University of Technology, Brisbane, 2002. (Also see http://www.tm.tue.nl/it/research/patterns.) To appear in Acta Informatica.
[30] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003.
]]>
?span> 要：针对Web环境下办公自动化pȝ要求Q提ZZ工作管理的OApȝ模型Q论qCZB/Sl构体系的优势，通过工作流的开发方法与B/S技术相l合设计OApȝ的分析，?span>OApȝ的开发和应用的实现?/span>
关键词：工作?span> B/Sl构 OApȝ
中图分类PTP316 文献标识码：A 文章~号Q?/span>1006-7973Q?span>2006Q?span>05-0113-02
一?span>OApȝ工作基本模?/span>
工作徏模是工作技术中的重要组成部分，它通过一pd的过E定义，利用操作、事件、触发条件等因素实现对现实流E的关系抽象。而且在只有保证工作模型和pȝ目标同构的条件下Q在工作徏模过E中才能发挥工作模型的q程开展工作的指导作用。工作流pȝ中主要部件和数据的作用如下：
Q?span>1Q过E定义工兯用来创徏计算机可处理的业务过E描q。它可是形式q程定义语言或对象关pL型，也可以是单地规定用户间信息传输的一l\由命令?/span>
Q?span>2Q过E定义ؓ实现某工作目标而要完成的一pd步骤的描q。它包含了所有业务q程能被工作执行服务的必要信息。这些信息包含v始和l止条g、各个组成活动、活动调度规则、各业务的参与和需要做的工作、相兛_用次序和数据的调用信息等。过E由zd和相x据组成?/span>
Q?span>3Q活动是q程中的每一个步骤。活动可以是E序zd或过E活动，zd通过分配l能够执行活动的用户执行?/span>
Q?span>4Q数据流是活动中间交换信息和映射。工作流理pȝQ?span>WFMSQ用这些数据确定工作流实例的状态{U，例如q程调度决策数据、活动间的传输数据等。工作流相关既可以被工作引擎用，也可以被应用E序调用?/span>
Q?span>5Q控制流是活动间的执行顺序，包含被工作流执行服务Q?span>WESQ和引擎理的系l数据，例如工作实例的状态信息，每一zd的状态信息等?/span>
Q?span>6Q工作流引擎负责解释q程定义Qƈq行q程实例化和q程执行控制、Q务调动、日志维护、通过应用E序接口Q?span>APIQ调用应用程序、提供监督和理功能{，q提供与工作参与者之间的接口?/span>
二?span>B/S|络模式的结构和特点
B/S|络模式是基?span>Intranet需求而出现ƈ发展的。一斚wIntranet是应?span>TCP/IP协议中徏立的企事业单位内部网l，它采用诸?span>TCP/IPQ?span>HTTPQ?span>SMIP?span>HTML{?span>Internet技术和标准Q能Z事业单位内部交换信息提供服务。同Ӟ它是有连?span>Internet的防止外界入늚安全措施。另一斚wQ由于数据库h强大的数据存储和理能力Qƈ且能够动态地q行数据输入和输出，如果把数据库应用?span>Internet上，不仅可以实现大量信息的网上发布，而且能够为广大用h供动态的信息查询和数据处理服务，q而加Z息交，降低企事业单位的日常工作成本Q提高企事业单位的经效益?/span>
B/S模式Q即览器服务器模式Q是一U从传统的二?span>C/S模式发展h的新的网l结构模式。其本质是三层结?span>C/S模式?span>B/S模式主要由客hQ?span>Web服务器，应用服务器和数据服务器（serverQ组成。在客户端安装的是标准、易用的通用览器（BrowserQ，?span>Web技术与数据库技术相l合?span>Web服务器主要是实现对客L应用E序的集中管理，应用服务器主要负责事务处理，数据服务器主要用于数据的理Q?/span>
B/S模式基本上克服了C/S模式的不I其主要表现在Q?/span>
1Q系l开发、维护和升的经性?/span>
2Q?span>B/S模式提供了一致的用户界面Q应用Y仉是基?span>Web览器，从?/span>提供了一致的用户界面?/span>
3Q?span>B/S模式h很强的开放性?/span>
4Q?span>B/S模式的结构易于扩展，h可~性?/span>
5Q?span>B/S模式h最强的信息pȝ集成性?/span>
6Q?span>B/S模式提供灉|的交和信息发布服务?/span>
三?span>OApȝ?span>B/Sl构
软g体系l构的设计是整个软g开发过E中的关键点。不同类型的pȝ需要不同的l构体系Q对于应用Y件来_特别是一些较为复杂的软gpȝQ要求必d备一个合适的体系l构Q系l的设计与实现很大程度上取决于结构体pȝ择取Q基?span>B/S|络l构体系开发的OApȝQ如?span>3Q，?span>OApȝ中的三要素（数据、功能、行为）分离QŞ成前端客户层Q负责可UL的逻辑表达Q中间应用层Q允许用户通过其与设计应用隔而共享和控制业务逻辑Q后端的设计隔离和服务层Q提供对专门数据服务的访问，处理客户端与数据库间的数据流?span>B/Sl构体系?span>C/Sl构体系相比Q其优点如下Q?/span>
1Q不必开发专门的客户端YӞ在用L端不需要增加Q何代码，用户只需要用现行的览器，基操作十分方便，单易学，界面l一Q降低了用户学习新知识的隑ֺQ既节省了开发时_也减了pȝ出错的可能性，降低了维护费用?/span>
2Q网l应用系l跨q_Q兼Ҏ好Q保护原有的软硬件设施，原来的网l操作系l，数据库都可以很容易地加以利用Q可以ɾpȝ在最短的旉发挥效益?/span>
3Q技术上相对成熟Q投入费用少Q系l维护简便，单易用，见效快，回报率高Q应?span>Web技术，OApȝ只需在服务器上集中实现和配置的维护管理，大大降低了用L于Y件系l维护和升的难度和费用Q用h资风险小?/span>
4Q系l运行稳定、安全、可靠、ƈ可进行扩展?/span>
5QY件移植容易，q可以进行严密的安全理?/span>
此外Q?span>B/S层次分离的优势体现在界面l一为浏览器Qƈhl一的语a格式Q统一的传输协议，pȝ理单，能够优化资源Q可支持数据库和方便信息发布{?/span>
四?span>OA的系l设计分?/span>
1OApȝ的体pȝ?/span>
Internet为工作流的应用提供了良好的网l^収ͼ在实践中Q可以徏立一个如?span>1所C的ZB/S应用工作技术的办公信息pȝ?/span>
?span>1 pȝl构?/span>
从上囑֏以看出基?span>B/S应用工作技术的办公信息pȝ。一般包括（1Q客L览器（2Q?span>Web服务器（3Q数据库服务器（4Q工作流服务器等。由于采?span>Web览器的形式Q在客户端只要求安装Web览器，用户在客Lq行信息览、业务操作、工作流的处理等{。而处理过E在服务器端完成?/span>
3Q应用工作流Petri|和B/Sl构实现pȝ工作的开?/span>
Petri|是由d国数学家C·A·Petri定义的一U通用模型Q用以描q存在于条g与事仉的关p，它是一U可用图形表辄l合模型Q具有直观、易懂和易用的特点，很适合工作的表达Q工作流是由一l相x动构成，zd是完成一Q务所要进行的多种操作的统Uͼ各个相应部门所完成的活动就UCZQ务。每Q务包括Q务的内容、Q务的状态、Q务的执行l果?/span>
Petri|中控制极为重要，它控制流E的走向Q控制流的结构分为顺序结构、ƈ行结构、或条gl构Q@环结构等Q?/span>
各企事业单位在具体设?span>OApȝ的功能模块时Q可针对自n情况q行具体分析Q通过一U或几种l构的有机组合，同时要考虑到方斚w面的协调性尽量做到流E的设计规范、实用、方ѝ安全?/span>
工作流E控制的大部分功能部仉是利?span>Active Xlg来实现的Q系l用VBScriptQ?span>Java Script来集成这些组Ӟ利用新增lgQ客户可以灵zd扩展服务器端和用L的功能，随着用户需求的动态变化，pȝ可以方便地通过重组lg实现功能的扩展，对分配给每个工作参加者的d列表和Q务管理器Q用h据自q角色通过览器从服务器上下蝲到客Lq行?/span>
在系l中Q对公用信息应用׃n模型q行程理Q应?span>Web技术处理客L的请C，公用的信息保存在服务器端，办公室h员根据自q角色和相应的权限Q周期性地从服务器端提取信息，工作服务器也周期性地从服务器端提取处理结果，Ҏl果控制程?/span>
4Q开发工具和q行q_的选择
Z实现OApȝ的各功能和l护数据，一般需q行Z|络的数据库开发，首先必须建立Z|络数据库的开发环境，在此基础上才能进一步开展工作，一般情况下Q?span>OApȝq_配置要求如下Q?/span>
服务器端Q网l操作系l?span>Windows 2000 Server 中文版，|络协议TCP/IPQ?/span>
Web服务器：MicrosoftIIs5.0 Q数据库pȝMicrosoft SQL Server2000 {；
客户端：Microsoft Windows2000中文版或其他操作pȝQ?span>IE5.0中文版等Q?/span>
开发工PASPQ?span>Microsoft SQL2000 Q?span>J Builder 9.0{?/span>
五、结束语
本文分析了基于工作流理技术和采用B/Sl构相结合的OApȝQ能够将办公{诸多工作集成于一P通过Internet/Intranetq行办公业务处理Q提供数字化办公环境。采?span>SQL Server2000 数据库作为后台支撑，而设计开发的OApȝ。此U系l能够提供规范、灵zȝ办公程理Q具有功能齐全，使用方便、安全性好、可靠性高的特炏V科学化的管理需要依靠现代化的办公工兗智能化决策、无U化办公已经成ؓ企事业单位现代化理的趋势，而办公自动化pȝ在C化管理中发挥来重要的作用?/span>
参考文?/span>
[1] KimY.Kang.S.KimD.etal.WW?span>based workflow management with runtime encapsulation.[J].IEEEInternet Comput-er.2002.4.3Q?span>55~64.
[2] LIUKQ?span>ONGT.Amodeling approach for handling business rules and exception.[J].The Computer Journal.1999.42.3Q?span>206~223.
[3] 张友生，陈松?/span>.C/S?span> B/S混合软g体系l构模型.[J].计算机工E与应用.2002.23Q?span>138~140.
[4] 胡生Q党延忠.ZWeb的工作流技术在办公信息pȝ中的应用.计算机应用研IӞ2002.9Q?span>117~119.
]]>