??xml version="1.0" encoding="utf-8" standalone="yes"?>
Shark是体pd功能最为复杂的代表。它是另一N循WfMC的XPDL标准开源工作流引擎Qƈ且同旉循OMGl织的Workflow Management Facility规范。在所有开源工作流引擎中,Shark的体pL为完备和复杂。其一直秉承着“模块化”的思想Q所以比较容易扩展。但是自从被Together公司收购后,Shark的商业化色彩已经来浓Q改UCؓTogether Workflow ServerQƈ仅以Community Edition的Ş式提供了部分开源代码供参考?/p>
OSWorkflow
OSWorkflow是最轻量型的代表Q也是一N常灵zd低别定位的工作引擎的实现框架。低U别定位的意思是_它不是定位在解决程模型对象和运转场景,而是提供一套可l护调度的机Ӟ供开发h员自L展。这个维护流E调度机制OSWorkflow选择的是Z行ؓ(Action)的FSM理论Q所以OSWorkflow更像是一个复杂而灵zȝ有限状态调度机?/p>
OSWorkflow在国内项目应用得较多Q很多国内的易审ҎE项目都是基于其引擎二次开发而来。这主要是由于OSWorkflow是基于Action驱动的,而国内的客户也很Ҏ接受q样的操作习惯。但OSWorkflow所依赖的FSM模型对于分支、聚合、子程的支持度很低Q这一点在实施q程中需要注意?/p>
jBpm
jBpm是最适合扩展的代表,是在所有开源引擎中最适宜被商业化应用的一ƾ。首先其程建模模型是基于Activity Diagram(zd?的,q在引擎构徏上融入了FSM和PetriNet思想Q所以其内核和根基比较牢固扎实。其ơ,自从被JBoss收购后,?. xpd的结构更加趋于微内核QPlug-in思想也更加深入。其同时q提供了对BPEL扩展Q存储支持JBoss Hibernate实现Q集成了JBoss seamQ规则引擎准备采用JBoss rulesQƈ准备集成JBoss Messaging。这P不论从内核和外围应用QjBpm都具有了强劲的动力?/p>
另外QjBpm对Token的应用也很有特色Qy妙地利用Parent-Child Token的机制处理分支、父子流E等复杂应用场景。这个设计思想很值得大家学习参考?/p>
YAWL
YAWL是算法和模式最值得研究的代表,它是Alast力主倡导的一Ƒ֟于PetriNet建模的工作流引擎Q其PetriNet的Token与And、XOR、OR法q行了融合,q对Workflow Patterns(工作模?中所有模式提供支持。但YAWL本n仅是一个研I性项目,所以其l构和实现缺了商业化应用的特点。但有必要研I一下YAWLQ一斚w可以加深对工作流模式的理解,另一斚wQYAWL的一些徏模思想、处理算法很值得推敲和吸U?/p>
ActiveBPEL
ActiveBPEL 是BPEL引擎的代表,也是一Ƒ֏执行BPEL4WS规范的开源流E引擎,其结构和实现方式h很高的参考h倹{目前国内很多正在开发基于BPEL产品的中型软g厂商Q其实现的很多基性内容和思想都参考自ActiveBPEL。受目前国内中小型客户对程需求的限制Q基于BPEL的开源引擎或型产品被市场接受度q很低。但BPEL所围绕的业务流E及程整合应用是一个发展趋ѝ?/p>
时下的新Chcȝ到我Q一定会认ؓ在下是个十的老古董,q不Q《功夫》这L片子我到今年2月底才看。不q看q《功夫》,我想的一定比一般的人多Q周星星迹江湖Q和他胖子大哥出LҎӞZ么要他大哥胸前画两把斧头Q找个假靠山呗!装是斧头帮的人才不会被h啊?
q让我想到年前的一则新闻:jbpm joins jboss and becomes jboss-jbpm。也是说了Qjbpm找了个靠山jbossQ以后不用自己在外流了?
好,我们转入正题Q谈q里说的三大L开源工作流引擎QShark,osworkflow,jbpm?
Shark的靠山是Enhydra。Enhydra做过什么呢Q多了!从j2ee应用服务器,到o/r mapping工具Q到q个工作引擎等{。ؓ什么Shark的持久层采用DODS来实玎ͼ是因ؓ他们是一家h?
Jbpm的靠山是jboss。Jbpm3的持久层采用hibernate3来实玎ͼ也是因ؓq个原因吧。Jbpm3的图形化程定义已经军_嵌入到jboss eclipse IDE中,大家看看jboss eclipse IDE preview 1.5版,我们已经可以用插件方式编辑一个jbpm3程定义文g了?
Osworkflow的靠山是opensymphony。我是非常喜Ƣ这个组l的Q它做出了很多的好东ѝ在开发工作流理pȝӞ我就推荐用它的另外一个东西:webwork2。笔者主持的开源工作流引擎AgileFlow是Zww2+spring+hibernate架构实现的?
完成本段时说句题外话Q现在基本上所有的J2EE应用E序服务器都有自q工作引擎,如上面提到的Enhydra,jboss和没有提到的websphere和weblogic{,可见Q学习工作流引擎技术的是非常重要的?
2Q如来神?
光有靠山是不行的Q周星星加入了斧头帮q不是被邪神打扁了头Q要救自己,q是要靠如来掌?
Shark的流E定义语a是XPDLQ我们知道,XPDL的两个最重要的概忉|Process和Activity。XPDL中的Activity是基于UML1.x中的zd囄概念。活动图天生的适于工作程建模Q它相对于状态图的一个最大的优点是容易做q发U程的分叉控Ӟq些q发U程可以同时执行也可以顺序执行;它还有一个优Ҏ有泳道的概念Q可以控制工作流引擎中的d的生。Shark的如来神掌是zd图?
Osworkflow的如来神掌又是什么呢Q我们知道,它有个重要概忉|State……呵呵,我们知道了,它的如来掌是FSM。不知道FSM是什么东西?Q那你读大学时肯定不是好学生Q当然了Q不知道也不打紧Q你把他cM理解为状态图可以了。Osworkflow中的State是由step和status联合表达的,一个State是一个step中的某个statusQ而state的{换由action来驱动,cM状态图中的event,因ؓ一个event对应一个action嘛?
Jbpm的如来神掌就没有上面的简单了Q它l合应用了状态图+zd?PetriNet的知识,而且Q这里的zd图还是UML2.0版的。UML2.0的活动图中,节点不叫zdQActivityQ而叫动作(action)Q活动成了一个高层次的概念,它包含一个动作序列。一个活动图展现一pd的动作,q些动作l成了活动。Jbpm把action也改名了Q称为state。Jbpm使用的状态图的概忉|transition/event{,q个自己ȝ吧。Jbpm来内部实Cq采用了PetriNet的概念,如token,signal{。什么?又不知道PetriNet什么东东?那你大学是学计算机的吗?不是Q那你可能是学文U的Q学机械/甉|/土木工程/交通运输等专业都有接触PetriNet的课E,如果没有学过Q还是看看jbpm吧,反正我们也不搞理论,知道大致概念p?
3Q市场预?
做预是件吃力不讨好的事情,好多国外的大师做的预也是被人骂得……幸亏我dq中在《工作流之大局ѝ中做的预测q是基本正确。那时我的预是QShark……将M头号宝。应该说Q在那篇文章发表前,国内的工作流引擎使用率最高的是osworkflow;到去q年底,Shark占有了明显的优势地位,我分析有如下原因Q?
1. 国内的企业都看中XPDLQ因意味着在品说明书中又可以吹牛说“我们遵循WFMC……?
2. 因ؓ我自诩“Shark工作引擎在国内的主要推q者”,大部分给我反馈工作流理pȝ开发选用技术的朋友都是用的Shark
3. Shark的确是一套不错的工作引擎,q你只是想学习XPDLQ你也可以从学习Shark开?
现在已经C《工作流之大局ѝ中说的从封建社会向资本M转型的时代,而驱动这一转型的,不是别hQ正是上面说的jbpm。Jbpm3在3月发布阿发版,jbpm3的最l版支持bpel4ws的核心部分。所以,我估计,Shark在引领风骚数百天后Q被jbpm3赶下W一宝。笔者的开源敏捷工作流开发框架AgileFlow整合jbpm3Q同时对agile引擎和jbpm3引擎提供支持?
但bpel4ws真的和我们q么快的亲密接触了吗Q没有。我估计在今q它是不会真正走q我们的生活的,那会是什么时候呢Q这是我下文章要预测的内容,我现在可不敢pQ我现在考虑的是Q是不是要自诩“jbpm3工作引擎在国内的主要推q者”,呵呵?br />
http://www.360doc.com/showWeb.aspx?ArticleID=4713
工作?/span> 现状 Q?a target="_blank">原文Q?
作?a >Tom Baeyens 译dinghong
如果数据库系l( database systemsQ像受h敬的智者讲q的条理清晰的故事,那么工作?/strong>Q?strong>workflowQ就像一^臭未q的子在大谈各自的“哲理”。之所以这栯Q我是想指出Q?strong>工作?/strong>pȝ Q?strong>workflow management systemsQ还处于技术发展曲U( technology hype curveQ上的初U阶Dc在q个领域我们面临一个激动h心的阶段?Z描述q一点,可以?strong>工作?/strong>和关pL据库pȝQRDBMSQ做一个对比。当在Y件开发团队中谈论RDBMSӞ大部分h会有一个清晰的概念Q在你和他们交流的时候,Z会通过d的点头表C可或理解你所说的。可当用工作流术语讨论工作?/strong>Ӟ他们会摇头表CZ同意Q因为每个h?strong>工作?/strong>术语都有不同的理解?/span>
D形成q种状况的原因之一Q是?strong>工作?/strong>中用了q多的概c在q个领域中的大量规范和工h有一个是怼的。当Ӟ它们怺之间有重叠ƈ且会怺参考引证?br /> 在介l?strong>工作?/strong>时有一个话题必d括,那就?strong>工作?/strong>?strong>业务程理QBPMQ的关系。术?amp;ldquo;工作?/strong>”通常描述Z计算机系l的一pd相关交互。在开发h员中Q?strong>工作?/strong>l常被提及。有Ӟ工作?/strong>的意思是指一些不同的UI界面。业务流E管理的范围比较q,相比之下工作?/strong>多半局限于技术领域。业务流E管理还从管理h员的角度涉及了非技术问题,比如分析、组l的效率?/p>
在本文中Q我首先解释什么是工作?/strong>理pȝQ然后介l业务流E管理的优点。接下来描述一下ؓ什?strong>工作?/strong>市场乍看h如此混ؕ。本文给出的主要l论是:选择工作?/strong>pȝ是想?strong>工作?/strong>pȝ的公司,要面对的最困难的事情。ؓ此,本文的核心部分描qC一个流E定义(process definitionQ的四个层次Qؓ你选择工作?/strong>提供一个基。本文还用中立的语言描述?strong>工作?/strong>和BPM的通用概念。最后,l出了一些规范和工具的指导性描q?/p>
工作?/strong>pȝ是以规格化的程描述作ؓ输入的Y件组?它维护流E的q行状?q在人和应用之间分派zd?/p>
Z后面的描qͼ我们先定义一些基本的术语Q流E定义(process definitionQ和程实例Qprocess instanceQ? 一个流E定?/u>是一个业务流E或q程的规格化描述。一?u>程实例是流E定义的一个运行实体?都目前ؓ止,概念q比较清晰是不是Q但当再深入一步时Q我们就要小心用文字了。如何阐q流E中的步骤,现在q没有一个统一的方式。这是各U?strong>工作?/strong>规范和工具之间主要的分歧?/p>
Z么应当禁止用术?amp;ldquo;zdQactivityQ?amp;rdquo;...
工作系l?/strong>另一个重要的职责是维护每一个流E运行的上下文信息?程上下文变量(process context variableQ?/u> Q或U变量,是与程实例相关的变量。如Q休假申L开始日期、数据库中一条记录的键倹{文档管理系l中一文档的索引{。通常在流E定义中声明q些变量Q然后在程实例生成Ӟq些程变量被实例化。所有成熟的工作管理系l?/strong>都支持定制的变量cd?/p>
使用工作管理系l?/strong>的目的之一是作Z业应用系l集成(EAIQ的q_。在当前大部分企业IT架构中,各种各样的异构(heterogeneousQ应用和数据库运行在企业内网中。在q些pȝ被应用到l织Ӟ都有一个清晰的目标。例如,客户理、文档管理、供应链、订单、支付、资源计划等{。让我们U这些系lؓ专门应用Q?dedicated applicationsQ。每一个专门应用都包含它们所支持业务程的领域知识。这些专门应用中的自动化程Q被DC业中更大的非自动化流E中。每当一个这L专门应用安装q投入用,都会带来涉及其他多个应用的新功能需求。企业应用系l集成(EAIQ就是通过使用多个专门应用满软g新需求的Ҏ。有Ӟq只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务程编码在软g中。可以这么说Q在你购C门应用时Q你是购C一l固定的自动化业务流E。?strong>工作管理系l?/strong>是不必事先知道问题域的相关信息的?strong>工作系l?/strong>业务流E描qC入ƈ理程实例的执行,q得它比专门应用更灉|Q当然你也要q力编写业务流E的规格化描qͼ。这是Z么说工作系l?/strong>和专门系l是怺补充的?strong>工作系l?/strong>可以用来理全局的业务流E。如果专门应用支持你所需要的业务程Q那么用专门应用。在此讨论的工作系l?/strong>的第一U用方式就是:l合所有的专门应用Q?strong>工作系l?/strong>构徏一个EAIq_?/p>
工作系l?/strong>能够发挥很大价值的W二个用方式是Q协助涉及多人相关Q?strong>工作?/strong>软g的开发。ؓ了达到这个目的,大部?strong>工作系l?/strong>都有一个方便的机制Q来生成执行d的表单。对于专注于ISO 或?a >CMM认证的组l,采用q种方式使用工作系l?/strong>能够显著提高生率?不用过E用文字的Ş式写在纸上,工作系l?/strong>使你通过程定义建模实现q程的自动化Q如使用ZWeb的应用)?/p>
工作系l?/strong>的第三种使用方式是:?strong>工作引?/strong>嵌入到其他应用中。在前面我们谈到Q专门应用将指定问题域相关的业务程固化在Y件中。开发专门应用的公司也可以将工作引?/strong>嵌入C们的软g中。在q里Q?strong>工作引?/strong>只是作ؓ一个Y件组Ӟ对于应用的最l用h不可见的。将工作引?/strong>嵌入到应用中的主要原因是Z重用Q不重复发明轮子Q和应用软g的可l护性?/p>
对于引入工作?/strong>的组l,能够在Y件开发和业务两个层次受益?/p>
工作管理系l?/strong>能够化企业软g开发甚至维护?
在自动化业务程之前Q分析ƈ它们规格化是一件艰苦但会有很好回报的工作?a >e-workflow.org对于分析程能够带了的益处有不错的阐qͼ
我认Z们还遗漏了一个?strong>工作?/strong>pȝ最重要的因敎ͼ提高对P代开发的支持。如果Y件中业务程部分不容易更改,l织׃花很大的_֊在开发前的业务流E分析中Q希望一ơ成功。但可悲的是Q在M软g目开发中Q这都很能实现?strong>工作?/strong>pȝ使得C务流E很Ҏ部vQ业务流E相关的软g可以一UP代的方式开发,因此使用工作?/strong>pȝ使开发更有效、风险更低?/p>
一?strong>工作管理系l?/strong>以流E定义作入。在q里Q可以将程定义看作UMLzd图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报仗?..之后Q?strong>工作?/strong>pȝ负责l护q些程定义的执行状态和上下文。ؓ此,需要通知工作?/strong>pȝ状态的变化。运行流E的状态变化可以记录下来,以备监控理?/p>
圈套QPitfallQ?/b>
所有状态和控制的表述Q都属于业务程的状态层。标准编E语a中的控制来源于Von Neuman体系。控制流定义了必被执行的指令的序Q控制流由我们书写的命o、if语句、@环语句等定。在业务程中的控制基本与此一致。但在业务流E中不是使用命o而是使用状态作为基本元素?/p>
在流E中Q?u>状?/u> (或者说{待状?代表了一U对外部参与者(actorQ的依赖。状态的意思就?amp;ldquo;现在Xpȝ或某某h必须作某些事Q在此等待直到参与者通知q些d已完?amp;rdquo;。状态定义了一U对外部提供l果的依赖。状态典型的例子是批准步骤(stepQ?/p>
程定义中的状态也指定了执行依赖于哪个参与者。在zd图中Q泳道(swimlanesQ的标注代表q些参与者的名字?strong>工作?/strong>pȝ使用q些信息构徏d列表Q这是一?strong>工作?/strong>pȝ都有的功能。如前所qͼ参与者可以是Z可以是系l。对于需要h参与的状态,工作?/strong>pȝ必须在运行时计算出具体的个h。这L计算?strong>工作?/strong>pȝ必须依赖于组l结构信息。关于这斚w的一非常有的文章是在further reading section提到?amp;ldquo;工作?/strong>应用中的l织理”Q?'Organizational Management in Workflow Applications'Q?/p>
程定义的控制流包含一l状态和它们之间的关pR状态之间的逻辑关系描述了哪些执行\径可以同时执行,那些不可以。同步执行\径用分叉QforksQ和联合QjoinsQ徏模,异步执行路径用判断(decisionsQ和合ƈQ?mergesQ徏模。注意在大多数模型中Q在每个状态之前都有一个隐式合q?/span>?/p>
UMLzd囄常被用来做业务流E徏模。作ZU直观和通用的表达,zd囑֜囑Ş表述上有一个主要问题,是没有区分状态和动作Q它们都用活动来表示。缺这U区分(D状态概늚~失Q是学术z֯UMLzd囄主要批评。UMLzd囄W二个问题是在UML2.0版中引入的。当多个q移QtransitionsQ到达一个活动时Q以前的版本规定q是一个缺省合qӞmergeQ,?.0版中规定q是一个需要同步的~省联合QjoinQ。在我看来,UMLzd囄囑Ş部分仍旧可以用来对业务流E状态层ơ徏模,只要使用时对两条构徏语义作如下的变化Q?/span>
在流E运行过E中Q?strong>工作?/strong>pȝ用一个o牌(tokenQ作为指针跟t流E的状态。这相当于Von Neuman体系中的E序计数器。当令牌到达一个状态时Q它被分配给工作?/strong>pȝ{待的外部参与者。外部参与者可以是个h、组l或者计机pȝ。我们定义流E运行的执行人或pȝ?amp;ldquo;参与?amp;rdquo;QactorQ。只有在工作?/strong>pȝo牌分配给一个参与者时Q才需要访问组l结构信息?strong>工作?/strong>pȝ通过分配令牌构徏d列表?/p>
程上下文变量(process context variableQ?/u> Q或U变量,是与程实例相关的变量。流E开发h员可以用流E变量存储跨流E实例整个生命周期的数据。一?strong>工作管理系l?/strong>有固定数目的数据cdQ另一些你可以定义自己的数据类型?/p>
注意变量也可以用来存攑ּ用( referencesQ。一个变量可以引用如数据库中的记录、网l上的文件。什么时候用引用,取决于用引用数据的其他应用?/p>
和流E变量相关的另一个o人感兴趣的方面是Q?strong>工作?/strong>pȝ如何数据{化ؓ信息?strong>工作?/strong>是用于组l内部跨各U异构系l实CQ务和数据协同的。对于业务流E中人工执行的Q务,工作?/strong>pȝ负责从其他相关系l,如SAP、数据库、CRMpȝ、文档管理系l收集数据。在业务程的每一个h工步骤,只有相关联的数据被从异构系l中攉和计。通过q种方式Q从不同pȝ来的数据被{换ƈ展现Z息?/p>
如前所qͼ动作是在程q行q程中,工作?/strong>pȝ响应指定的事ӞeventQ执行的一D늨序逻辑Qprogramming logicQ。程序逻辑可以是二q制或源代码形式的、用M语言或脚本编写的软g。程序逻辑层是所有这些Y件片断和关于在什么事件发生时调用它们的信息的l合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERPpȝ中拿数据和更新数据库?/p>
当前在BPM领域中,关于可执行业务流E的规范有趋向于l一集中的趋ѝ?XLANG, WSFL 和BPML合ƈ为基于交互(消息交换Q的BPEL。BPEL在面向服务体pȝ?SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法Q这套语法可以看作一U编E语aQ用来描q包括对WSDL定义的服务调用的控制?/p>
在可执行业务程和基于状态的工作管理系l?/strong>所使用的方法中Q我注意C三点主要的区别:
最后我们看看真实世界中?strong>工作管理系l?/strong>。选择一?strong>工作管理系l?/strong>是一件困隄事情Q但有选择L没有选择好?-) 本文阐述工作?/strong>基本概念的目的之一Q就是你能够作更好的选择。但我也意识刎ͼ对于现在的Y件架构师来说Q选择工作?/strong>pȝ是一件最h战性的工作?/p>
下面的列表来源于三个地方Q?a >my previous article, the list of Carlos E Perez, ?list by Topicus.
Michael zur Muehlen作了一个所?strong>工作?/strong>相关规范的介l性的qȝ?/a>Q很不错?/p>
我同?a >John Pyke 在我看来Q导致规范如此之多而同时每个规范的应用又很有限的原因是Q在工作?/strong>最基础概念上大家达成的p很少?strong>工作?/strong>是最Ҏ让你感到心烦的话题,因ؓ工作?/strong>本n的概念会和其他相x念和技术淆在一赗可以D一个具体的例子Q比如说工作?/strong>完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一?strong>工作?/strong>理pȝQ但是不能假定L必须通过Web Service接口讉K工作?/strong>pȝ接口。一些规范造成了这L假设。除了Web ServiceQ其他容易淆的概念和技术包括:Email、流E之间的通讯、Web应用和组l结构?/p>
?strong>工作?/strong>领域W一个致力于标准化工作的?a >Workflow Management Coalition (WfMC)Q开始于 1993?WfMC发布?a >参考模?/a>很不错,它定义了工作管理系l?/strong>和其他相关部分之间的接口。WfMC的另一Ҏ果是XPDL规范?XPDL定义了描q?strong>工作?/strong>声明部分Qdeclarative partQ的XMLl构。我个h认ؓQ参考模型和XPDL是目前最好的规范?/p>
我在本文中指?strong>工作?/strong>市场q属于年轻而又混ؕQyoung and wildQ的阶段Q但已经有可靠的工具存在?
从以上所有这些中能得到的l论是:
我希望本文能够激发你?strong>工作?/strong>的兴ƈ且能够ؓ你进行有效的Ҏ提供正确的背景知识?/p>
about the author
什么是工作?/strong>理pȝQWFMSQ?/font>
定义
程定义通常用一些活动表q。我认ؓq是D工作领域所有q主要原因。我告诉你ؓ什么:因ؓ术语“zd”h了状态(stateQ和动作QactionQ之间的差异。在程中,状?/u> (或者说{待状?代表了一U对外部参与者(actorQ的依赖。在程q行Ӟq意味着程引擎必须{待Q直到外部参与者通知工作管理系l指定的状态完成了。比如,{待可进一步运行的认可?u>动作是在程q行q程中,工作系lؓ响应指定事gQeventQ运行的一D늨序逻辑Qprogramming logicQ。当程q行q程中指定的事g发生Ӟ工作系l启动ƈ执行q些动作。比如,当状态分配给一个参与者时Q发一Email。你也能看出Q状态和动作是如此不同,因此使用同样的术语去描述q些概念是一个坏习惯。我的徏议是避免使用术语“zd”Q?amp;ldquo;状?amp;rdquo;或?amp;ldquo;动作”代替它?/span>
目标领域QTarget usageQ?/h2>
The case for workflow
方便开?/font>
业务程理 (BPM)
~失的一环(Missing linkQ?/h2>
我确实认为工作流pȝ是企业应用开发中~失的一环。将企业业务程逻辑在企业软g中实现的~省方式是分散的。这意味着业务程逻辑散布在各U系l中Q如EJB、数据库触发器、消息代理等{。这样得到的软g难于l护Q结果,企业只能改变业务流EY件作为最后的选择。他们经常能够做的是Q改变流E以适应软g。上q问题也适用于采用大型外部ERP软g包的企业。进一步,假设我们认识到这个问题,q打将一个流E相关的代码都集中v来。对于一个流E来说这很不错,但当你要实现多个程Ӟ你会看到理状态和程变量的代码被到处复制。最后,我们会整理这些代码放C个集中的库中。好Q?..q就是一个工作流理pȝ了,不用费心自己来实玎ͼ你可以从本文后面的列表中选择一?/font>
?/span>
A closer look
WFMS interfaces
Figure 2: Interfaces of a WFMS
q些是WfMC参考模型(reference model of the WfMCQ中定义的五个接口中的四个?
许多工作管理系l?/strong>的开发商想你相信,通过使用他们的图形化程开发工P只要业务分析师就可以生成程定义。这Ux?amp;ldquo;~程很难”q样的事实。开发商的销售h员喜Ƣ说“看,你不用写一行代?amp;rdquo;。不用写代码是好事,可大部分开发商在这点上走的太远Q忽略了在某些场合提供一U将代码集成到流E定义中的机制是很适合的。在?strong>工作?/strong>pȝ作ؓEAIq_Ӟ必须在流E中集成代码。开发流E定义需要业务分析师和Y件开发h员的合作。一个好的图形流E设计工具应该能够支持这U合作?/span>
程定义的四个层?/h2>
在下面这部分Q我试回答q样的问?amp;ldquo;什么是程定义包括的内容?”。这是从各种规范和工h使用模型的原则和概念中ȝ得来的,反映了大部分模型中通用的基本思想。流E定义的内容可以分ؓ四个不同的层ơ:状态(stateQ、上下文QcontextQ、程序逻辑Qprogramming logicQ和用户界面QUIQ?/font>
状态层
上下文层
E序逻辑?/h2>
用户界面?/h2>
一个参与者通过向流E变量中填充数据的事Ӟ来触发结束一个状态。比如,在请假的例子中,老板提供“同意”?amp;ldquo;不同?amp;rdquo;数据到流E中。某?strong>工作?/strong>pȝ允许指定哪些数据可以填充到流E中Q以及它们如何在程变量中存储。通过q些信息Q可以生成从用户攉信息的UI表单。基于流E定义生成用h交表单的Web应用例子Q可以访?a >the jBpm online demo?/span>
工作?/strong>全景
可执行流E与工作管理系l?/strong>的比较(Executional processes versus a WFMSQ?/font>
学术?/h2>
学术界对工作?/strong>的研I可以回溯到上个世纪七十q代。在当前Q研I域趋向于认ؓpetr |?/a>?a >所有流E定义语a之母。关于petri|已有大量先q的分析技术,d?2003 conference on Business Process Management上我有幸会晤了Petri教授。对于大部分够访问和理解的有关Petyri|最好的研究之一?strong>工作?/strong>模式(workflow patterns)?strong>工作?/strong>模式比较了大量的工作管理系l?/strong>q以petri|的术语表述了通用程建模概念?/span>
开放源代码目
商业软g提供?/h2>
工具目录
规范
l论
的益处?
Further reading
A special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article. Thanks
A special thanks for Gustavo Maciel Dias Vieira and Jef Vanbockryck for their valuable feedback on the draft versions of this article.
Tom Baeyens leads the jBpm support organisation, specialized in Java, workflow and business process management. His expertises are both at a technical, analysis and at a business level. Tom is the founder of jbpm.org, an open source workflow engine. Tom is also a member of the expertgroup of the JSR 207: Process Definition for Java. Tom Baeyens can be contacted at tom at jbpm.org