??xml version="1.0" encoding="utf-8" standalone="yes"?> 我们使用业务程建模来交信息,正如在上一节里所qͼҎ(gu)不同模型的用P客户、业务h员、分析h员、开发h员)(j)Q徏模有着不同的风根{BPMN被设计用来涵盖各U风格的程模型Q以满不同角色人员交流的需要)(j)和创建端到端的业务流E,它支持三U基本类型的程模型Q?/p> U有的业务流E是指某一l织的内部工作流E,我们通常UC为称为工作流Q在WEB服务领域Q我们也UC为服务的~制QOrchestrationQ。存在两U类型的U有业务程Q可执行的和不可执行的。可执行的私有业务流E以被计机执行为徏模目的,q应的BPMSpȝ来自动化程的执行,它包含了_的执行细节,q些l节包括执行规则、条件表辑ּ{计机解释执行所需要的技术信息,该模型最直接的用h开发h员。不可执行的U有业务程则以文档化ؓ(f)建模的目的,它缺执行细节,但是包括_的交信息,该模型的用户包括了业务h员与分析人员?/p> 作ؓ(f)一个例子,我们一h看看我在公安局L(fng)Uؓ(f)儿子办理户口的流E,如下图所C:(x) ?公安局L(fng)U上户口的流E?/p> 当我来到L(fng)U,递上_的资料,然后开始等待。我能看到共有四个工作h员,W一个工作h员负责接收资料,查看资料是否完备Q接下来Q她所有的资料传递到下一个工作h员,W二个工作h员对资料q行审核Q在计算Z查看我们的户口信息是否正,接下来,如果资料无误Q他资料传递到W三个工作h员,W三个工作h员负责在计算Z为我的儿子录入新的户口,最后打印出一张户口页Q第四个工作人员是职位最大的警员Q她负责盖章Q然后将儿子的户口页传递给在窗口外{待的我?/p> Ҏ(gu)上面对私有业务流E的定义Q我们很Ҏ(gu)的判断出q个程是个不可执行的私有业务流E,因ؓ(f)该流E是L(fng)U的内部工作程Q作程服务对象的我Q我Ҏ(gu)不用兛_L(fng)U内部是如何Ҏ(gu)的申误行处理的Q所以它是私有业务流E。该程是由规章或制度所规定的,由工作h员来驱动Qƈ非通过计算机协调,所以这是个不可执行的私有业务流E?/p> 因ؓ(f)U有业务程是内部流E,所以它只能存在于一个池QpoolQ池代表一个参与者)(j)里,如下图所C,我们可以私有业务流E徏模在一个池里,但通常q样做没有太大的意义Q更l常的情冉|Q我们选择池忽略?/p> ?公安局L(fng)U私有业务流E的另一U徏模Ş?/p> 公开程表现一个私有业务流E与其他程或参与者之间的交互?/p> q是以户口办理作Z子,作ؓ(f)户口甌人,我来到公安局L(fng)U,我心揣揣Q我不知道我该做些什么,于是我看到大厅里如下图所C的程Q于是我立刻明白了Q我只需要将资料交给办事人员Q然后等待取新的户口即可?/p> 注意下图所C的公开程与图1所C的U有程有哪些不同。第一是图中出C多个参与者,参与者间通过消息连接(图中虚线头q线Q;W二是户c科的办理流E被~减到只剩两个与外部参与者交互的zdQ两个原有的内部zd被忽略了。这两点不同x公开程的特点:(x)表现与外部参与者、流E间的交互,忽略内部zd。联惛_我们实际的编E,ȝ成一句话Q就是隐藏内部实现细节,仅仅展现对外接口Q表现流E的外部行ؓ(f)?/p> ?公安局L(fng)U办理户口的公开程 协作描绘两个或多个业务实体间的交互。一个协作通常包含两个或多个池Q每个池代表一个参与者(业务实体Q。参与者之间的消息交换通过q接两个池(或池中的对象Q的消息表现。协作可以表Cؓ(f)两个或多个公开程之间的交互,在上一节里Q我们提刎ͼ与对应的U有程相比Q公开程隐藏了内部细节活动。池也可以是黑盒Q即里面什么对象都没有?/p> 那么Q这里有一个问题,公开程与协作有什么区别?区别在于表现的范_(d)公开程只是表现一个私有流E与外部的交互,而协作则能表现多个流E?参与者之间的交互?/p> q是看户口办理的例子Q在前面的例子中Q我们看C公安局L(fng)U办理户口的U有程和公开程Q似乎办理户口是一件很单的事情Q但q仅仅只是办理户口中的一步而已。在此之前,我先要去医院办理孩出生证明Q接下来Q我要去居委?x)登记小孩信息,再接下来Q我要去计生办办理符合计划生育政{的证明Q最后,我才来到L(fng)U。下图是整个户口办理的协作图Q作为简化,q里除甌人和L(fng)U之外的池都黑盒了:(x) ?户口办理协作?/p> 同样是表现多个参与者之间的交互Q编排做的更为纯_,它取消掉了池的概念,改由~排zd直接表现多个参与者之间的消息交互Qؓ(f)协作模型提供了一U基于流E图的视图。户口办理的~排囑֦下图所C,其中每个zd都能看到上下的方形区域有参与者信息,q表明这个活动的参与者,色部分为活动的发v者,p部分为活动的响应者,我们?x)在接下来的BPMN元素节里详l描q这一zdcdQ?/p> ?户口办理~排?/p> 与协作图相比Q编排图省略掉了更多的细节,例如与各个参与者具体的交互q程Q它兛_谁和谁生了交互Q至于如何交互,分几步交互,它ƈ不关心。例如办理户口这个活动,实际上我是分别和两个警官q行了交互,一个是负责接受资料的年d警官Q一个是负责盖章复核的领D官,在协作图中,我可以通过公开程展现一点,但是在编排图中,qƈ不是要表现的重点?/p> 协作图表现出参与者之间的交互Qƈ包含交互的细节信息(交互的接口、如何交互)(j)Q编排图则以程囄形式表现出参与者之间的交互Q它兛_的是某个d需要哪些参与者发生交互,交互的细节不是其表现的重炏V?/p> ~制与编排的区别 在上文中Q我们提C服务的编ӞOrchestrationQ,q里Q我们又提到了编排(ChoreographyQ,q两者是有很大区别的?/span> WS-BPELSOA中的服务按照一定的序灉|l装在一L(fng)程是~制QOrchestrationQ。编制后的WS-BPEL,通常代表了某个特定的业务中的服务的执行流。而编排(ChoreographyQ则是描q参与者之间交互关pȝ程。与~制不同的是Q编排ƈ不需要一个执行引擎,它只是描q关pR编制代表的是一个可执行程Q它必须通过执行引擎来执行。而编排实质上是代表一U描qͼ卛_与者之间如何互相协调来完成一个目标?/span> John Reynolds在其博客中是q样描述~制和编排的区别[1]Q?/span> ~制 == 可执行过E?/span> Web服务~制与执行特定的业务程相关。WS-BPEL是一U用来定义可以在一个编制引擎中执行的流E语a?/span> ~排 == 多方合作 因此~制必须对应一个执行引擎,而编排由于涉?qing)到多方合作Q所以它是不能被直接部v的?/span> ?x)话视图为协作图提供了另外一U非正式的表现Ş式,与编排图一P它的目标同样在于表现参与者之间的关系Q它?yu)一pd相关的信息交互定义ؓ(f)一ơ会(x)话。户口办理的?x)话囑֦下图所C,图中只存在池与会(x)话(CommunicationQ元素,?x)话元素由图中的六边形代表,它代表两个或多个参与者之间一pd相关的信息交互,我们可以看到Q办理户口需要申请h与四个组l发生四ơ会(x)话:(x) ?户口办理?x)话?/p> ?x)话视图的作用之一是能够有效减模型中消息的数量Q便于我们理解?/p> ??x)话视图化交互模?/p> 正如语言是h之间的沟通方式一P数据?/font>ITpȝ之间的沟通方式,语言之间的沟通L最有效的,数据交互却未必,因ؓ(f)ITpȝ里的数据除了让计机理解外重要的是还需要h理解。在q篇文章里,我们讨论工作流pȝ里的数据Q从数据角度分析工作数据的分类以及(qing)不同的应用场景?/font> 一、工作流pȝ的应用场?/font> 在正式开始对工作数据的讨论之前Q首先对工作系l的应用场景q行讨论是必要的Q因为工作流数据q不开工作系l这个大的上下文。目前,工作系l的应用主要有两U方式:(x) 1?nbsp; 工作流pȝ嵌入C务系l中使用。此时工作流pȝ作ؓ(f)内部lg对业务系l进行流E逻辑的横切。试想一个需要多人处理的?sh)力~费程Q在引入工作系l之前,我们需要ؓ(f)每个业务表单讄一个状态位Q以此来q行业务处理状态的跟踪。如果流E固定,那么q样做ƈ没有什么不好,例如财务软g、vx兌Y件等Q它们的程虽然复杂但是不常改变Q此时就没有必要引入工作系l。但是对于另外一些情况,例如刉业的订单处理、库存管理、政府的协同办公{,程l常需要定制修改,此时如果l箋׃务系l自己处理流E逻辑那么成本会(x)很高?/font> 2?nbsp; 使用工作系l进行业务系l的集成。在上规模的企业里,很多程?x)涉及(qing)到不同的业务功能,例如报h(hun)、订单审核、资产核准、W效评估等Q这些流E经怼(x)跨越不同的部门和业务pȝ。因Z同企业都有自己所采用的业务系l、组l机构以?qing)最佳的业务协作Ҏ(gu)Q所以这些流E基本上也随企业而异。工作流pȝ此时扮演的就是集成角Ԍ由其通过定制程这些业务系l撮合v来,实现企业内各部门、客户间的信息流动和协作?/font> 在第一U应用场景下Q工作流pȝ作ؓ(f)业务pȝ的内部横切组件出玎ͼ作ؓ(f)横切lgQ工作流数据仅仅包括与流E逻辑相关的数据以?qing)其他必需数据Q这些数据包括工作流控制数据、工作流相关数据以及(qing)需要通过程传递的业务数据?/font> 在第二种应用场景下,׃不同业务pȝ之间的数据传递很大程度上依靠工作系l,所以这些数据被装?/font>SDO在不?/font>WEB服务间传递,需要注意的是,q些数据q不在工作流pȝ中存储?/font> 在下面的工作数据分cMQ我们将详细分类q些工作数据?/font> 二、工作流数据的分c?/font> 提到工作数据,׃得不提业务数据。作为最直接的区分,我们存储于业务pȝ中的数据UCؓ(f)业务数据Q将存储于工作流pȝ中的数据UCؓ(f)工作数据。根?/font>WFMC定义Q我们将工作数据分为工作流控制数据和工作流相关数据?/font> 1?nbsp; 工作控制数?/font>。指被工作流pȝ理的系l数据,q些数据包括了与程实例和Q务实例相关的执行数据Q例如流E实例的状态、执行时间等信息、Q务实例的执行者、执行时间、状态、紧急程度等?/font> 2?nbsp; 工作相x?/font>。指与业务流E相关的数据。工作流相关数据又具体分?/font>3U:(x) · 影响程实例执行的业务数据。在WFMC中,q个数据被描qCؓ(f)Q工作流pȝ通过该数据来定程实例的流转条Ӟq择下一个将执行的Q务,q些数据可以被业务系l访问ƈ修改。例如报销程中的“报销金额”Q这个数据会(x)军_该流E的审批路径Q再例如ZQ务设|的时旉Q这个数据会(x)触发d的取消。实质上q些数据是工作系l需要依赖于q行程{的业务数据?/font> · 契合业务的关联数据。指工作系l与业务pȝq行兌的数据,例如特定?/font>WEBpȝQ工作流pȝ?x)在每个程实例里保持有D臛_应业务表单的URL?/font> · 传递作用的业务数据。当程跨越多个业务模块Ӟ需要在模块间传递数据,此时?x)利用工作流pȝq行传递,?x)在工作系l里暂时存储q些业务数据?/font> 那么Q工作流数据有哪些应用场景呢Q?/font> 三、工作流数据与业务上下文 工作数据最重要的职责之一是Z务系l的不同应用场景建立起与之对应的业务上下文?/font> 什么是业务上下文? 我们知道Q?/font>ITpȝ是对企业现实业务的映。在一个翻译公司的典型业务场景中,校对人员对翻译h员提交的译文档q行审校Q此Ӟ校对人员持有译人员译后的文档Q他需要对该文档进行检查,产生新的审校文档q反馈翻译h员的译质量。那么,映射?/font>ITpȝ里,校对人员的Q务通常对应于一张需要处理的业务表单Q业务表单里?x)展Cq行当前工作所需要的数据Q翻译文档、翻译h员信息、该校对工作的紧急程度等Q另外,在这张表单里Q他所能进行的操作也根据他此时的职责作Z行ؓ(f)限定Q例如他可以上传新的校对后的文档Q但是不能删除已有的译文档{。如下图1所C,业务表单实质上反映的是此L们能获取哪些数据以及(qing)能够如何处理q些数据Q我们把它称之ؓ(f)业务上下文,可以看到Q在ITpȝ里,业务上下文实质上{于数据加上行ؓ(f)?/font> 企业业务׃pd怺兌的业务场景组成,q些业务场景对应?/font>ITpȝ里的业务上下文,而业务上下文的本质则是数据加上行为。数据和行ؓ(f)的不同决定了业务上下文的差别。这与现实中的工作相W,ZҎ(gu)获取/处理信息的不同,担负不同的职责?/font> ?/font> 1与应用场景对应的业务上下?/font> 工作数据如何徏立业务上下文呢?看一个简单的例子?/font> 在实际应用工作流pȝq行开发时Q我们经怼(x)到q样的问题:(x)同一程中的不同d对业务数据拥有不同的权限Q如下图6-9所C?/font> ?/font> 6?与流E相关的业务数据权限 上图中,在执行请假申请Q务时Q申误(g)可以编辑请假h、天数和原因3个字D;而到审批dӞ审批者增加了一个可~辑的审Ҏ(gu)见字D,但其?/font>3个字D变化ؓ(f)只读字段。我们将q类问题l称Z程相关的业务数据权限控制?/font> 产生q类问题的原因是什么呢Q原因就在于在一个业务流E里Q不同的dh不同的业务上下文。如下图6-10所C,不同的Q务展C同的数据Qƈh不同的行为?/font> ?/font> 6?0d与业务上下文 ?/font>ITpȝ的设计实CQ数据的建模是通过领域模型实现的。在工作系l的嵌入式应用中Q流E实例即是通过与领域模型相兌实现与业务契合的。那么,?/font>6-10可以q一步泛化ؓ(f)?/font>6-11Q流E中d通过获取领域模型不同的部分实C务上下文的界定?/font> ?/font> 6?1领域模型与业务上下文 在大部分的业务流E徏模中Q一个流E模型只与一个领域模型关?/font>?/font> 那么Q回到最初的问题上,如何处理此类权限问题呢?{案非常明了Q由领域模型实现对业务上下文的切分,工作系l通过契合业务的关联数据与业务上下文挂接,保持工作系l的单一职责?/font> ?/font> 6?2程相关的业务数据权限控?/font> 如上?/font>6-12所C,我们在业务系l里引入业务权限角色的概念,通过该角色隔d工作系l与业务数据权限Q即我们认ؓ(f)业务数据权限的管理属于业务系l范_(d)׃务系l具体实玎ͼ(j)Q更q一步,我们认ؓ(f)其属于领域模型的职责范围。在定义好业务系l的权限角色后,我们通过dU别的工作流变量流E中的具体Q务与业务权限角色l定Q这样就实现了流EQ务与业务数据权限的挂接?/font> 在上面的例子中,我们看到的是利用兌业务的工作流数据界定dU别的业务上下文Q这是一U最单的工作数据应用场景。在不同应用中,我们可以看到Q工作流数据一个重要的职责是Z务流E里的Q?/font>/程建立业务上下文,实现数据的聚合。在单的应用场景里,对一个流E实例而言Q这些数据可能只对应于一个领域模型;Ҏ(gu)E实例里的一个Q务实例而言Q这些数据对应于领域模型的一个切面。复杂一些的情况Q业务上下文需要跨多个领域模型甚臛_个业务系l,q时我们可以看到Q通过工作系l能够显著降低业务系l徏模的复杂性,因ؓ(f)q些数据聚合工作可以有效分派l工作流pȝ承担。同Ӟ我们需要保持工作流pȝ的单一职责Q工作流pȝ只保存与业务数据q行兌的关联数据、必需的业务传递数据以?qing)自w的执行数据?/font> ?/font> 6?9跨系l的业务上下?/font> 四、工作流数据与数据分?/font> 工作数据的W?/font>2个应用场景是对业务流E执行进行数据分析,q部分的数据主要?strong>工作控制数?/strong>。这一部分正受到越来越多的重视Q是未来工作系l的发展方向?/font> ?/font> 6?8外部环境从流E实例拉数据q行分析 q里有两个典型的应用例子Q?/font> 例子1在对报销程q行分析Ӟ我们发现大部分的报销金额都低?/font>500元,然而这些报销程却都要经q很多环节,在与客户认后,我们低?/font>500元的报销限定于部门内部审批即可,q样对个人来说大大加快了报销q程Q对公司来说则省下了很多的办公成本?/font> 例子2Q在刉流E里Q很重要的一Ҏ(gu)需要控制流E的节拍旉Q即程里各个Q务的完成旉要一_(d)如果有一Q务的旉多于其他dQ那么很快就?x)Ş成瓶颈,造成在制品的大量U压Q前l的d完成很快Q中间忙死,后箋d执行者却无事可做Q更重要的是Q不能对客户q行快速交付?/font> 五、工作流数据与流E\?/font> 最后一U应用场景非常常见,q部分数据即影响程实例执行的业务数?/strong>Q直接上图:(x) q部分媄(jing)响\q一定是业务数据Q它们保存到工作系l里Ҏ(gu)E\׃生媄(jing)响。这U媄(jing)响不限于d的选择Q还包括的Q务的执行条g、Q务的完成条g、基于数据的d触发{?/font> 六、工作流数据结 ȝ一下,作ؓ(f)区分Q?/font>我们存储于业务pȝ中的数据UCؓ(f)业务数据Q将存储于工作流pȝ中的数据UCؓ(f)工作数据?/font> 工作数据分ZU:(x)工作控制数据和工作相x据。其中工作流相关数据又分?/font>3U:(x)影响程实例执行的业务数据、契合业务的兌数据和传递作用的业务数据?/font> 工作数据的应用场景Qؓ(f)程/d建立业务上下文,q部分数据主要是契合业务的关联数据和传递作用的业务数据Q这是工作流数据最重要的职责之一Q数据分析,q部分数据主要是工作控制数据,q是未来工作的发展方向Q媄(jing)响流E\由,q部分数据h如其名,是媄(jing)响流E实例执行的业务数据?/font> 实际应用中,我们一定要保持工作系l的单一职责Q例如划分Q务权限这个需求,一定需要业务系l自行实现权限的界定Q工作流数据仅仅q行挂接?/font> BPMN的流E模?/strong>
Ø 程~制QProcess OrchestrationQ,包含Q?/h3>
Ø ~排QChoreographyQ?br />Ø 协作QCollaborationsQ,包含程?或编排?/h3>
U有的(内部的)(j)业务程
公开程
协作
~排
协作的会(x)话视?/strong>
]]>
BPMN最早是׃务流E管理倡议l织QBPMI, Business Process Management InitiativeQ开发的Q这个组l的领导者是Intalio公司。提到BPMIl织Q不得不?BPML(Business Process Modeling Language) 业务程建模语言。在敏锐的认识到Web成为未来分布式pȝ架构的^台后QBPMIl织创徏了BPMLQ一U全新的程执行语言Q该语言不与M供应商绑定,而BPMN则作为BPML的可视化表现W号被创建。BPMIl织的会(x)员在高峰期达C200多家公司Q除了IBM和微软,几乎所有的主要软g供应商都加入了该l织?nbsp;
BPMN则反映出BPMIl织的另一个具有前L的观点Q即业务人员Q多是非技术h员)(j)对IT执行程的可视化和管理将成ؓ(f)未来BPMpȝ的关键。通过授权Q业务h员能够管理自q程。在BPMN出现之前Q市面上已经存在程建模囄标准例如UML的活动图QUML由对象管理组lOMGl护理Q很快,我们再ơ看到这一l织Q,但这些标准被认ؓ(f)q于技术化Q而BPMN在被设计之初强调要对业务h员友好。BPMN1.0?004q?月由BPMIl织正式发布Q其全称是Business Process Modeling NotationQ即仅仅作ؓ(f)业务程建模的一pdW号标准?nbsp;
对BPMN和BPML来说Q两者的遭遇截然不同Q在BPMIl织的会(x)员中QBPMN受到了大多数程建模工具厂商的欢q,他们认ؓ(f)l一的徏模标准能够他们围绕核心建模工具提供其他更多的h(hun)|而BPML则遭C很多工作厂商的痛恨Q因Z个统一的流E执行语a标准得他们重新竞争,而私有的程执行语言已经市场分Ԍ他们想维持现状。因此,矛盾从一开始就存在了,BPMIl织原计划是建立一套业务h员能够自理的流E系l标准,BPMNx业务程的描q和分析Q它建立的模型是面向业务人员的,是不可以直接执行的,而BPML则由BPMN自动生成可执行的程语言Q交由ITpȝ执行Q但是现在,BPML被工作流厂商们认为是对自q一U威胁?nbsp;
事实上,厂商们对BPML是多虑了。IBM和微软很快开始了反击Q他们在2002q?月推ZBPEL-WS规范Q一个与BPML有稍怸同的语言Q基于新的WSDL标准。BPML与BPEL-WS之争也被看作是Betamax与VHS格式之争QBetamax品质优秀Q但VHS得到数量众多的制造商支持QBetamax战|Q于是BPML被消灭?nbsp;
2005q_(d)BPMIl织被OMGl织合ƈQBPML停止l护Q?006qOMGl织正式通过BPMN1.0规范Q?008q?月发布BPMN1.1?nbsp;
记忆里,有那么多的规范、标准,从开始炒作的沸沸扬扬Q到最后的逐渐淡出Q不q几q光景。但BPMN却在2008q大爆发Q得C极大的普?qing)。具有讽刺意味的是,BPMN的流行完全归功于那些当初反对BPML的工作流厂商们,恩恩Q现在他们都改名叫BPMS厂商了。原因很单,业务人员对IT执行程的可视化和管理已l成为BPMSpȝ的关键,BPMIl织猜到了结局Q却忘了猜猜自己?nbsp;
那么QBPMN的故事结束了吗?昄没有QBPMN1.x只是一些徏模符P不支持元模型Q不支持存储和交换,也不支持执行。那么围l着BPMN1.x的存储、交换和执行Q必然会(x)产生新的竞争Q这ơ的主角换成了XPDL、BPEL和BPDM?nbsp;
XPDL作ؓ(f)WfMC提出的流E定义语a规范Q本w就是一个元模型Q可以存储,q且具备执行语义Q因此理Z来讲Q将BPMN转换为XPDL可以解军_储、交换和执行的问题。XPDL2.0?005q?0月发布,在规范里QW(xu)fMC直接XPDL的目标定义ؓ(f)BPMN的XML序列化格式?008q??3日发布的XPDL2.1规范Q直接支持BPMN1.1到XPDL2.1的{换。XPDL是面向图的,BPMN也是面向囄Q因此BPMN到XPDL的{换有着天然的优ѝ如今有过80个的不同公司的品用XPDL来交换流E定义,同时也有一些厂商在自己提供的BPMN工具中用了XPDL作ؓ(f)交换和存储格式?nbsp;
但XPDL的流行是大厂商们所不愿看到的,他们的规范自然还是BPELQ我辛辛苦苦PK掉BPMLQ?zhn)XPDL抢位来了Q我情何以堪Q情何以堪啊。BPEL-WS规范?003q?月提交给了OASISQOrganization for the Advancement of Structured Information StandardsQ结构化信息标准促进l织Qƈ更名为WSBPELQWeb Services Business Process Execution LanguageQ规范, 2007q?月发布WSBPEL2.0版本Q除了Microsoft?BEA?IBM?SAP 和SiebelQSun Microsystems和甲骨文公司也相l加入了OASISl织。除Ld素,BPEL的流行还在于Web正成为分布式pȝ架构的^C?qing)SOA的雄PSOA服务的分解和解耦,而BPEL则对q些WEB服务q行~制Q两者密不可分。但BPMN到BPEL的{换存在着先天上的~陷Q原因是BPMN是基于图的,而BPEL是基于块的,BPEL是一个结构化Q块[Block]Q和非结构化Q控刉和事Ӟ(j)的合体。这个缺陷导致有些BPMN建模的流E无法映到BPELQ两者的双向工程更是存在问题。这个缺hZh们反复诟病的对象。许多支持BPEL的品ؓ(f)了解册一问题Q不得不在用户徏模时做出U种限制Q让用户l制不出无法转换的模型?nbsp;
而BPDMQ业务流E定义元模型QBusiness Process Definition MetamodelQ则是OMGl织自己提出来解决BPMN存储和交换问题的规范。于2007q?月Ş成初E,2008q?月被OMG最l采用。BPDM是一个标准的概念定义Q用来表达业务流E模型。元模型定义了用来交换的概念Q关pd场景Q可以得不同的建模工具所建模出来的流E模型进行交换。BPDM越了BPMN和BPEL所定义的业务流E徏模的要素Q它定义了编排和~制?nbsp;
三者的竞争关系gq将l箋Q但QBPMN2.0出现了,BPMN2.0 beta1版本?009q?月发布,BPMN2.0 beta2版本?010q?月发布,BPMN2.0正式版本?011q??日发布。BPMN2.0正式自己更名ؓ(f)Business Process Model And NotationQ业务流E模型和W号Q,相比BPMN1.xQ最重要的变化在于其定义了流E的元模型和执行语义Q即它自p决了存储、交换和执行的问题,BPMN由单U的业务建模重新回归了它的本源,即作Z个对业务人员友好的标准流E执行语a的图形化前端。BPMN2.0一出手Q竞争就l束了,XPDL、BPEL和BPDM各自准备回家钓鱼。看h胜利者似乎是BPMNQ但看看BPMN2.0的领D,׃(x)发现最后的胜利者还是IBMQ?Oracle和SAPq些大厂商们Q他们提交的草案明确要赋予BPMN2.0以执行语义,q迫使BPDM团队撤回了其提交Qƈ他们的提议与BPDM团队x合ƈQ这是BPMN2.0最后内容的由来?nbsp;
BPMN的目标是期望通过一套统一的徏模、执行模型填起业务h员与开发h员之间的那道鸿沟。但问题是它真的能够如它期望般的做到q一点吗Q对业务人员友好的模型对开发h员同样友好吗Q反q来Q对开发h员友好的模型对业务h员同样友好吗Q尽他们用的都是同一套符P我们在后l的建模实例里将看到q样的问题,q涉?qing)到建模的风根{同一个流E模型能够用多U徏模方式,哪种方式才是最有效的?q就需要考虑模型的用h谁(业务人员、分析h员、开发h员)(j)Q才能界定是否有效了。此外,工具毕竟只是工具Q促q业务h员与开发h员之间的沟通,除了工具Q还有公司文化、组l结构等{其他h的因素,q也才是最重要的因素?nbsp;
不管怎样QBPMN2.0是BPMN历史上最重要的一个版本,BPMNl箋向正的方向q进了一大步。在下一节里Q我们将一L(fng)看BPMN所支持的三U基本类型的程模型?nbsp;
]]>
]]>
在之前的一D|间里Q只要一提vPDFQ我׃(x)头晕Q然后是头疼Q最后是头大QM是和头相兟뀂需求很单:(x)为所有报表提供在U生?/font>PDF版本的功能,q样|站用户在浏览报表时可以下载离U浏览。对不住了,开源YӞ我不得不_(d)慎用开源YӞ慎用Q痛苦的查找论坛、痛苦的ȝ源码Q最后,在支付了200Ƨ后Q痛苦消׃Q我们购C商业软gQ?/font>200Ƨ兼容了更多的网늻构,200Ƨ具有更快的速度Q?/font>200Ƨ带有一q的技术支持,最最重要的是Q?/font>200Ƨ,客户出的?/font>
q不是这里的关键Q问题是Q?/font>200Ƨ后Q我遇上了新ȝ(ch)Q报表的PDF版本样式不正,不正的原因是图片下方的文字图片的排列样式弄ؕ了(囄大小不规则,字数不规则)(j)。在|页中,DOM渲染完毕后,我们使用JavaScript来进行图片与文字高度的重计算Q但?/font>PDF中,我们束手无策?/font>
我问BAQ可以容忍部分图片排列不整齐否?不出所料?/font>
怀有oq,我l问BAQ可以容忍部分文字丢失否Q?/font>BA_(d)不可以。意料之中。于是找到徐昊?/font>
徐昊?/font>BAQ这些说明文字对客户如此重要吗?
BA_(d)是的?/font>
徐昊_(d)Z么?它主要有哪些内容Q?/font>
BA_(d)有标题,单说明以?qing)图片的版权信息Q最重要的就是版权信息,一定不能丢失?/font>
徐昊_(d)能不能这么说Q其实对客户最兛_的是版权信息?/font>
BA_(d)是的?/font>
于是问题解决。解x案是Q我们给文字定高Q同时将文字~小以容Ux可能多的字数Q这L(fng)站用户在PDF里看到的囄重新恢复了整齐,管看不太清囄说明文字Q但是用L(fng)正关心的是图片,谁关心哪些无处不在的版权信息呢?你可能会(x)说了Q看不清版权信息怎么行?q好Q你问的不是Q版权信息有那么重要吗。回{是Q这里是PDFQ移动你的鼠标到ZoomQ点M拉框Q点?/font>150%以上的选项Q然后,你会(x)惊讶的发玎ͼ那些该死的版权信息到处都是?/font>
BA的职责是帮客户发现的问题Q开发h员的职责是解决问题,QA的职责是校验最l的实现是否能够解决客户的问题。具体到一个用h事上Q就?/font>BA~写用户故事Q?/font>DEV~码开发,QA验收用户故事Q这是三个Q务,很明显,q三个Q务有一个非帔R要的׃n信息Q这个信息就是用h事所要实现的客户价|卛_客户解决的问题)(j)。围l着客户价|每次q代开始前Q团队都?x)进行P代计划会(x)议,所有成员会(x)跟随BA逐一审核各个用户故事Q围l着客户价|开发h员开发中随时可以?/font>BAq行沟通,p计问题进行讨论;围绕着客户价|开发h员每开发完成一个故事,BA、开发h员和QA׃(x)在一赯行一个微?/font> ShowCaseQ在期间讨论用户故事的实现是否实C客户价|大家对用h事的理解是否一致?/font>
那么Q在相关的Q务之间需要能够定义变量,q些变量数据能够在这些Q务间׃n?/font>
描述
一定的d范围能够定义变量Q在一个流E实例里Q该范围所包含的Q务实例能够用该变量?/font>
?/font> 6-4d范围U别的数据可见?/font>
如图6-4所C,我们划定了一个Q务范_(d)该范围包含了dA、Q?/font>B和Q?/font>CQ同Ӟ我们在该d范围内定义了一个变?/font>MQ那么,在一个流E实例里Q只有Q?/font>A?/font>B?/font>C的实例在q行期能够用该变量QQ?/font>D?/font>E的实例都不能讉KQ不可见?/font>
可以看到d范围和块d在概念上比较怼Q都是包含一pd的子dQ它们之间的差别在于Q块d一般具有比较独立的执行上下文和业务语义Q而Q务范围则是对h相同执行上下文的d的一U分l?/font>
在工作流pȝ里,Ҏ(gu)EQ务进行分l的好处在于Q可以ؓ(f)特定的一lQ务绑定数变量、异常处理器和补偿动作。例如在?/font>6-4中,如果dA?/font>B?/font>C中的M实例执行p|Q那么我们就认ؓ(f)整个d区域执行p|Q将l一执行一个业务补偿行为,同时Q这些Q务共享一个异常处理器?/font>
实现
?/font>jBPM4里,程定义模型相比jBPM3最大的变化x引入了Q务嵌套的概念Q一个Q务能够包含多个其他Q务,q里的父d卛_充当d范围的定义?/font>jBPM4针对q种嵌套的Q务徏立了一套处理机Ӟȝ来说是建立dq行期的嵌套关系Q查扑֏量时首先?x)在dU别q行查找Q如果找不到Q则?x)依ơ向上查扄d实例Q直xE实例别变量,同时Q父d可以l一l定异常处理器和事g动作。在后箋jBPM4的章节,我们会(x)详细分析该机制的实现l节?/font>
在一个典型的目团队里,包括了以下几U角Ԍ帽子Q:(x) PMQ项目经理)(j)? BAQ业务分析师Q? DEVQ程序开发者)(j)? QAQ质量保证h员)(j)Q整个团队的目标是向客户交付价倹{?
那么Q有一天, QA MM来找我,我是开发h员? MM_(d)一张图片没有正常显C,我想知道原因Q同时想知道你能否修复。我的第一x是,q不可能Q一定是环境的原因。我_(d)好的Q稍{。接下来Q我张大嘴巴看到? MMl我重现? BUGQ本该显C图片的位置一片空白,像此时我合不上的嘴。这怎么可能呢?我想Q这个功能完成的如此之得意,以至于测试用例里的数据都是以我的名字命名的?
几分钟后Q或者更长,我叫? MMQ说Q找到原因了?
我打开~辑器,光标在源E序的某一行闪烁,我说Q最Ҏ(gu)的原因在q里。我看到 MM的眼中闪q一丝迷茫。接下来Q我却换到另外一个源文gQ光标l闪烁,我说Q这里的E序因此受到影响。看得出Q? MM有点发晕。终于,当我打开W? N个源文gq试囄l讲解时Q? MM昏过M?
? MM苏醒q来Ӟ我在Ҏ(gu)澈的双眼中看C一只清晰的唐僧?
MM肯定感到了不好意思,因ؓ(f)我的讲解中包含了比喻、类推、排比等我力所能及(qing)的各U语文知识,看得出,我很努力Q我的语文老师也很努力Q所以她委婉地说Q能不能单一点?
我想了想Q说Q测试驱动时试数据不全DE序考虑一U情c(din)?
MM_(d)能修复吗Q?
我说Q可以。于是故事结束?
? 是这P当我们执行一Q务时Q围l这Q务必然会(x)产生许许多多的信息,q些信息对于该Q务的执行者是必须的,但是对于其他人则不是Q有效的沟通往往来自 于简l的表达卛_表达Ҏ(gu)需要和可以理解的内容,瀚的l节只会(x)真正想表达的内Ҏ(gu)没。其实这里还有这样一层意思:(x)我之所以用q么多的l节信息来?/span> QAQ实际上是不太情愿承认程序里? BUG? QA惌的结果很单,是否是程? BUGQ能否修复。而开发h员则往往把自qE序与自己关联在了一P认ؓ(f)E序是自q扩展Q程序有 BUG则意味着自己有缺陗这一关系明显是矛盄Q可是一些团队里开发h员和 QA能够和^相处Q而有些团队却势如水火?
那么Q对于单个Q务而言Q需要定义自q变量Q这些变量数据只与该d相关Q只在该d里可见。典型的工作应用于d执行期间的中间数据存储。在文档处理中,一个重要的功能是需要提供版本管理,在单个Q务实例里Q办理者能够管理自己处理过的文档版本?
描述
d能够定义变量Q在一个流E实例里Q该变量只能被其d实例所使用?
? 6-2dU别的数据可见?
如图 6-2所C,我们在Q? B上定义了一个变? MQ此Ӟ在一个流E实例里Q只有Q? B的实例才能用该变量?
实现
存在两种实现方式Q一U是如图 6-1所C的Q在d节点定义中声明变量,q行期初始化d实例的同时初始化该变量ƈ使用Q? 另一U是在流E定义别统一声明变量Q但是各个Q务实例都独立初始化ƈ存储该变量。第二种实现方式在各个Q务都需要用同一语义的变量时很常见,例如各个d实例都会(x)有参与者,我们在流E定义时声明一个名?/span> userid的变量,在流E实际执行时Q各个Q务实例都?x)独自保存有自己? userid数据?
{等Q这个故事和本章的主?/font>-? 据模式有一毛钱的关p?q只是一个关于沟通的故事。是的,让我们稍微映一下:(x)q里Q晚饭这个流E包含了两个基本的Q务,分别是做饭和z碗Q在做饭q个? 务完成时QQ务的执行者(老婆Q向下一个Q务的执行者(我)(j)传递了数据Q要z哪些东西)(j)Q正如语a是h之间的沟通方式一P数据?/font>ITpȝ之间的沟通方式,语言之间的沟通L最有效的,数据交互却未必,因ؓ(f)ITpȝ里的数据交互除了让计机理解外重要的是还需要h理解Q?/font>ITpȝ是对现实生活的映,也正因ؓ(f)如此Q现在数据之间的沟通也在向语言靠拢卌义化Q?/font>REST/语义|)(j)?/font>
好,a归正传?/font>
? 前两章里Q我们分别讨Z工作的控制模式和资源模式,控制模式x于如何合理调配业务流E里的Q务,从而获得理想的执行效率和收益;资源模式则关注于? 何合理调配可用的资源来执行业务流E。本章将介绍工作系l里的数据模式,从数据的角度分析工作系l对数据的处理。数据模式共?/font>39U,在下面的介绍中,我们这些模式分Z四部分,分别是数据可见性、数据交互、数据传输和Z数据的\由?/font>
本章先会(x)概要重复一下与数据模式相关的一些基本概念,例如程定义、流E实例、原子Q务、块d{。接下来?x)对具体?/font>39U数据模式进行讨论,讨论的模式按照应用、描q和实现展开Q分别对应着实际场景Ҏ(gu)式的映射、模式的介绍和工作流pȝ对该模式的实现支持。最后是结?/font>
一、基本概?/font>
1、工作流pȝ里的程l构
在正式介l数据模式之前,让我们先单回一下工作流pȝ里流E的基本l构?/font>
?/font> 6-1 工作系l里的流E结?/font>
程定义Q对业务程的徏模和描述Q其h_的细节信息,能够直接被工作流pȝ所执行。典型的Q流E定义由一pd的Q务组成,q些d以图形的形式展现q被q接h?/font>
程实例Q流E定义的一个执行实例被UCؓ(f)程实例。一个流E定义可以存在多个同时执行的程实例。这些流E实例互相独立执行?/font>
dQ一个Q务对应着程定义里的一个单一工作单元。存在四U不同类型的dQ原子Q务、块d、多实例d和多实例块Q务?/font>
原子d包含单且独立的Q务定义,当其初始化时只会(x)产生一个可执行的Q务实例?/font>
块Q务是一pdd的组合,典型的,工作系l里存在的子程dQ节点)(j)x块Q务,当一个块d开始执行时Q其流E控制权传递给与之对应子流E的W一个Q务,当子程完成执行后则控制权q回l块d。如?/font>6-1所C,块Q?/font>C对应着一个由dX、Q?/font>Y和Q?/font>Zl成的子程Q实际执行时QQ?/font>C?x)触发Q?/font>X的执行,dZ执行完毕卛_程执行完成后则?x)触发Q?/font>C执行完成?/font>
多实例Q务在实际执行时会(x)产生多个q行执行的Q务实例,q些d实例一般互相独立执行。当一定数量的实例执行完毕后即?x)触发后lQ务的执行?/font>
多实例块dl合了块d和多实例d的定义,其在实际执行时生多个Q务实例,每个d实例对应着一个子程实例?/font>
d实例QQ务的一个执行实例?/font>
2、数据相关约?/font>
我们使用def var ${变量?/font>}定义数据元素Q同?/font>def var ${变量?/font>}的声明位|决定了变量的作用范围。如?/font>6-1所C,我们在Q?/font>C上定义了一个名?/font>M的数据变量,其的作用范围ZQ?/font>CQQ务别?/font>
我们使用use(${变量?/font>})表明对变量的使用Q?/font>pass(${变量?/font>})表明数据变量的传递。在?/font>6-1里,变量M从Q?/font>C传递至dE?/font>
对于变量的数据类型,典型的有String?/font>integer?/font>float?/font>boolean?/font>date?/font>time{,很多工作系l用序列化和反序列化支持存储Q意类型的数据cdQ如数组、集合、对象?/font>
3、类比的U定
在后l对各个模式的介l里Q我?x)围l一个项目团队的故事q行映射Q我们如此约定:(x)
程定义Q?/font>我们认ؓ(f)所有成熟的软g公司都会(x)建立起其完整q用的一套Y件开发流E,我们这套流E看作是q里的流E定义?/font>
程实例Q?/font>围绕着软g开发流E,我们?x)用这套流E来开始我们实际的软g开发项目,我们所有的软g开发项目都看作是开发流E的执行实例Q即程实例?/font>
dQ?/font>目开发过E中的各Q务?/font>
数据Q?/font>我们团队成员之间的信息交流看作是数据交互?/font>
提到程Q第一个问题就是流E的历史?/font>18世纪英国l济家学亚当·斯密在《国民胦(ch)富的性质和原因的研究》中提出“力_分工原理”Q提出分工有利于提高效率、增加量,其理由有三:(x)W一Q劳动者的技巧因业专而日q;W二Q分工可以免除由一U工作{到另一U工作的旉损失Q第三,化劳动和机械的发明一个h能做许多人的工作。亚?/font>·斯密的分工论蕴涵了最朴素的流E理c(din)流E生于一pd的分工?/font>
l基癄? 对业务流E进行了如下定义Q业务流E是为特定的对象Q客P(j)创造h(hun)值的q程Q这一q程׃pd相关联、有l织的活动或dl成。企业和l织中,业务程一 般被划分ZU基本类型:(x)理程Q对企业q行q行理、协调的程Q运行流E,构成核心业务和创造基本h(hun)值的程Q如采购、制造、市场销售等Q支持流 E,支撑理程和运行流E的程Q如?x)计、招聘、技术支持等?/font>
接下来我们关注工作流技术的历史。工作流技术发端于1970q代中期办公自动?/span>领域的研I工作,但工作流思想的出现还应该更早Q?/font>1968q?/span>Fritz Nordsieck已l清楚地表达了利用信息技术实现工作流E自动化的想法?/font>1970q代与工作流有关的研I工作包括:(x)宑֤法尼亚大?/span>沃顿学院?/font>Michael D. Zisman开发的原型pȝSCOOPQ?/font>施乐帕洛阿尔托研I中?/span>?/font>Clarence A. Ellis?/font>Gary J. Nutt{h开发的OfficeTalkpd试验pȝQ还?/font>Anatol Holt?/font>Paul Cashman开发的ARPANET上的“监控软g故障报告”E序?/font>SCOOP, Officetalk?/font>Anatol Holt开发的pȝ都采?/font>Petri|?/span>的某U变体进行流E徏模。其?/font>SCOOP?/font>OfficetalkpȝQ不但标志着工作技术的开始,而且也是最早的办公自动化系l?/font>
1970q? 代h们对工作技术充满着强烈乐观情AQ研I者普遍相信新技术可以带来办公效率的巨大改善Q这U期望不可避免的落空了。h们观察到q样一U现象,一个成? 的组l往往?x)在适当的时候创造性的打破标准的办公流E;而工作流技术的引入使得Z只能L的遵守固定的程Q最l导致办公效率低和h们对技术的反感?/font>1970q代工作技术失败的技术原因则包括Q在办公室?/font>个h计算?/span>未被社?x)接受?/font>|络技术还不普遍,开发者还不了?/font>g技术的需求与~陷。ȝ一下,工作应用失败的原因有两点:(x)W一Ҏ(gu)自动化流E的柔性低Q第二点则是限于当时的技术原因?/font>
q入1990q代后,随着IT技术的发展、个机的普?qing),工作技术开始重新进入一个新的热潮,q个热潮完全是技术驱动的Q这时候出C大量的工作流技术应用。需要注意的是,工作技术不仅仅是指专门的工作流理pȝQ同时也指拥有工作流特征的各U应用系l,例如各类企业理软gQ?/font>ERPQ和协作软g里有h的相应流E组件。工作流技术的应用使得很多应用软g的开发得C定程度的化(同时Q可以观察到工作品的采购客户往往?x)是pȝ集成商)(j)。需要注意的是,此时工作要解决的问题域依旧是实现工作流E的自动化,由此带来的应用局限ƈ没有发生变化?/font>
与此同时Q新的管理革命正在发生?/font>
1990q迈克尔·哈默在《哈?jng)商业评论》上发表了题为《再造:(x)不是自动化改造而是推倒重来?/font>(Renglneenllg workQ?/font>don"t automateQ?/font>obliterate)的文章,文中提出的再造思想开创了一场新的管理革命?/font>1993q迈克尔·哈默和詹姆斯·q在其著作《企业再 造:(x)企业革命的宣a)(Reengineering the CorporationQ?/font>a Manifesto for Business Revoiution) 一书中Q首ơ提Z业务程再?/font>(BPRQ?/font>Business Process Reengineering)概念Qƈ其定义为:(x)对企业业务流E进行根本性的再思考和d性的再设计,以取得企业在成本、质量、服务和速度{衡量企业W 效的关键指标上取得显著性的q展。该定义包含了四个关键词Q即Q?/font>“程”?/font>“Ҏ(gu)?/font>”?/font>“d?/font>”?/font>“显著?/font>”?/font>
以此为标 志,形成了新的业务流E理念,q伴随着对传l企业金字塔式组l理念和理模式的反思,新的理念企业以业务流Eؓ(f)中心q行q作、打破传l的部门隔阂、增 加客户h(hun)值和企业效益Q降低成本)(j)。以业务程Z心取代职能分工,成ؓ(f)理的首要原则,围绕程建立h的组l具有更高的敏捷性、效率和效益Q呈现出? q_、网l化的特征?/font>
新的理理念催生新的IT产品Q?/font>BPM产品孕育而生。可以说一个好?/font>IT? 品L对应有相应的理论基础Q那U简单的对现有工作方式的复制化是没有生命力的Q一个小的而典型例子是?sh)子印章软gQ从布局到排版都很逼真。可是现实中? 章的设计是ؓ(f)q行文g的状态确认,非常直接Q但是在?sh)脑上摹仿这U印章,不但用着别扭Q看着也十分难q,更重要的是,明明通过工作的控制已经能够认? 件的状态,却一定要通过?sh)子印章来生模拟。)(j)。很多技术h员以XPDL?/font>BPEL来区分流E品是工作还?/font>BPMQ认?/font>BPM更ؓ(f)软g的系l集成能力?strong>实际上,工作Y件与BPM软g最大的区别不在于技术实玎ͼ而是它们解决的问题域发生了变化?/font>
工作Y件解决的问题域是程的自动化Q?/font>BPM软g解决的问题则是业务流E的优化?/font>
因ؓ(f)解决的问题域发生变化Q那?/font>BPM软g相比工作Y件在技术上的变化就很清CQ强调对程q行的监控、强调对程q行数据的分析、强调对各种企业应用软g的集成能力、强调快速的开发能力。实际上很多BPM软g的前w即是工作流产品Q从技术角度上理解Q工作流软g?/font>BPM软g是没有区别的Q?/font>BPM软g是工作流软g发展的结果,只是开发商Z市场的考虑换上一个不同的标签而已Q非常类g当前的药品市场,同一U成分换个名U就变成新药Q。然而从处理问题的角度考虑Q区别两者则又是必要的?/font>
但是BPM软g面(f)的问题依旧存在,因ؓ(f)很多BPM软g解决问题的思\q不正确Q很?/font>BPM软g依旧是通过自动化流E来实现业务程的优化,q再ơ回到工作流软g所面(f)的问题:(x)企业很多业务程很难自动化、自动化程的柔性很低。对于这些问题,BPM软g试图通过化编E(快速开发?/font>SOA思想Q和pȝ集成来尽可能自动化多的流E,通过增强程定量分析能力来尽可能的增加流E柔性。这实际上是在用正确的方式做错误的事Q因决问题的思\从一开始就军_了这q不是一条正的路?/font>
相比而言Q?/font>Nimbus?/font>Control-ES软g则选择了另外一条道路,它ƈ不强调流E的自动化,它是从咨询Y件发展而来的,q决定了其解决问题的另外一U方式:(x)对现有流E的评估和重构而非自动化。在Control-ES里,程是作Z业胦(ch)产保存的Q仅仅文档化。这几乎立刻扩大了其对业务流E的描述能力Q但是其的咨询背景也军_了它的局限性:(x)无法实时获取业务程执行的数据(完全依靠咨询人员的工作)(j)Q于?/font>Control-ES更多是作为咨询h员的工具而存在的。从某种意义上说Q流E改q本来就是一咨询工作,很多IT厂商甚至没有M业务领域l验Q拿出其BPM软g宣传能够实现客hE的优化是一件很搞的事情Q很多所谓的程梳理实际仅仅是对现有程的复制再玎ͼ没有M改进可言?/font>
一U更好的方式是文档化所有业务流E,然后通过pȝ集成能力实时获得关键的数据信息,实现以流Eؓ(f)中心的数据撮合,关键的流E执行和改进则交׃hȝzL行。对q种实现思\我们在本书的最后部分进行讨论。可以看见的是,程优化从来也不应该?/strong>ITpȝ能够完成的事情,ITpȝ所要做的是为流E优化撮合必需的数据,做ؓ(f)支撑pȝ而存在?/font>
说完BPM软gQ最后我们需要关注的一个方向是云计。越来越多的企业其工作攄C|上Q典型的?/font>Google提供的各U在U服务,文档、邮件?/font>Excel{,q种势触发了新的业务模式,云中的工作流x其中一U,通过提供在线的工作流E自动化Q将各种在线服务通过程_合h。在q方面,Cordys走在了最前面?/font>
本章讨论的控制模式共?/span>43U。需要注意的是,q些模式的出发点是基于对实际业务q行描述的,与具体的工作系l没有太大的兌。而一个工作流pȝ对工作流模式的支持程度则直接军_了该pȝ对业务的建模能力。所以在某种E度上,衡量一个合适的工作系l时Q往往?x)考虑其对工作模式的支持E度?/span>
本章讨论的控制模式按照描q、应用和实现展开Q分别对应着模式的介l、模式对实际业务的映和工作品对该模式的实现支持。最后是结。作为约定,我们业务流E里的活动映ؓ(f)dQ将Ҏ(gu)动的建模描述映射ZQ务节炏V?/span>
一?span style="font-family: "Times New Roman"; font-style: normal; font-weight: normal;">
基本控制模式基本控制模式包括5个模式,是其他控制模式的基础?/span>
1?strong>序Q?/span>WCP_01: SequenceQ?/span>
描述
在同一个流E实例里QQ务会(x)在前lQ务完成后序触发?/span>
如图4-1所C,dA执行完毕后会(x)序触发dB的执行,dB执行完毕后会(x)序触发dC的执行?/span>
同义?/span>
序执行、串行\由?/span>
应用
序模式是工作流建模的基Q是程定义里最基本的构建块Q用以描q连l串行的一pddQ这些Q务之间的触发是无条g的?/span>
序模式也是实际的业务中应用最多的模式Q? 当实C个业务h(hun)值需要执行多个Q务时Q最自然的方式就是排序ƈ序完成q些dQ典型的如流水线作业。当企业人数不多Q业务模式简单(不需要过多的d 或Q务之间存在很强的U性依赖关p)(j)Q管理成本很低时Q顺序模式是最自然的选择?/span>
2?strong>q发分裂Q?/span>WCP_02: Parallel SplitQ?/span>
描述
分支分裂Z个或多个后箋分支Q当分支执行完毕后触发后lƈ发分支的同时执行。ƈ发的分支有可能在后箋合ƈZ个分支,也可能不合ƈ?/span>
?/span> 4-2
如图4-2所C,dA完成后将同时触发dB和Q?/span>C的执行,dB和Q?/span>C的执行不存在前后关系?/span>
同义?/span>
AND-split?/span>Fork、ƈ行\由、ƈ行分裂?/span>
应用
在传l的软g开发里Q开发过E被典型的分Z5个阶D,如下图所C:(x)
?/span> 4-3
q?/span>5? 阶段是顺序执行关p,典型的当需求分析完毕后?x)有一个需求冻l状态,在这U状态下才开始正式的软g设计和实现。该模式最大的弊端在于在需求分析阶D不可能 捕获用户所有可能的需求,而且客户的需求是变化的,开发阶D는于需求冻l对于客户完全黑盒,D最后的交付无法实现客户期望的业务h(hun)倹{?/span>
在敏捷开发里Q开发过E由多个q代l成Q在每个q代里,需求分析、架构设计、编码开发、测试和交付都是同时q行的,客户参与到这个过E中Q客戯够从不断的交付中提出新的需求,q样软g才能够更好的响应变化Q不至于在最l交付时出现业务价值的偏差?/span>
?/span> 4-4
其实从某U角度上看,不同企业的组l管理结构也军_了它所采用的业务流E模式。在?/span>4-3所 C的开发流E里Q每个阶D都对应于不同的部门Q需求分析有专门的业务部门,开发部门内部分Z架构部门、开发部门和试部门Q交付则又有专门的实施团队, 在这U情况下Q从理的成本考虑Q顺序执行无疑是最自然和最便宜的选择Q这也是Z么在传统企业里实施敏捷困隄原因之一Q?/span>
而在敏捷开发团队里Q整个团队则是围l开发流E徏立,减少了内部不必要的协调沟通成本,能够辑ֈ相对较高的执行效率?/span>
实现
׃后箋分支的触发是无条件的Q所以在很多工作品的实现里省MAND-split节点Q直接由d节点q行分支分裂Q如下图4-5所C:(x)
?/span> 4-5
jBPM使用token记录当前程实例执行的位|ƈ触发{Q徏立vtoken的父子关pR如下图所C,?/span>AND-split节点每个q发的分支都?x)生一个新的子tokenQ当?/span>token到达AND-join节点后即可通过其访问到它的?/span>tokenQ再通过?/span>token遍历其子token卛_获得当前q发分支的执行情况ƈ实现合ƈ?/span>
?/span> 4-6
作ؓ(f)U定Q我们在后箋的说明中Q将?x)采?/span>token来指代当前流E实例所执行的位|?/span>
3?strong>同步Q?/span>WCP_03: SynchronizationQ?/span>
描述
两个或多个分支合qؓ(f)一个后l分支,当被合ƈ的分支都执行完毕后,后箋分支才被触发?/span>
?/span>4-7
如上图所C,当Q?/span>A和Q?/span>B都完成后Q才?x)触发Q?/span>C的执行?/span>
同义?/span>
AND-join、汇聚、同步?/span>
应用
在实际的应用中,AND-split节点?/span>AND-join节点一般成对出现?/span>
在Q何时候,ȝL有必要的Q每ơP代开发结束后Q我们都?x)进行P代小l,写出应该改进的部分、应该保持的部分Q以保持整个团队的P代前q?/span>
实际上,很多情况?/span>AND-split节点?/span>AND-join节点往往隐含着理意义Q上一U的理者在AND-split节点q行d的管理和下发Q在AND-join节点对Q务执行结果进行负责?/span>
实现
?/span>AND-split节点一P在部分工作流产品里,直接采用d节点q行分支合ƈQ如下图所C:(x)
?/span> 4-7
jBPM里,分支的合q实际是token的合qӞ?/span>token生命周期l止Q父token重新ȀzR?/span>
4?strong>排他选择Q?/span>WCP_04: Exclusive ChoiceQ?/span>
描述
分支分裂Z个或多个后箋分支Q当分支执行完毕后只能选择触发一个后l分支执行,卛_选一?/span>
?/span> 4-9
如上图所C,dA完成后将?x)选择触发dB或Q?/span>C的执行,dB和Q?/span>C之间只能选择一个执行?/span>
同义?/span>
XOR-split、排?/span>OR-split、条件\由?/span>
应用
程里的决策d。会(x)存在两种决策方式Qh为决{和pȝ决策。由人或一l系l设定条件根据流E执行情况作出后l执行\径的选择?/span>
实现
两种实现方式Q一U是?/span>XOR-split节点定义路由选择条gQ图4-10Q、一U是在后l{Uȝ上定义触发条Ӟ?/span>4-11Q?/span>
?/span> 4-10
?/span> 4-11
条g的计有多种方式Q工作流变量与相应条件定义值简单匹配、提供接口由具体实现c返回计结果、规则引擎进行规则匹配计。同Ӟ当存在多个后l分支和条g判断Ӟ一般会(x)定义一个默认执行分支?/span>
5?strong>单合qӞWCP_05: Simple MergeQ?/span>
描述
两个或多个分支合qؓ(f)一个后l分支,M一个分支执行完毕后׃(x)触发后箋分支的执行,不需要同步,遵@先进先出的原则。需要注意的是:(x)该模式有个前提条Ӟ卛_l分支有且只有一个会(x)执行?/span>
?/span> 4-12
如上图所C,dA或Q?/span>B只要有一个完成都?x)触发Q?/span>C的执行,但是dA和Q?/span>B有且只有一个可以执行。如果Q?/span>A和Q?/span>B都有可能执行Q则变ؓ(f)另外一个模式:(x)多合q模式(WCP_08Q?/span>
同义?/span>
XOR-join、排?/span>OR-join?/span>merge?/span>
应用
在实际的应用中,Z证该模式的前提条Ӟ一?/span>XOR-join节点?/span>XOR-split节点成对使用?/span>
实现
?/span>AND-join节点一P因ؓ(f)不需要Q何条件判断,所以在部分工作品里Q直接采用Q务节点进行分支简单合qӞ但是需要和AND-join做出区别Q如下图所C:(x)
?/span> 4-13
6?strong>基本控制模式结
基本控制模式非常单,实现h也没有太大的隑ֺ。需要注意的是,对于一U模式往往?x)存在多U实现方式,W者的是:(x)条件判断的节点独立出来Q由其负责条件计和路径选择Q而Q务节点则只关注于实际业务的执行,做到职责分离。例如,AND-split?/span>AND-join?/span>XOR-split?/span>XOR-join节点都会(x)单独存在?/span>
可以看到Q除?/span>AND-split?/span>AND-join? 点,序、排他选择、简单合q模式组合的程和我们编写程序的逻辑程N常的怼Q也是q三U模式能够对E序的逻辑程图进行徏模。于是一件有意思的 事情出现了:(x)有快速开发^C品用流E引擎来~排E序逻辑。他们的做法是将l粒度的代码逻辑装构Ӟ然后再通过程的可视化~辑器将q些q算? 件粘合v来。这P传统方式下采用代码实C务逻辑的过E变成了LE图的过E。笔者认L(fng)实现存在相当大的弊端Q相当不合理。首先,~写代码变得? 杂了Q明明几十行代码能够实现的逻辑却需要经q编写构件、绘制程序流E图、部|Ӏ运行好多步才能实现Q编E效率可以想象;其次是代码的执行效率低,E序? q行需要经q一ơ流E定义的解释才能执行Q然后是q种实现完全牺牲了语a自n的特性,面向q程Q很难提供代码别的单元试环境Q只能提供有限的调试。该 实现实际上是定义了一U简单的程语言Q通过该流E语a来进行功能函敎ͼq算构gQ调用的~排。Q务编排没有问题,服务~排也没有问题,但是如果~排l粒 度到功能函数Q那么就出了流E引擎的作用域。提升编E效率的最好途径L语言而不是工兗?/span>
在前面的资源模式里,我们讨论了创建模式、推模式和拉模式Q它们实际对应着工作的一个正常生命周期:(x)创徏、提?/span>/指派、资源选取开始执行。在前面的讨论里Q工作项的执行都是由资源驱动的(从工作项待办列表里选取执行Q,而自动开始模式则提供了一U系l驱动工作项执行的方式,pȝ直接驱动工作Ҏ(gu)行往往表明了该工作的最高优先Q需要马上开始执行?/span>
?/span> 5-42
如图5-42所C,自动开始模式对应着U线标识着的工作项的状态变q,共有4U模式:(x)创徏x行、指z֍执行、成堆执行和铑ּ执行?/span>
1、创建即开始执行(WRP_36: Commencement on CreationQ?/span>
描述
资源能够在工作项一创徏完毕开始执行?/span>
?/span> 5-43
如图5-43所C,dA工作一创徏插入员工甲的办理列表,需要员工甲马上开始执行?/span>
应用
该模式应用在关键的优先高的d里,通过pȝ推送,强制资源优先执行该Q务,省去d的等待时间?/span>
实现
该模式的实现实际是系l同时完成了工作的创徏和推送,pȝ需要确定具体的执行人,工作不?x)分配给角色、岗位等资源l以提供l相应资源进行选择?/span>
2、指z֍开始执行(WRP_37: Commencement on AllocationQ?/span>
描述
资源能够在工作项一指派完毕开始执行?/span>
?/span> 5-44
如图5-44所C,dA工作一旦被员工甲从可拾取列表拾取就马上插入员工甲的办理列表Q需要员工甲马上开始执行?/span>
应用
该模式蟩q了工作的指派状态,实际是对? 建即开始执行模式的扩展Q在创徏卛_始执行模式里Q工作项必须预先定明确的执行hQ不能分配给角色、岗位等资源l,而在该模式里除了支持创徏卛_始执? 模式里的情况Q同时也提供了对q种情况的支持,工作可以提供给多个资源拑֏Q一旦一个资源拾取则必须马上开始执行(从这个角度看Q该模式与资源驱动执?/span>-提供工作Ҏ(gu)式是相同的)(j)?/span>
3、成堆执行(WRP_38: Piled ExecutionQ?/span>
描述
资源能够成堆执行相同d的不同工作项?/span>
?/span> 5-45
如图5-45所C,员工甲有多个dA的工作项需要执行,q些注意的是Q这些工作项q不是由一个Q务实例所产生的,它们属于不同的流E实例,是由多个程实例里的dA生成的。一旦员工甲开始Q?/span>A工作的执行Q那么他执行所有Q?/span>A的工作项Q即Q?/span>A相关的工作项全部打包执行。这一功能ql驱动,pȝ与dA相关的工作项依次推送至资源的办理列表?/span>
应用
开发h员甲熟?zhn)持箋集成工具Q此时同时有多个软g开发项目需要搭建持l集成环境。一旦他为某个项目组搭徏了持l集成环境,那么处于执行效率的考虑Q最好的方式无疑是他一鼓作气将所有的持箋集成环境都搭建完毕?/span>
相同/怼的工作交由同一资源一q执行,q些工作h完全或大部分怼的执行上下文Q相同的知识、能力要求)(j)Q从q个角度能够辑ֈ最高的工作效率?/span>
实现
pȝ需要在q行工作状态变q操作时提供相应的钩子,以进行相应的回调操作?/span>
4、链式执行(WRP_39: Chained ExecutionQ?/span>
描述
在一个流E实例里Q当前一个Q务的工作Ҏ(gu)行完毕后Q能够自动开始执行下一个Q务的工作V?/span>
?/span> 5-46
如图5-46所C,dA和Q?/span>B是两个连贯的dQ它们都分配l员工甲执行Q当员工甲执行完毕Q?/span>A的工作项后,dB生成的工作项马上被pȝ发送至员工甲的办理列表Q员工甲需要马上办理?/span>
应用
该模式实际是资源胶黏在一个流E实例上Q同hZ执行效率的考虑Q两个Q务位于同一程实例里,h相同的执行上下文Q。该模式的应用具有前提条Ӟ(x)程定义Ӟq箋的Q务由相同的资源进行处理?/span>
七、可见性模?/span>
可见性模式讨论各U不同资源对工作的可见 性,不同的资源由于角艌Ӏ权限的不同Q对工作Ҏ(gu)有不同的可见范围。由于涉?qing)到权限Q那么根据不同的l织机构讄Q必然会(x)出现不同的工作项权限分配Q这? 不讨论具体的工作Ҏ(gu)限分配,仅从工作的状态来讨论q些工作区分可见性的必要性?/span>
可见性模式包?/span>2U:(x)未指z态工作项的可见性和指派状态工作项的可见性。实际上Q工作项处于执行状态或完成状态也存在不同的可见性?/span>
1、可配置的未指派工作的可见性(WRP_40: Configurable Unallocated Work Item VisibilityQ?/span>
描述
能够配置未指zַ作项的可见性?/span>
?/span> 5-47
如图5-47所C,可拾取列表里存在3个工作项QQ?/span>A工作VQ?/span>B工作和dC工作V员工甲可拾取的工作包括:(x)dA和Q?/span>B工作;员工乙可拑֏的工作项包括QQ?/span>B和Q?/span>C工作,那么由此产生的可见性是Q员工甲只能看到dA和Q?/span>B工作,而员工乙则只能看CQ?/span>B和Q?/span>C工作V而作为员工甲和员工乙的部门经理,他需要了解每个属下的工作情况Q所以他可以看见所有甲乙可见的工作V?/span>
应用
随着企业规模的发展,几乎所有企业的l织? 型都?x)Ş成金字塔型的l构Q一斚w是出于分工的需要,另一斚w则是Z理的需要,每一层的h员都需要对上一U负责,同时理下一层的h员。处于管? 的需要,理者必焉要了解下属的工作情况Q这h限就自然产生了,具体到工作流的Q务里Q管理者需要对其所理下属的工作具有可见性?/span>
其实不仅仅是对于工作,对于程实例本n 也具有可见性的分配。对程负责的h必然具备最大的可见性和权限Q流E根据Q务分解,如果仅仅只对某一d负责Q那么则只对该Q务具有可见性,而如果需? 对多个Q务负责,那么需要对多个dh可见性,最直接的负责h是具体执行该Q务的人员Q但是引入管理的层后,职责的承担也?x)Ş成层U的关系Q从? 至下层层承担Q此时担负最大职责的人员往往不再是具体的工作执行人员Q而是相应的管理h员?/span>
实现
在前面所描述的情况里Q支持员工甲乙的可见性是比较单的Q因为每条工作项记录都携带有参与者信息,但是部门l理昄不在q些参与者信息里Q所以需要引入与l织权限模型相匹配的工作Ҏ(gu)询机Ӟ即不同于工作列表的查询列表?/span>
2、可配置的指zַ作项的可见性(WRP_41: Configurable Allocated Work Item VisibilityQ?/span>
描述
能够配置已指zַ作项的可见性?/span>
?/span> 5-48
如图5-48所C,待办列表里存?/span>3个工作项QQ?/span>A工作VQ?/span>B工作和dC工作V指z员工甲的工作包括:(x)dA和Q?/span>B工作;指派l员工乙的工作项包括QQ?/span>C工作,那么由此产生的可见性是Q员工甲只能看到dA和Q?/span>B工作,而员工乙则只能看CQ?/span>C工作V而作为员工甲和员工乙的部门经理,他需要了解每个属下的工作情况Q所以他可以看见所有甲乙可见的工作V?/span>
八、多资源模式
到目前ؓ(f)止,我们讨论的工作项都是与某一特定资源一一对应的,即一个工作项只能׃个单一资源执行Q或者严格来_(d)一个工作项在Q何时间段都只能由一个单一资源执行Q考虑到工作移交的情况Q;同时Q一个资源在M一个时间段都只能处理一个工作项?/span>
多资源模式将?x)讨ZU不同的情况Q一个资源同时执行多个工作项、多个资源执行同一个工作项?/span>
1、同时执行(WRP_42: Simultaneous ExecutionQ?/span>
描述
资源能够同时执行多个工作V?/span>
?/span> 5-49
如图5-49所C,员工甲的办理列表里有三个工作,他能够同时执行这三个工作V?/span>
应用
和计机一P虽然在Q何时刻都只能处理一工作,但是通过多工作切分成多个U程交替执行Q从某个旉D늜Qh能够同时处理多项工作?/span>
够选取相关联的多个工作Q同时开始执行,在执行的q程中,合理安排q些工作的执行时机和序?/span>
实现
几乎所有的工作系l都不会(x)U束人员往自己的办理列表里增加多个工作V?/span>
2、增加资源执行(WRP_43: Additional ResourcesQ?/span>
描述
资源能够要求增加资源来处理他正在执行的工作项?/span>
?/span> 5-50
如图5-50所C,员工甲和员工乙同时处理一个工作项?/span>
应用
在一些复杂的场景里,一工作往往需要多个资源共同协作完成?/span>
典型的在一个会(x){Q务里Q一个发文需要多人签字通过Q同时在?x)签q程中,l常出现动态加{情况Q需要新的h员加入进行签字?/span>
在敏捷开发里Q所有的开发工作都是由两个开发h员共同结对完成?/span>
实现
工作作为工作流pȝ里最的工作单元Q如果将其分配给多个资源Q无疑会(x)增加~程模型的复杂度。最常见的实现方式是增加工作,一个Q务节点对应多个工作项Q对于需要增加资源的情况Q增加工作项?/span>
?ji)、小l?/span>
在本章里Q我们讨Z工作的43U资源模式,q些模式分ؓ(f)7c,分别是创建模式、推模式、拉模式、折回模式、自动开始模式、可见性模式和多资源模式?/span>
创徏模式在系l创建工作项时生效,其位于工作项生命周期的创建阶D,创徏模式作ؓ(f)程模型的构成部分在程设计期指定,通常在Q务节点的定义里进行定义,与一个Q务关联,其用来限定可执行该Q务的资源范围。系l根据创建模式限定的资源范围生成工作V?/span>
接下来,pȝ需要将工作Ҏ(gu)送给相关的资源进行执行,q个推送的q程x推模式所包含的内宏V工作流pȝ通过工作管理器即不同类型的工作列表与用户q行交互Q这里的推送可以理解ؓ(f)pȝ生成的工作Ҏ(gu)送至相应资源的工作项列表里?/span>
推模式的主语是系l,ql将工作Ҏ(gu)送至资源的工作项列表Q那么,接下来的d权交由单个资源本w,由其拉动工作的执行Q这是拉模式所包含的内宏V?/span>
实际工作中,工作的执行状态不可能L与预想相W的QM(x)出现各种各样的情况,例如重新分配、重做、挂L(fng){。折回模式对应着q些情况Q折回代表着工作状态的反复、回退?/span>
自动开始模式提供了一U系l驱动工作项执行的方式,pȝ直接驱动工作Ҏ(gu)行往往表明了该工作的高优先Q需要马上开始执行?/span>
可见性模式讨论各U不同资源对工作的可见性,工作自w作源与权限相关?/span>
多资源模式讨Z个资源执行多个工作项和多个资源执行同一个工作项的情c(din)?/span>
从这些模式的讨论可以看出Q这些模式更多关 注的是对实际业务执行的场景描qͼx通过合理分配d和调配工作的执行为组l带来最大的执行效率。从另一个角度看Q由于这些模式都以业务作为出发点Q这 l工作流pȝ的实现带来了复杂性,很多模式当前的工作流pȝ都无法完全支持或直接支持。在很多情况下,模式的支持需要很多的U束Q而这U约束往往需要在? 作流实施阶段l合客户具体情况q行限定Q这实际了工作流实施的重要性,工作系l的应用是由工作品加实施两部分组成,很多时候,实施占据了更大的 比重Q这对工作品的可扩展性提Z要求。应用工作流不仅仅是选择工作品,更重要的q包括选择合适的实施团队?/span>
在下一章里Q我们将讨论另外一U工作流模式-数据模式?/span>
实际工作中,工作的执行状态不可能L与预想相W的QM(x)出现各种各样的情况,例如原本分配l员工甲的Q务由于甲要请假不得不重新分配Q由于新的紧急Q务员工乙当前的工作需要挂起一D|间等{。折回模式则刚好对应着q些情况Q折回代表着工作状态的反复、回退?/span>
?/span> 5-33
如图5-33所C,折回模式对应着U线标识着的工作项的状态变q。这些状态变q对应着以下情况Q?/span>
委派Q资源将先前指派l他的工作项委派l他人执行?/span>
pȝ重新分配Q系l将没有完成的工作项重新提供或指z其他资源执行?/span>
退回指z?/span>Q资源撤销指派l他的工作项Q工作项可以重新指派l其他资源?/span>
工作UMQ资源将其已l开始执行的工作移交给他h执行?/span>
挂v/恢复执行Q资源(f)时挂起当前执行的工作,q在某一个时候重新恢复执行该工作V?/span>
跌Q资源选择跌指派l他的工作项的执行,不执行该工作V?/span>
重做Q资源重新执行先前已l完成的工作V?/span>
提前执行Q资源在程实际触发该工作前已经开始执行该工作?/span>
折回模式共有9U?/span>
1、委z(WRP_27: DelegationQ?/span>
描述
资源能够先前指z他的工作Ҏ(gu)z另外的资源执行?/span>
?/span> 5-34
如图5-34所C,委派对应于红U标识着的工作项状态变q?/span>
应用
委派在^常工作中非常常见Q例如员工甲要请假Q他他要完成的工作委派l同事乙执行Q在协同办公里,领导相兛_作委z下属执行{等?/span>
实现
实际应用中,委派按照_度分ؓ(f)了两U:(x)一U? 是工作项的委z,q是一U细_度的委z,指单一d实例的委z,与某一特定的Q务实例关联;另一U是业务的委z,q是一U粗_度的委z,例如Q员工甲其 负责的某cM务的工作全部委派l员工乙Q这意味着属于q类业务的所有工作都由员工乙执行。业务的委派通常与权限紧密关联,实际实现时ؓ(f)避免用户权限的 淆,一般采取分开dpȝ的方式进行实玎ͼ卛_工乙如果惛_理员工甲委派l其的工作,则需要用员工甲的账号和其l定的密码重新登录系l,q注销掉自p̎? 的用?/span>
需要注意的一Ҏ(gu)Q委z意味着原先指派的资源还必须对该工作负责Q例如员工甲某工作委z员工乙执行,管员工乙实际执行了该工作,但该工作仍然必须由员工甲负责。所以在实现中,员工甲必能够保持对委派工作的q踪和控制?/span>
2、系l重新分配(WRP_28: EscalationQ?/span>
描述
pȝ能够重新分配已经分配的工作项Q以加快工作的执行?/span>
?/span> 5-35
如图5-35所C,工作原先提供或指派l了一个或多个资源执行Q现在由于各U原因,需要优化该工作的执行Q所以将该工作项收回重新分配Q提供或指派l其他的资源?/span>
应用
工作分配的优化。很多时候,计划跟不上变 化,工作也是q样Q分配工作前有许多的考虑因素Q例如个力、工作经验、技能要求等{,但在实际工作中往往?x)发现原先的人力分配q不合理Q或者有些h? 担了太多的职责,或者有力超出其目前担承的职责等{(在敏捯Y件开发里Q我们通过频繁的交换结对编E以辑ֈ部分的^衡)(j)Q在q种时候就需要对工作q行 灉|的重新分配以到达最高的执行效率?/span>
实现
实际实现中非常受限,Ҏ(gu)E的优化始终是一 个对人的命题Q而不是对机器对工L(fng)命题Q工h能做到的只是可能多的提供可供参考的数据模型Q例如各U报表、数据分析等{,最后做出决{的q是人。所 以该模式的实C以提供给程理员重新分配工作项的能力ؓ(f)主,同时提供工作超时的提示?/span>
3、退回指z(WRP_29: DeallocationQ?/span>
描述
资源撤销指派l他的工作项Q工作项可以重新分配l其他资源?/span>
?/span> 5-36
如图5-36所C,资源能够退回原先指z他的工作,该工作项可以交由pȝ重新分配l其他资源?/span>
应用
同样是工作分配的优化Q只不过该模式由资源驱动?/span>
实际工作中,׃各种原因Q例如经验不뀁当前承担职责过多等{,发现自己q不能很好完成当前的dӞ可以提出不执行该d?/span>
实现
实现的难点在于资源退回工作项后的重新分配Q即如何重新分配该工作项?/span>
与提供给多个资源模式对应Q该模式的最单支持是退回重新提供给多个资源。例如工作项分配l开发h员这一角色执行Q开发h员甲拑֏了该工作(故事卡)(j)Q经q一番痛苦和彷LQ最l将该工作项退回,q样所有开发h员又都能拑֏该工作项?/span>
4、有状态工作移交(WRP_30: Stateful ReallocationQ?/span>
描述
资源正在执行的工作移交给其他资源执行Q该工作的状态将得到保存?/span>
?/span> 5-37
如图5-37所C,资源已开始执行的工作UMl其他资源执行。该模式与委z模式很怼Q差别就在于委派模式是将未开始执行的工作q行重新指派执行Q而该模式则是已开始执行的工作q行重新指派执行。委z模式中的委z者仍需要ؓ(f)委派出去的工作负责,而移交则同时意味着责Q的移交?/span>
应用
工作UM非常常见Q最常见的原因包括位|调动、离职、休假等{?/span>
实现
在大多数的工作流pȝ实现里,业务数据与流E数据是怺隔离的,仅仅通过某一字段q行兌Q例如业务主键)(j)Q流E的目标是携带业务数据进行流转。在q种情况下,该模式的实现变成了默认实玎ͼpȝ不需要做M回退或清理操作,直接做工作项的{发即可?/span>
5、无状态工作移交(WRP_31: Stateless ReallocationQ?/span>
描述
资源正在执行的工作移交给其他资源执行Q该工作的状态不?x)得C存?/span>
与有状态工作移交对应?/span>
应用
工作的无状态移交通常意味着工作的重新执行,q且原有的工作对重启的工作而言没有太大的h(hun)倹{?/span>
实现
与有状态工作移交相比,该模式需要处理相应业务数据的回退或清理。直接支持该模式比较困难Q需要在实施时根据情况对该Q务节Ҏ(gu)作业务数据的权限q行限定Qƈ在限定的基础上进行记录和回退?/span>
6、挂?/span>/恢复执行Q?/span>WRP_32: Suspension/ResumptionQ?/span>
描述
资源能够挂v当前执行的工作项Qƈ在某一个时候重新恢复执行该工作V?/span>
?/span> 5-38
应用
资源对分配给其的工作q行优化执行Q能够根据自己和当前的实际情况合理的安排工作执行Q挂h在执行的工作Q执行当前最重要或效率最高的工作Q然后再q回执行该工作?/span>
实现
基本的状态变q?/span>
7、蟩q(WRP_33: SkipQ?/span>
描述
资源能够选择跌指派l他的工作项的执行,不执行该工作,q将该工作项标识为完成?/span>
?/span> 5-39
应用
实际工作中,对于非关键工作,可以选择跌Q以便进行后l更为紧急或重要的工作?/span>
实现
对于实现工作Ҏ(gu)w的状态变q来_(d)支持该模式非常简单,问题在于业务数据的依赖关p,如果后箋工作的处理依赖于该节点处理后的业务数据,那么单的选择跌该工作项的执行就?x)生问题。所以一个好的做法是l一些关键Q务节点加上约束,不允许执行蟩q操作?/span>
8、重做(WRP_34: RedoQ?/span>
描述
资源能够对先前完成的工作w新处理,同时Q该工作的后l工作项Q后lQ务所对应的工作项Q也被重新处理?/span>
?/span> 5-40
应用
对已完成的工作进行重新处理ƈ不少见,但该 模式最为重要的部分q是在于要求所有后l工作的重新处理。所以该模式一般应用在极其重要的关键Q务节点,例如非常重要的决{节点,因ؓ(f)后箋的Q务严重依? 于该节点所作出的决{(所产生的数据)(j)Q一旦决{发生变化,那么相应的后l工作必都要做出变化。这也是业务敏捷性的一U反映。同旉要注意,该模式也? 一U代价高昂的应用Q因往往意味着该业务流E实例中的很多工作都需要重新处理,所以如何在业务处理中尽早发现可能的环境变化q及(qing)时作出决{的调整q 免成本高昂的q工才是最为重要的一炏V?/span>
现在的Y件开发越来越于拥抱变化, 代码的重构和演进Q尽如此,如果软g的基架构需要根据当前业务变化发生重大变_(d)那么q依旧是一件成本高昂的事情Q因Z旦基架构发生变化Q那么很 多模块实现将不得不重新编写代码。所以尽越来越多的开发团队开始引入敏L(fng)开发方法,但是l验丰富的开发h员才是整个敏捷团队的基石Q敏捷开发非帔R? 人)(j)?/span>
实现
从该模式里能够看到资源模式与控制模式的结合,工作的重做需要后lQ务的重新执行Q这需要取消当前的执行dQƈ流E实例的控制炚w新返回至该工作项所对应的Q务。这涉及(qing)CU控制模式,分别是:(x)取消d模式和Q意@环模式(具体可以参考第四章的说明)(j)?/span>
9、提前执行(WRP_35: Pre-DoQ?/span>
描述
在工作项实际提供或指z资源执行之前Q资源已l可以执行该工作V?/span>
?/span> 5-41
如图5-41所C,dAq在执行QQ?/span>Bq未Ȁz,但此时员工甲已经可以开始执行Q?/span>B的工作项。该模式的实现需要一个前提条Ӟ(x)dB不能依赖于Q?/span>A的执行结果,即不能依赖于前箋d的处理输出?/span>
可以看出Q该模式与前面推模式里的提前分配模式非常怼Q所不同的是Q提前分配强调一U通知机制Q强调预先准备;而提前执行则已经可以开始实际的执行工作?/span>
应用
和提前分配模式不同,该模式实际提供了一U? 程d执行的灵zLӞ在预先定义的业务程里,d的执行是h一定顺序的Q可能在大多数情况下Q这U顺序是合理的,但是在某些具体的程实例里,? 些串行执行的d节点可以q行的执行以辑ֈ最好的执行效率和负载均衡,在这U情况下Q就可以应用该模式ƈ行执行部分Q务?/span>
需要注意的是,该模式仅仅引入了一U实际执行Q务的灉|性,是对业务程定义固化的补偿,如果在一个业务流E中频繁应用到该模式Q则往往意味着程定义本n需要作整?/span>
与推模式相比Q拉模式的区别在于动作的主语发生了变化:(x)推模式的主语是系l,ql将工作Ҏ(gu)送至资源的工作项列表Q那么,接下来的d权交由单个资源本w,由其拉动工作的执行?/span>
?/span> 5-28
如图5-17所C,拉模式对应着工作的五种状态变q:(x)
由提供给一个资源拾取到指派l一个资源负责执?/span>Q这意味着该资源拾取了该工作项Q其负责该工作的执行Qƈ在未来的某个时候执行该工作;
由提供给多个资源拑֏到指z一个资源负责执?/span>Q这意味着多个资源中的一个资源拾取了该工作项Q其负责该工作的执行Qƈ在未来的某个时候执行该工作,余下的资源将不再有机?x)执行该工作?/span>
由提供给一个资源拾取到开始执?/span>Q这意味着该资源拾取了该工作项Q其负责该工作的执行Qƈ立即开始执行该工作;
由指z一个资源负责执行到开始执?/span>Q这意味着该资源开始执行该工作;
由提供给多个资源拑֏到开始执?/span>Q这意味着多个资源中的一个资源拾取了该工作项Q其负责该工作的执行Qƈ立即开始执行该工作,余下的资源将不再有机?x)执行该工作?/span>
拉模式共?/span>6U,分ؓ(f)两组Q前三种模式x工作的状态变q;后三U模式关注工作项昄在资源工作项列表里的序以及(qing)选择执行的方式?/span>
1?strong>资源驱动指派Q?/strong>WRP_21: Resource-Initiated AllocationQ?/span>
描述
资源能够工作项指派l自己,负责该工作项的执行,但是不必马上开始执行该工作V?/span>
?/span> 5-29
如图5-29所C,员工甲拾取了可拾取列表里的Q?/span>A工作,该工作项由可拑֏列表U至待办列表。可拑֏列表通常是一个共享的列表Q而待办列表则是某一资源的专属列表。资源拾取工作项Q意味着工作从׃n状态进入到专属状态?/span>
该模式实际对应着工作的两种状态变q:(x)由提供给一个资源拾取到指派l一个资源负责执行;由提供给多个资源拑֏到指z一个资源负责执行?/span>
应用
该模式符合大多数的工作场景,我选择负责执行该工作,但我q不马上开始,我可能还有其他的工作需要处理,{到处理完毕后才处理该工作?/span>
实现
分配l角艌Ӏ部门等资源l的工作w常都以׃n的Ş式分配给所有的l内成员Q一旦有人拾取即q入他的专属待办列表Q其他h不再可见?/span>
2?strong>资源驱动执行-指派工作(WRP_22: Resource-Initiated Execution – Allocated Work ItemQ?/span>
描述
资源能够开始执行指z其的工作V?/span>
?/span> 5-30
如图5-30所C,员工甲开始执行Q?/span>A工作,该工作项由待办列表移臛_理列表?/span>
该模式对应着工作的一U状态变q:(x)由指z一个资源负责执行到开始执行?/span>
实现
最基本的工作项状态变q,所有的工作系l都提供支持?/span>
3、资源驱动执?/span>-提供工作(WRP_23: Resource-Initiated Execution – Offered Work ItemQ?/span>
描述
资源能够选取提供l其的一个工作项Qƈ马上开始执行该工作V?/span>
?/span> 5-31
如图5-29所C,员工甲拾取了可拾取列表里的Q?/span>A工作ƈ立刻开始执行,该工作项由可拑֏列表U至办理列表?/span>
该模式对应着工作的两种状态变q:(x)由提供给一个资源拾取到开始执行;由提供给多个资源拑֏到开始执行?/span>
应用
与描q略有不同,实际应用该模式是强制要求资源一旦拾取了׃n的工作项必马上开始执行,Z两点的考虑Q一是工作项能够快执行Q二是工作项能够指派l当前最为空闲的资源Q不?x)出现该工作被一J忙资源卡住Q造成{待和阻塞?/span>
在敏捷开发里Q我们用故事卡理目的开 发,故事卡够小Q如果大的故事卡则分解ؓ(f)多个dQ,每天早上由开发h员挑选移动该卡,一旦该卡由可开发状态移动至开发状态,则必进行该卡的开发工 作,q样目的真实进展随时得到显C,同时不允怸个开发h员同时进行多张卡的开发?/span>
实现
通过q三个模式我们可以发玎ͼ工作系l实现这些模式只是在不同的工作项列表里移动这些工作项Q以反映工作不同的状态和变迁{略Q这对于ITp? l而言q不是很困难Q困隑֜于如何能保证人确实是q么做的Q例如说一旦拾取就必须开始执行,工作的跌{很简单,但无法保证的是拾取该工作的Z定会(x)? 照要求马上开始执行该工作,也就是说业务程目的实施不仅仅包含技术实施,也包含了一套与之相应的理实施。那U期望上一套流E系l就能马上提高生? 效率和管理水qx然是不现实的Q其中一定包含管理方式的变化和组l机构的变化?/span>
敏捷开发中Q早上的站立?x)议是重要的部分Q每个团队成员都?x)汇报昨天的q展和今天将要进行的工作Q这样就保证了工作执行的有效性?/span>
4、系l决定工作队列内容(WRP_24: System-Determined Work Queue ContentQ?/span>
描述
工作系l能够排定资源工作项列表里的工作w序和内容?/span>
?/span> 5-32
如图5-32所C,员工甲共享的可拾取列表默认按旉排序工作V?/span>
应用
实际应用中工作项的排序条仉常多Q其目的是最重要或优先最高的工作Ҏ(gu)在最前面Q引赯源的注意或优先执行?/span>
实现
实际实现时有多种排序{略Q通常?x)有旉排序Q例如先q先出、先q后出等Q同时也有很多其他的排序元素Q例如工作项的预定完成时间、执行该工作的成本预算、工作项的优先或重要程度等Q系l查询工作项时根据这些媄(jing)响因素进行默认排序?/span>
5、资源决定工作队列内容(WRP_24: Resource-Determined Work Queue ContentQ?/span>
描述
资源能够排定其工作项列表里的工作w序和内容?/span>
应用
源提供一定程度上排定工作的灉|性。每个hx的视角和侧重点不同,׃(x)产生不同的排序和内容qo(h)?/span>
例如Q作板Q我可能更ؓ(f)x各个工作的成本预,我需要按成本排定各项工作Q而作为秘书,我更为关注老板下发各项工作的重要程度,我需要按老板指定的重要程度排定工作?/span>
实现
提供工作列表的客户端排序,一般情况下列表昄pȝl定的顺序,用户可以在客L(fng)q行二次排序Q典型的Webpȝ中,工作系l提?/span>JavaScript的表格控Ӟ利用Ajax异步h重新排序或进行工作项的过滤?/span>
6、自主选择Q?/span>WRP_26: Selection AutonomyQ?/span>
描述
资源能够Ҏ(gu)自己个h的情况选择执行工作V?/span>
?/span> 5-32
如图5-32所C,员工甲能够根据自q情况选择执行dA?/span>B?/span>C中Q意一个工作项?/span>
应用
管老板要求先实现功能最后再重构Q但是我认ؓ(f)当前代码如果不进行一定重构会(x)严重影响后箋的开发效率,所以我军_先进行部分重构?/span>
实现
几乎所有工作流pȝ都不?x)对用户实际选择执行工作的方式q行限制Q也没有办法限制。但是系l一般会(x)把重要的工作加以高亮显C,让用户优先选择?/span>
在创建阶D,pȝҎ(gu)不同的创建模式ؓ(f)d 节点产生了一个或多个工作,每个工作Ҏ(gu)分配l单个资源或分配l角艌Ӏ部门等。那么接下来Q系l就需要将q些工作Ҏ(gu)送给相关的资源进行执行,q个推? 的过E即是推模式所包含的内宏V需要注意的是,推模式讨论的是对单个工作的推送?/span>
在前面我们已l了解到Q工作流pȝ通过工作管理器即不同类型的工作列表与用户q行交互Q这里的推送也可以理解为系l将生成的工作项推送至相应资源的工作项列表里?/span>
?/span> 5-17
如图5-17所C,推模式对应着工作到三种状态的变迁Q提供给一个资源拾取执行;提供l多个资源拾取执行(q些资源中只?x)有一个会(x)实际执行Q属于竞争关p)(j)Q指z一个资源负责执行?/span>
推模式共?/span>9U,分ؓ(f)3l, W一l包括提供给单个资源、提供给多个资源和指z单个资源Q讨论工作项推送的最l分配状态;W二l包括随机指z、@环指z֒最短队列指z,x当工作项 分配l角艌Ӏ部门等包含多个资源的资源组Ӟ如何从中定最l的一个资源ƈq行指派Q第三组包括提前分配、即时分配和推后分配Q关注将工作Ҏ(gu)送给用户? 旉?/span>
1、提供给单个资源Q?/span>WRP_12: Distribution by Offer - Single ResourceQ?/span>
描述
能够在非l定的基上将工作Ҏ(gu)送给单个资源?/span>
?/span> 5-18
如图5-18所C,dA? 作项被系l推送至员工甲的可拾取列表。这意味着员工甲不必ؓ(f)该工作负责,他可以选择执行该工作也可选择忽略或拒l。如果他选择拒绝或忽略且工作超Ӟ? 么会(x)Dpȝ对该工作的重新分配。如果他选择执行该工作,那么他首先需要拾取该工作,q会(x)使该工作进入他的代办列表,意味着其必d该工作负责?/span>
应用
该模式类g现实工作中的征求意见Q先工作分配给你,然后找你谈话Q征求你对该工作的看法,如果合适那么就׃执行Q否则再找他人执行?/span>
实现
参与者对工作的拒绝?x)导致系l对工作的 重新分配Q这是实现该模式的难炏V如何重新分配该工作,采取何种重新分配{略Q这些都h很大的复杂性。实际上q些工作模式单个看h可能比较清晰? 了,但一旦组合v来,例如该模式与创徏模式l合hQ那么就有了多种情况变得复杂h。对于复杂的问题Q最好的解决办法是留给实施阶段Q由用户情况作出 使用限定。这也再ơ强调了工作实施在工作应用中的重要性?/span>
2、提供给多个资源Q?/span>WRP_13: Distribution by Offer – Multiple ResourceQ?/span>
描述
能够在非l定的基上将工作Ҏ(gu)送给多个资源?/span>
?/span> 5-19
如图5-19所C,dA所 生成的工作项被推送给多个员工的可拑֏列表。这些员工不必ؓ(f)该工作负责,他们可以选择执行该工作也可选择忽略或拒l。如果他们都选择拒绝或忽略且工作超 Ӟ那么?x)导致系l对该工作项的重新分配。如果有一名员工选择执行该工作,那么该工作项q入他的代办列表Q其他员工将不再h拑֏该工作项的机?x)?/span>
应用
该模式是典型的竞争参与,卛_人可以完成该工作Q先执行者先得。类gL志愿者?/span>
实现
该模式的实现一般是创徏阶段工作项分配l角艌Ӏ部门等包含多个资源的分l,在推送阶D,该工作w至q些l下所有资源共享的可拾取列表里Q工作项的实例只有一个,但是多资源可见?/span>
3、指z单个资源Q?/span>WRP_14: Distribution by Allocation – Single ResourceQ?/span>
描述
能够在绑定的基础上将工作Ҏ(gu)送给单个资源?/span>
?/span> 5-20
如图5-20所C,dA工作被pȝ推送至员工甲的待办列表。这意味着员工甲必Mؓ(f)该工作负责?/span>
应用
该模式是应用最多的模式Q直接指定Q务的负责人?/span>
在采用军事化理的企业里Q上U的命o(h)一定要执行Q下属没有商量和拒绝的权利?/span>
实现
相比提供Q指z֮现非常容易,直接工作项推送至选定资源的待办列表?/span>
4、随机指z(WRP_15: Random AllocationQ?/span>
描述
当存在多个资源可供选择Ӟ从中随机选择一个资源进行工作项的指z?/span>
?/span> 5-21
如图5-21所C,dA所生成的工作项在创建阶D分配给了开发h员这一角色Q在推送阶D,pȝ?x)随机选取一名开发h员负责该工作的执行?/span>
应用
该模式提供了一U指z资源的非确定性机制?/span>
5、@环指z(WRP_16: Round Robin AllocationQ?/span>
描述
当存在多个资源可供选择Ӟ循环选择其中一个资源进行工作项的指z?/span>
?/span> 5-22
如图5-22所C,dA所生成的工作项在创建阶D分配给了开发h员这一角色Q在推送阶D,pȝ?x)@环轮选取一名开发h员负责该工作的执行?/span>
应用
不?zhn)贫而?zhn)不均Q^{的分配工作?/span>
6、最短队列指z(WRP_17: Shortest QueueQ?/span>
描述
当存在多个资源可供选择Ӟ选择其中一个具有最待办工作即最短工作队列的资源q行工作的指派?/span>
?/span> 5-23
如图5-23所C,dA所生成的工作项在创建阶D分配给了开发h员这一角色Q在推送阶D,pȝ发现员工甲的待办列表里有两条待办工作QQ?/span>B和Q?/span>CQ,员工乙的待办列表里没有待办工作,所以系l将dA工作Ҏ(gu)z员工乙负责该工作的执行?/span>
应用
该模式的目的在于能够最快开始工作的执行Q找出相比而言最为空闲的资源q速开始工作。但是实际应用中Q仅仅依靠工作的数量来判断资源是否空闲是不可靠的Q因为工作和工作之间q存在着难易之分?/span>
7、提前分配(WRP_18: Early DistributionQ?/span>
描述
在工作项实际可以执行之前卛_该工作项通知或潜在的分配l资源?/span>
?/span> 5-24
如图5-24所C,dAq在执行QQ?/span>Bq未Ȁz,但此时Q?/span>B的工作项已经提前分配l员工甲Q该工作的主要职责是通知员工甲将由其来完成Q?/span>Bq能开始一部分准备工作Q而实际的工作则要{到dB被激zd才能q行?/span>
应用
该模式强调的是预先计划,即管理的计划性?/span>
在我们实际的目开始之前,目l理已经通知我们要q行的开发工作,让我们提前熟(zhn)相关的技术。这样当目开始时p提高最初P代的开发效率?/span>
从某U意义上_(d)E微复杂一点的工作都应该做到提前通知、提前准备,卌划的必要性?/span>
实现
让工作流pȝ直接支持该模式比较困难,因ؓ(f)该模式嵌套在控制模式和不同的工作创建模式里Q找不出一U通用的模式,无法预判工作的生成和实际的参与者。在一定范围内Q可以采用下面的方式变通:(x)
?/span> 5-25
如图5-25所C,在自动节Ҏ(gu)行时能确定Q?/span>B的参与者的情况下,可以通过自动节点l员工甲发送邮件或消息q行通知Q工作流pȝq不生成工作V?/span>
8、即时分配(WRP_19: Distribution on EnablementQ?/span>
描述
在工作项实际可以执行时将该工作项分配l资源?/span>
应用
机器执行的工作,重复单一的审批工作,无计划性的工作Q如各种H发情况的处理?/span>
实现
大多数工作流pȝ的标准实玎ͼ满d执行条g时先ȀzMQ务节点,然后创徏工作V分配工作项?/span>
9、推后分配(WRP_20: Late DistributionQ?/span>
描述
在工作项实际可以执行后的某个旉才将该工作项分配l资源?/span>
?/span> 5-26
如图5-26所C,dB已经ȀzM已生成可以执行工作项Q但是系lƈ没有其分配臛_工甲的工作项列表里。这是因为员工甲正在执行dA的工作项Q直到其执行dA完毕Q系l才?x)把dB工作Ҏ(gu)送至工作列表?/span>
应用
保证程和资源对工作的负载处于一U良好的状态,避免出现下图的情况:(x)
?/span> 5-27
在敏捷开发里Q我们强调客户合作,整个的开发过E对用户透明Q用L(fng)道当前正在进行的开发工作,也清楚开发团队的开发速度Q在q种情况下,一旦有新的需求加入,用户?x)推q该需求的实现Q或者推q当前其他需求的实现Q从而保证整个团队的开发效率?/span>
实现
该模式的实现依赖于推后的{略Q即在什么情况下推后分配Q满什么条件下q行分配。具体实现同样采取推后模式,推后到实施阶D实现?/span>
创徏模式在系l创建工作项时生效,如下图所C,其位于工作项生命周期的创建阶Dc(din)?/span>
?/span> 5-2
正如上面提到的,工作系l在执行d节点时会(x)为其创徏相应的工作项Q根据情况工作项可以是一个也可以是多个?/span>
创徏模式作ؓ(f)程模型的构成部分在程设计期指定,通常在Q务节点的定义里进行定义,与一个Q务关联,其用来限定可执行该Q务的资源范围。系l根据创建模式限定的资源范围生成工作,工作可以直接分配给人,也可以分配给角色、部门、岗位等?/span>
1、直接分配(WRP_01: Direct DistributionQ?/span>
描述
在设计期直接ZQ务指定特定的资源Q该d的工作项能够在运行期分配l它。注意,指定的资源可以ؓ(f)多个Q如果是多个的话׃(x)生成多个工作,为每个资源生成一个单独的工作V该模式实际限制执行该Q务的资源范围?/span>
?/span> 5-3
如图5-3所C,dA在定义时直接指定l员工甲QQ?/span>B在定义时直接指定l员工乙Q当实际执行dA和Q?/span>BӞ由员工甲和员工乙分别执行?/span>
应用
该模式一般应用于程里的关键路径。同Ӟ 在中企业里Q该模式是应用最多的分配模式Q因Zh员少Q管理扁qI所以每个h的职责都非常清晰。该模式也是执行效率较高的资源模式,因ؓ(f)人和d直接l? 定,所以不?x)生推诿等情况Q便于管理也便于q究责QQ因行情况完全在设计期确定。而随着企业规模的扩大,理层次的复杂,一个Q务往往需要交q? 的部门、岗位或角色来执行,q样无Ş中会(x)影响d执行的效率?/span>
该模式的~点在于一旦关键h物因为各U原因不能及(qing)时处理Q务,那么造成整个程的挂L(fng)待?/span>
实现
最单的资源模式Q设计期定资源Q运行期工作引擎不需要做额外的工作?/span>
2、基于角色的分配Q?/span>WRP_02: Role-Based DistributionQ?/span>
描述
在设计期ZQ务指定一个或多个角色Q该d的工作项能够在运行期分配l这些角艌Ӏ实际执行该dӞ资源从属于q些角色的资源中产生。该模式实际限制执行该Q务的资源范围?/span>
?/span> 5-4
如图5-4所C,dA在定义时指定l?#8220;开发h?#8221;q一角色Q该角色包括了两名员工甲和乙。实际执行Q?/span>AӞ由员工甲或乙来执行?/span>
应用
企业辑ֈ一定规模,׃(x)产生人员的分l,角色是典型的分组方式Q将h怼属性的人员定义Z个特定的角色Q这些属性通常与工作的内容相关Q例如开发h员、项目经理、ȝ理等Q而角色通常又会(x)与权限生关联?/span>
Q务分配给角色意味着会(x)有多个员工可以执行该dQ执行效率相比直接分配会(x)有下降,q也是企业扩大后理成本增大的一U表现Ş式?/span>
实现
工作系l内|的l织机构模型需要对角色q行支持。引擎运行期通过角色讉K属于该角色的人员?/span>
3、gq分配(WRP_03: Deferred DistributionQ?/span>
描述
在设计期ZQ务指定资源的标识Q典型的Q在工作系l里Q该标识对应于一个数据字D变量,例如userid。即在设计期q不定资源Q资源的定被gq至q行期,pȝq行期从该数据字D里获取该Q务分配的资源?/span>
?/span> 5-5
如图5-5所C,dB在定义时资源的标识指定ؓ(f)useridQ实际执行时QQ?/span>A由员工甲执行Q其指定了下一d的执行者ؓ(f)员工乙即讄?/span>useridq一变量为员工乙?/span>idQ在dB实例创徏Ӟ它访?/span>useridQ发现该变量里是员工乙的idQ于是将该Q务分配给员工乙?/span>
需要注意的是,Ҏ(gu)具体的分配策略,q行期该数据字段不仅可以指定人员Q也可以指定角色、部门等?/span>
应用
该模式给资源的分配引入了灉|性。资源的定延迟臌行期Q即d可以Ҏ(gu)具体的实际情况再定执行人。具体实施时Q这个指定的数据字段可以通过一pd的规则运得出?/span>
在国内应用中Q该模式被大量应用在人工q预程中,例如下一d的执行由上一d的办理者指定?/span>
实现
一般通过工作变量来包含资源?/span>id。ؓ(f)了区别该id是h?/span>idq是角色idQ一般内|特D变量,例如userid?/span>roleid?/span>groupid{?/span>
4、按权限分配Q?/span>WRP_04: AuthorizationQ?/span>
描述
能够指定资源的范_(d)只有该范围内的资源才h执行该Q务的权限?/span>
?/span> 5-6
如图5-6所C,只有目l理才有权限对开发h员申误Y件的要求q行批准?/span>
应用
随着分工的细化,每个人工作内容的不同Q必然会(x)产生权限的概c(din)权限实际代表着对同一件事情,每个人执行工作内容的差别。权限越大能执行的操作越多意味着需要负责的斚w多?/span>
该模式强调通过权限Ҏ(gu)行Q务的资源加以限定?/span>
实现
在大多数的Y件系l中Q角色不仅仅代表h怼属性的一lh员,同时其也是最重要的权限概念,人员往往不与权限直接兌Q角色将人员与权限两者进行关联。所以,对Q务设定权限可以通过指定角色来完成?/span>
5、职责分(WRP_05: Separation of DutiesQ?/span>
描述
在一个流E实例里Q能够指定两个Q务必ȝ不同的资源执行?/span>
?/span> 5-7
如图5-7所C,dA和Q?/span>B在设计期被指定不能由相同的资源执行,同时它们都指定分配给l理q个角色。那么在q行期,在一个流E实例里QQ?/span>A被分配给了员工甲执行Q那么在q行dB的分配时Q尽员工甲也属于经理,但是不能由其执行?/span>
应用
职责分离Q不能既当运动员又当裁判员,不能又当x队领队又当全q会(x)裁判ѝ?/span>
典型的报销程里,一般员工的差旅报销p(ch)务h员核实,但如果某名胦(ch)务h员需要报销差旅Ҏ(gu)然不能由自己审批Q需要另外一名具有同h限的财务人员审核。此时就可以对申请Q务和审核d两个d节点应用该模式。如下图所C:(x)
?/span> 5-8
实现
后箋节点q行d分配Ӟ需要获取与之关联前l节点的分配执行信息。流E定义期Q在定义d节点属性时建立两者的关系?/span>
6、流E实例整个处理(WRP_06: Case HandingQ?/span>
描述
在一个流E实例里Q所有的d都能够分配给同一个资源执行?/span>
?/span> 5-9
如图5-9所C,程实例中的所有Q务都由同一个h执行QQ?/span>A?/span>B?/span>C都由员工甲执行?/span>
应用
在应用该模式的流E里Q通常程里的d? 是紧密关联的。流E里的Q务往往执行在一个紧密相关的上下文里Q如果所有的工作都由一个h执行Q那么在其了解该上下文的情况下连贯执行这些Q务会(x)h更高 的效率;而如果执行Q务的q程中换人,那么新换的h无疑q需要时间对该流E实例相关的上下文进行熟(zhn),q样无疑?x)多付出执行成本?/span>
同一个Y件的开发最好由同一拨开发h员完成,如果中途更换开发h员,那么新来的开发h员需要一D|间熟(zhn)该软gQ会(x)对开发进度生媄(jing)响。同L(fng)道理Q在软g上线前增加开发h员不一定会(x)提高开发效率,很多时候甚至作用相反?/span>
实现
可以在实现gq分配模式的情况下实现该模式Q即在第一个Q务节点初始化讄参与者变量,后箋d全部使用该变量。如下图所C:(x)
?/span> 5-10
7、经验获取(WRP_07: Retain FamiliarQ?/span>
描述
在同一个流E实例里Q当存在多个资源都能执行某一工作Ҏ(gu)Q能够将该工作项分配l执行了前某一工作的同一资源?/span>
?/span> 5-11
如图5-11所C,dA和Q?/span>B在设计期被指定由相同的资源执行,同时它们都指定分配给l理q个角色。那么在q行期,在一个流E实例里QQ?/span>A被分配给了员工甲执行Q那么在q行dB的分配时QQ?/span>B依旧由员工甲执行?/span>
应用
该模式刚好与职责分离模式相反Q正如它的名字所暗示的,q些d之间存在着紧密兌Q如果执行了其中一个,那么׃(x)熟?zhn)q些相关联Q务的背景上下文,U篏一定经验,那么后箋d的执行相对其他h来说?x)变得容易。提高Q务执行的效率?/span>
?/span> 5-12
如图5-12所C,在Y仉售的q程中,售前和编写标书是重要的两步,q两个Q务最好由同一个hq行处理Q因为参与Y件售前的人更熟?zhn)客户的实际情况和需求,如果分开׃同的人员执行Q那么必然会(x)存在前者与后者的交流成本?/span>
实现
后箋节点q行d分配Ӟ需要获取与之关联前l节点的分配执行信息。流E定义期Q在定义d节点属性时建立两者的关系。运行期可以通过参与者变量(工作变量)(j)建立赯行期关系?/span>
8、基于能力的分配Q?/span>WRP_08: Capability-Based DistributionQ?/span>
描述
能够Z资源的能力进行工作项的分配,能力作ؓ(f)l织模型的一部分建模源的属性?/span>
?/span> 5-13
如图5-13所C,dA需要交与开发h员执行,同时其对办理该Q务的人员能力提出了要求,要求只有熟?zhn)?/span>JAVA且工作经验大?/span>2q的开发h员才能执行该d。这样就~小了选取资源的范围?/span>
应用
人力资源理中很重要的一点就是要做到人尽 其用Q每个h的能力都能得到最大的发挥Q其实也是Ҏ(gu)能力h攄到最合适的工作中去。从q一点看Q该模式是对人尽其能的实现。但是如何定义各个h员的 能力Q这本n比较的主观Q执行各工作需要具备的能力也具有主观因素,更何况很多时候能力ƈ不能与表现划上等P模型是固定的但h是变化的受环境媄(jing)? 的,所以工hw就是工P工具的应用最后还是依赖于人?/span>
实现
实现需要两部分Q一部分是组l机构对行徏模时需要包括能力模型;另一部分是流E徏模时需要给d定义执行该Q务所需的能力约束,q些U束是一pd的领域特定条Ӟ需要有特定的解析器q行条g的解析?/span>
很多工作引擎提供有参与者接口,接口q回人员ID列表供给d分配Q从而将q部分工作委zֈ工作实施时实现?/span>
9、基于历史的分配Q?/span>WRP_09: History-Based DistributionQ?/span>
描述
能够Z先前的工作历史决定当前Q务的分配?/span>
?/span> 5-14
如图5-14所C,当需要在员工甲和员工乙之间做出选择Ӟ?x)选择此前执行cMd时完成最好的员工。需要注意的是,q里的历史不再是限定在同一程实例的Q务执行里Q可能是同一程模型的执行历Ԍ也可能是不同程模型的执行历双Ӏ?/span>
考虑历史Ӟ有很多的考虑因素Q例如完成类gQ务最好的员工、完成类gQ务最快的员工、完成类gQ务出差错最的员工{等。这些考虑因素依赖于具体的d内容和背景?/span>
应用
国家球队比赛前Q主教练?x)考察各个位置里各个球员的联赛比赛历史情况Q其中不仅会(x)考虑出场旉也会(x)考虑各项数据Q从而做出选择?/span>
实现
同基于能力的分配模式一P该模式的实现依赖于工作流具体应用的场景,也就是需要到实施阶段l合实际实现。从某一U角度也说明Q应用工作流产品Ӟ产品实施阶段也是最重要的步骤,选择工作品不仅仅是选择产品也需要考察其背后的实施团队。同时也可见Q这些模式在诸如政府OAq些应用中是Ҏ(gu)应用不上的?/span>
实现需要两部分Q一部分是对用户d执行历史q行l计分析扑և关键的评定因素;另一部分是流E徏模时需要给d定义执行该Q务所需的历史因素约束,q些U束同样是一pd的领域特定条Ӟ需要特定的解析器进行解析?/span>
10、按l织分配Q?/span>WRP_10: Organizational DistributionQ?/span>
描述
能够Z人员在组l机构中的位|以?qing)与其他人员的关pd配工作项?/span>
?/span> 5-15
如图5-15所C,审批d需要由甌人的部门l理执行Q即需要员工甲的部门经理执行。这U情况即Z人员之间的关pd配工作?/span>
Z人员在组l机构中的位|分配即需要在工作模型里建立起与用户相匹配的l织机构模型Q可以将d分配l部门、角艌Ӏ(f)时组、岗位等?/span>
应用
应用最为广泛的模式Q实际工作中几乎所有的工作都必然和l织机构h联系。其他模式,如基于历史的分配、基于能力的分配{都是基于该模式之上的扩展,直接分配、基于角色的分配则直接是该模式的单情c(din)?/span>
实现
对该模式的支持实际上是对用户l织机构模型的支持。正如前面所提到的,很难存在一U工作流产品能够支持所有的l织机构模型Q但是大部分的品都?x)提供一套元模型或扩展机Ӟ需要在实施q程中最大限度的契合客户业务?/span>
11、自动执行(WRP_11: Automatic ExecutionQ?/span>
描述
d的执行能够自动完成,不需要h员参与?/span>
?/span> 5-16
如图5-16所C,请假审批后需要将情况通知l申请hQ该dp机完成Q不需要h的参与,也不?x)生工作项?/span>
应用
随着自动化水q的提高Q越来越多的工作可以交由计算机或相应的机器设备完成。流E中的自动执行节点也?x)逐渐增加?/span>
实现
实际上工作流产品对该模式的支持即是支持各U的企业集成方式Q不是通过Web服务q是消息Q工作流需要驱动相应的讑֤机器或应用系l进行工作ƈ传递给必须的数据。所以也可以看出Q随着信息化程度的提高Q目前工作流应用来趋向于企业集成领域。这也是Z么基?/span>Web服务~排?/span>BPEL?x)逐渐取代XPDL成ؓ(f)工作流行标准的原因之一?/span>