在工作流最基础概念上大家达成的p很少。工作流是最Ҏ(gu)让你感到心烦的话题,因ؓ(f)工作本w的概念?x)和其他相关概念和技术淆在一赗?/font> |
前言
如果数据库系l( database systemsQ像受h敬的智者讲q的条理清晰的故事,那么工作(workflowQ就像一^臭未q的子在大谈各自的“哲理”。之所以这栯Q我是想指出Q工作流pȝ Qworkflow management systemsQ还处于技术发展曲U( technology hype curveQ上的初U阶Dc在q个领域我们面临一个激动h心的阶段。ؓ(f)了描q这一点,可以工作流和关pL据库pȝQRDBMSQ做一个对比。当在Y件开发团队中谈论RDBMSӞ大部分h?x)有一个清晰的概念Q在你和他们交流的时候,Z?x)通过d的点头表C可或理解你所说的。可当用工作流术语讨论工作时Q他们会(x)摇头表示不同意,因ؓ(f)每个人对工作术语都有不同的理解?br />
Figure 1: Workflow vs. RDBMS positioned in the hype-curve
D形成q种状况的原因之一Q是在工作流中用了q多的概c在q个领域中的大量规范和工h有一个是怼的。当Ӟ它们怺之间有重叠ƈ且会(x)怺参考引证?br /> 在介l工作流时有一个话题必d括,那就是工作流和业务流E管理(BPMQ的关系。术语“工作流”通常描述Z计算机系l的一pd相关交互。在开发h员中Q工作流l常被提及。有Ӟ工作的意思是指一些不同的UI界面。业务流E管理的范围比较q,相比之下工作多半局限于技术领域。业务流E管理还从管理h员的角度涉及了非技术问题,比如分析、组l的效率?br />
在本文中Q我首先解释什么是工作管理系l,然后介绍业务程理的优炏V接下来描述一下ؓ(f)什么工作流市场乍看h如此混ؕ。本文给出的主要l论是:(x)选择工作系l是想用工作系l的公司Q将要面对的最困难的事情。ؓ(f)此,本文的核心部分描qC一个流E定义(process definitionQ的四个层次Qؓ(f)你选择工作提供一个基。本文还用中立的语言描述了工作流和BPM的通用概念。最后,l出了一些规范和工具的指导性描q?br />
什么是工作管理系l(WFMSQ?br />定义:
工作系l是以规格化的流E描qC入的软glg,它维护流E的q行状?q在人和应用之间分派zd?br />
Z后面的描qͼ我们先定义一些基本的术语Q流E定义(process definitionQ和程实例Qprocess instanceQ? 一个流E定义是一个业务流E或q程的规格化描述。一个流E实例是程定义的一个运行实体。都目前为止Q概念还比较清晰是不是?但当再深入一步时Q我们就要小心用文字了。如何阐q流E中的步骤,现在q没有一个统一的方式。这是各U工作流规范和工具之间主要的分歧?br />
Z么应当禁止用术语“活动(activityQ?..
程定义通常用一些活动表q。我认ؓ(f)q是D工作领域所有q主要原因。我告诉你ؓ(f)什么:(x)因ؓ(f)术语“活动”淆了状态(stateQ和动作QactionQ之间的差异。在程中,状?(或者说{待状?代表了一U对外部参与者(actorQ的依赖。在程q行Ӟq意味着程引擎必须{待Q直到外部参与者通知工作管理系l指定的状态完成了。比如,{待可进一步运行的认可。动作是在流E运行过E中Q工作流pȝ为响应指定事ӞeventQ运行的一D늨序逻辑Qprogramming logicQ。当程q行q程中指定的事g发生Ӟ工作系l启动ƈ执行q些动作。比如,当状态分配给一个参与者时Q发一Email。你也能看出Q状态和动作是如此不同,因此使用同样的术语去描述q些概念是一个坏?fn)惯。我的徏议是避免使用术语“活动”,使用“状态”或者“动作”代替它?br />
工作系l另一个重要的职责是维护每一个流E运行的上下文信息?程上下文变量(process context variableQ,或简U变量,是与程实例相关的变量。如Q休假申L(fng)开始日期、数据库中一条记录的键倹{文档管理系l中一文档的索引{。通常在流E定义中声明q些变量Q然后在程实例生成Ӟq些程变量被实例化。所有成熟的工作管理系l都支持定制的变量类型?br />
目标领域QTarget usageQ?br /> 使用工作管理系l的目的之一是作Z业应用系l集成(EAIQ的q_。在当前大部分企业IT架构中,各种各样的异构(heterogeneousQ应用和数据库运行在企业内网中。在q些pȝ被应用到l织Ӟ都有一个清晰的目标。例如,客户理、文档管理、供应链、订单、支付、资源计划等{。让我们U这些系lؓ(f)专门应用Q?dedicated applicationsQ。每一个专门应用都包含它们所支持业务程的领域知识。这些专门应用中的自动化程Q被DC业中更大的非自动化流E中。每当一个这L(fng)专门应用安装q投入用,都会(x)带来涉及其他多个应用的新功能需求。企业应用系l集成(EAIQ就是通过使用多个专门应用满软g新需求的Ҏ(gu)。有Ӟq只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务程编码在软g中。可以这么说Q在你购C门应用时Q你是购C一l固定的自动化业务流E。而工作流理pȝ是不必事先知道问题域的相关信息的。工作流pȝ业务流E描qC入ƈ理程实例的执行,q得它比专门应用更灉|Q当然你也要q力编写业务流E的规格化描qͼ。这是Z么说工作系l和专门pȝ是相互补充的。工作流pȝ可以用来理全局的业务流E。如果专门应用支持你所需要的业务程Q那么用专门应用。在此讨论的工作系l的W一U用方式就是:(x)l合所有的专门应用Q用工作流pȝ构徏一个EAIq_?br />
工作系l能够发挥很大h(hun)值的W二个用方式是Q协助涉及多人相关Q务工作流软g的开发。ؓ(f)了达到这个目的,大部分工作流pȝ都有一个方便的机制Q来生成执行d的表单。对于专注于ISO 或者CMM认证的组l,采用q种方式使用工作系l能够显著提高生产率。不用将q程用文字的形式写在U怸Q工作流pȝ使你通过程定义建模实现q程的自动化Q如使用ZWeb的应用)?br />
工作系l的W三U用方式是Q将工作引擎嵌入到其他应用中。在前面我们谈到Q专门应用将指定问题域相关的业务程固化在Y件中。开发专门应用的公司也可以将工作引擎嵌入到他们的Y件中。在q里Q工作流引擎只是作ؓ(f)一个Y件组Ӟ对于应用的最l用h不可见的。将工作引擎嵌入到应用中的主要原因是ؓ(f)了重用(不重复发明轮子)和应用Y件的可维护性?br />
The case for workflow
对于引入工作的l织Q能够在软g开发和业务两个层次受益?br />
方便开?br /> 工作管理系l能够简化企业软g开发甚至维护?
降低开发风?- 通过使用状态和动作q样的术语,业务分析师和开发h员用同一U语a交谈。这样开发h员就不必用户需求{化成软g设计了?
实现的集中统一 -业务程l常变化Q用工作流pȝ的最大好处是Q业务流E的实现代码Q不再是散落在各U各L(fng)pȝ??
加快应用开?- 你的软g不用再关注流E的参与者,开发v来更快,代码更容易维护?
业务程理 (BPM)
在自动化业务程之前Q分析ƈ它们规格化是一件艰苦但?x)有很好回报的工作。e-workflow.org对于分析程能够带了的益处有不错的阐qͼ(x)
提高效率 - 许多程在自动化q程中会(x)去除一些不必要的步?
较好的流E控?- 通过标准的工作方法和跟踪审计Q提高了业务程的管?br /> 改进客户服务 - 因ؓ(f)程的一致性,提高了对客户响应的可预见?
灉| - 跨越程的Y件控Ӟ使流E可以按照业务的需要重新设计?
业务程改进 - Ҏ(gu)E的xQ它们向于流畅和?
我认Z们还遗漏了一个用工作流pȝ最重要的因敎ͼ(x)提高对P代开发的支持。如果Y件中业务程部分不容易更改,l织׃(x)花很大的_֊在开发前的业务流E分析中Q希望一ơ成功。但可?zhn)的是Q在M软g目开发中Q这都很能实现。工作流pȝ使得C务流E很Ҏ(gu)部vQ业务流E相关的软g可以一UP代的方式开发,因此使用工作系l开发更有效、风险更低?br />
~失的一环(Missing linkQ?/strong>
我确实认为工作流pȝ是企业应用开发中~失的一环。将企业业务程逻辑在企业软g中实现的~省方式是分散的。这意味着业务程逻辑散布在各U系l中Q如 EJB、数据库触发器、消息代理等{。这样得到的软g难于l护Q结果,企业只能改变业务流EY件作为最后的选择。他们经常能够做的是Q改变流E以适应软g。上q问题也适用于采用大型外部ERP软g包的企业。进一步,假设我们认识到这个问题,q打将一个流E相关的代码都集中v来。对于一个流E来说这很不错,但当你要实现多个程Ӟ你会(x)看到理状态和程变量的代码被到处复制。最后,我们?x)整理这些代码放C个集中的库中。好Q?..q就是一个工作流理pȝ了,不用费心自己来实玎ͼ你可以从本文后面的列表中选择一个。?br />
一个工作流理pȝ以流E定义作入。在q里Q可以将程定义看作UMLzd图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报仗?..之后Q工作流pȝ负责l护q些程定义的执行状态和上下文。ؓ(f)此,需要通知工作系l状态的变化。运行流E的状态变化可以记录下来,以备监控理?br />
Figure 2: Interfaces of a WFMS
定义 工作系l的定义接口使流E开发h员能够部|流E定义。注意,q里的“流E开发h员”可以是业务分析师和软g开发h员的l合?圈套QPitfallQ?br /> 许多工作管理系l的开发商想你相信,通过使用他们的图形化程开发工P只要业务分析师就可以生成程定义。这Ux于“编E很䏀这L(fng)事实。开发商的销售h员喜Ƣ说“看Q你不用写一行代码”。不用写代码是好事,可大部分开发商在这点上走的太远Q忽略了在某些场合提供一U将代码集成到流E定义中的机制是很适合的。在工作流pȝ作ؓ(f)EAIq_Ӟ必须在流E中集成代码。开发流E定义需要业务分析师和Y件开发h员的合作。一个好的图形流E设计工具应该能够支持这U合作。 ?br />
执行 执行接口使用户和pȝ可以操作程实例。流E实例是程定义的执行。流E定义的控制通过状态机描述。执行接口的两个主要Ҏ(gu)是启动一个流E实例和通知工作系l一个状态结束了?
应用 应用接口代表了由工作系l发L(fng)工作系l和外部pȝ之间的交互。当一个用hpȝ操作一个流E实例的q行Ӟ?x)生成一些事Ӟ如一个迁Uȝ执行Q。流E定义中可以指定一D响应一个事件的可执行代码逻辑Q这D代码和l织内外部的其他pȝ打交道?
监控 理人员通过监控接口获得程q行的确切数据。有Ӟq行日志也可用于审计?
q些是WfMC参考模型(reference model of the WfMCQ中定义的五个接口中的四个?
程定义的四个层?/strong>
在下面这部分Q我试回答q样的问题“什么是程定义包括的内容?”。这是从各种规范和工h使用模型的原则和概念中ȝ得来的,反映了大部分模型中通用的基本思想。流E定义的内容可以分ؓ(f)四个不同的层ơ:(x)状态(stateQ、上下文QcontextQ、程序逻辑Qprogramming logicQ和用户界面QUIQ?
状态层
所有状态和控制的表述Q都属于业务程的状态层。标准编E语a中的控制来源于Von Neuman体系。控制流定义了必被执行的指令的序Q控制流由我们书写的命o(h)、if语句、@环语句等定。在业务程中的控制基本与此一致。但在业务流E中不是使用命o(h)而是使用状态作为基本元素?br />
在流E中Q状?(或者说{待状?代表了一U对外部参与者(actorQ的依赖。状态的意思就像“现在Xpȝ或某某h必须作某些事Q在此等待直到参与者通知q些d已完成”。状态定义了一U对外部提供l果的依赖。状态典型的例子是批准步骤(stepQ?br />
程定义中的状态也指定了执行依赖于哪个参与者。在zd图中Q泳道(swimlanesQ的标注代表q些参与者的名字。工作流pȝ使用q些信息构徏d列表Q这是一般工作流pȝ都有的功能。如前所qͼ参与者可以是Z可以是系l。对于需要h参与的状态,工作系l必dq行时计出具体的个人。这L(fng)计算使工作流pȝ必须依赖于组l结构信息。关于这斚w的一非常有的文章是在further reading section提到的“工作流应用中的l织理”( Organizational Management in Workflow ApplicationsQ?br />
程定义的控制流包含一l状态和它们之间的关pR状态之间的逻辑关系描述了哪些执行\径可以同时执行,那些不可以。同步执行\径用分叉QforksQ和联合QjoinsQ徏模,异步执行路径用判断(decisionsQ和合ƈQ?mergesQ徏模。注意在大多数模型中Q在每个状态之前都有一个隐式合q?br />
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?
在用囑Ş表述业务程Ӟ只徏模状态层Q状态和控制)Q不要包括动作。这意味着囑Ş中的矩Ş都是状态而不是活?
如果多个q移到达一个状态,~省定义Z需要同步的合ƈQmergesQ?
在流E运行过E中Q工作流pȝ用一个o(h)牌(tokenQ作为指针跟t流E的状态。这相当于Von Neuman体系中的E序计数器。当令牌到达一个状态时Q它被分配给工作系l等待的外部参与者。外部参与者可以是个h、组l或者计机pȝ。我们定义流E运行的执行人或pȝ为“参与者”(actorQ。只有在工作系l将令牌分配l一个参与者时Q才需要访问组l结构信息。工作流pȝ通过分配令牌构徏d列表?br />
上下文层
程上下文变量(process context variableQ?Q或U变量,是与程实例相关的变量。流E开发h员可以用流E变量存储跨流E实例整个生命周期的数据。一些工作流理pȝ有固定数目的数据cdQ另一些你可以定义自己的数据类型?br />
注意变量也可以用来存攑ּ用( referencesQ。一个变量可以引用如数据库中的记录、网l上的文件。什么时候用引用,取决于用引用数据的其他应用?br />
和流E变量相关的另一个o(h)人感兴趣的方面是Q工作流pȝ如何数据{化ؓ(f)信息。工作流是用于组l内部跨各U异构系l实CQ务和数据协同的。对于业务流E中人工执行的Q务,工作系l负责从其他相关pȝQ如SAP、数据库、CRMpȝ、文档管理系l收集数据。在业务程的每一个h工步骤,只有相关联的数据被从异构系l中攉和计。通过q种方式Q从不同pȝ来的数据被{换ƈ展现Z息?br />
E序逻辑?br /> 如前所qͼ动作是在程q行q程中,工作系l响应指定的事gQeventQ执行的一D늨序逻辑Qprogramming logicQ。程序逻辑可以是二q制或源代码形式的、用M语言或脚本编写的软g。程序逻辑层是所有这些Y件片断和关于在什么事件发生时调用它们的信息的l合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERPpȝ中拿数据和更新数据库?br />
用户界面?br /> 一个参与者通过向流E变量中填充数据的事Ӟ来触发结束一个状态。比如,在请假的例子中,老板提供“同意”或“不同意”数据到程中。某些工作流pȝ允许指定哪些数据可以填充到流E中Q以及它们如何在程变量中存储。通过q些信息Q可以生成从用户攉信息的UI表单。基于流E定义生成用h交表单的Web 应用例子Q可以访问the jBpm online demo?
工作全?/strong>
可执行流E与工作管理系l的比较QExecutional processes versus a WFMSQ?br /> 当前在BPM领域中,关于可执行业务流E的规范有趋向于l一集中的趋ѝ?XLANG, WSFL 和BPML合ƈ为基于交互(消息交换Q的BPEL。BPEL在面向服务体pȝ?SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法Q这套语法可以看作一U编E语aQ用来描q包括对WSDL定义的服务调用的控制?br />
在可执行业务程和基于状态的工作管理系l所使用的方法中Q我注意C三点主要的区别:(x)
Z状态与面向消息Q基于状态的工作系l以状态(或者活动)概念Z心。工作流引擎l护状态ƈ计算从一个状态到另一个状态的q移。另一斚wQ像BPEL q样的可执行程以对输入消息响应的定义ؓ(f)中心。一l这些响应外加其他信息(other bells and whistlesQ可以看作一个业务流E。这也解释了Z么BPEL可以看作是对Z状态的工作系l的某些斚w的补充。一个响应输入消息的BPEL onMessage事g处理器,可以在工作流状态之间的q移中执行?
程实例ID与消息相兛_理:(x)可执行业务流E的复杂性之一来自消息相关性的处理。流E描q的一部分必须说明BPEL引擎如何从输入消息中定具体程的标识。这必须Z输入消息的一个数据项。而工作流pȝ在每个流E实例生成同时生成了实例IDQ客L(fng)在后l调用引擎API时用这个ID?
工作引擎API与抽象服务端点(endpointQ:(x)工作系l提供一l集中的APIQ客L(fng)通过调用API完成与所有流E实例的交互。在可执行业务流E中Q每个流E表Cؓ(f)一个服务。这意味着对于每个程定义都有一个不同的讉K炏V?
学术?br /> 学术界对工作的研究可以回溯C个世U七十年代。在当前Q研I域趋向于认ؓ(f)petr |是所有流E定义语a之母。关于petri|已有大量先q的分析技术,d?2003 conference on Business Process Management上我有幸?x)晤了Petri教授。对于大部分够访问和理解的有关Petyri|最好的研究之一是工作流模式(workflow patterns)。工作流模式比较了大量的工作管理系lƈ以petri|的术语表述了通用程建模概念?
开放源代码目
最后我们看看真实世界中的工作流理pȝ。选择一个工作流理pȝ是一件困隄事情Q但有选择L没有选择好?-) 本文阐述工作基本概늚目的之一Q就是你能够作更好的选择。但我也意识刎ͼ对于现在的Y件架构师来说Q选择工作系l是一件最h战性的工作?br />
下面的列表来源于三个地方Qmy previous article, the list of Carlos E Perez, ?list by Topicus.
jBpm - jBpm是本文作者编写的一个灵zd扩展的工作流理pȝ。作为jBpmq行时server输入的业务流E用简单强大的语言表达q打包在程档案中?jBmp工作流应用开发的便利性和杰出的企业应用集成(EAIQ能力结合了h。jBmp包括一个Web应用E序和一个日E安排程序。jBmp是一l?J2SElgQ可以作为J2EE应用集群部v?
OpenEbXML - OpenebXML目致力于提供一个ebXML框架Q主要支持不久将?UN/CEFACT和OASIS发布的ebXML规范2.0版?
Werkflow - Werkflow是一个灵zd扩展的基于流E和状态的工作引擎。它的目标是满可以惌的所有工作流E,从企业的业务流E到范围的用户交互程。通过使用可插拔和分层l构Q可以方便地容纳各种工作语义?
OSWorkflow - OSWorkflow最独到之处是绝对的灉|?
wfmOpen - WfMOpen是WfMC和OMG中所谓工作流设施Qworkflow facilityQ?(工作引?的J2EE实现。工作流通过扩展的XPDL描述?
OFBiz - OFBiz工作引擎基于WfMC和OMG的规范,使用XPDL作ؓ(f)程定义语言?
ObjectWeb Bonita - Bonita是一个符合WfMC规范、灵zȝ协同工作系l。对于各U动作如程概念建模、定义、实例化、流E控制和用户交互{提供了全面的集成图形工兗?100% Z览器、用SOAP和XML数据l定技术的Web Services装了已有的工作业务方法ƈ它们以ZJ2EE的Web Service形式发布。基于活动预模型的W三代工作流引擎?
Bigbross Bossa -速度非常快、轻量的引擎,使用富有表达能力的Petri|定义工作流Q不要求关系数据库,使用单,能和Java应用集成。事实上Q它是按嵌入式设计的?
XFlow - XFlowq行于EJB和servlet容器中?
Taverna - Taverna目的目标是提供一U语a和Y件工P方便在eScience中用工作流和分布计技术?
Enhydra Shark - Shark完全ZWfMC和OMG标准Q?XPDL作ؓ(f)工作定义语a。流E和zd的存储用Enhydra DODS?
PowerFolder - PowerFolder包括开发h员用的studioQ管理环境和一个运行时引擎?
Breeze - Breeze一个轻量、跨q_、基于组件的工作引擎原型?
Open Business Engine - Open Business Engine是一个开放源码的Java工作引擎,支持WfMC规范Q包括接?QXPDLQ、接?/3QWAPIQ和接口5。OBE为活动的q行提供了一个可控的集中环境。OBE主要ZJ2EE实现?
OpenWFE - OpenWFE是一个开放源码的Java工作引擎?它包括可升的三个组Ӟ(x)引擎、工作列表和W(xu)eb界面。它的流E定义语a虽然使用XML格式Q其灉|来源?SchemeQ一ULisp方言?
Freefluo - Freefluo是一个用Web Service的工作流协同工具Q可以处理WSDL的Web Service调用。支持两UXML格式的工作流语言QIBM的WSFL和XScufl。Freefluo非常灉|Q它的核心是不与M工作语a或执行架构关联的可重用协同框架?Freefluo包括可执行用WSFL一个子集描q的工作的q行库?
ZBuilder - ZBuilder3是第二代工作开发管理系l,也是一个开放源码品。它Z同的工作引擎和工作定义了一l标准的JMX理接口?
Twister - Twister的目标是提供C代、易集成、应用Java领域中最新成果、面向B(ti)2B的工作流解决Ҏ(gu)。流E引擎基于BPEL业务程规范和W(xu)eb Service标准?
Con:cern - con:cern工作引擎基于扩展的案例QcaseQ处理方法,程׃l具有前后条件的zdl成?
商业软g提供?br />
工具目录
http://dmoz.org/Computers/Software/Workflow/Products/
A collection of links to tools for modelling business processes and workflows maintained by Bart-Jan Hommes at TU Delft, the Netherlands.
规范
Michael zur Muehlen作了一个所有工作流相关规范的介l性的qȝ片,很不错?br />
我同意John Pyke ?Wil van der Aalst 的观点:(x)工作标准还处于制定阶段。现在存在大量相互丛叠的规范?br />
在我看来Q导致规范如此之多而同时每个规范的应用又很有限的原因是Q在工作最基础概念上大家达成的p很少。工作流是最Ҏ(gu)让你感到心烦的话题,因ؓ(f)工作本w的概念?x)和其他相关概念和技术淆在一赗可以D一个具体的例子Q比如说工作完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一个工作流理pȝQ但是不能假定L必须通过Web Service接口讉K工作系l接口。一些规范造成了这L(fng)假设。除了Web ServiceQ其他容易淆的概念和技术包括:(x)Email、流E之间的通讯、Web应用和组l结构?br />
在工作流领域W一个致力于标准化工作的是Workflow Management Coalition (WfMC)Q开始于 1993?WfMC发布的参考模型很不错Q它定义了工作流理pȝ和其他相关部分之间的接口。WfMC的另一Ҏ(gu)果是XPDL规范?XPDL定义了描q工作流声明部分Qdeclarative partQ的XMLl构。我个h认ؓ(f)Q参考模型和XPDL是目前最好的规范?br />
JSR 207: Java的流E定?-是由Java Community Process (JCP) 发vQ如何在J2EE应用服务器中实现业务程自动化的标准。其基本模型是定义一个特D类型的ejb session beanQ作Z个业务流E的接口。JSR207标准化一lXML元标讎ͼmeta tagsQ作为JSR175元数据的一部分。JSR207 session bean和元数据作ؓ(f)ejb容器的输入,然后生成l定Ҏ(gu)的代码,q些Ҏ(gu)在元数据中描q。此规范q处于初U阶D,没有发布M内容。专家小l成立于 March 2003.
WfMCs XPDL - WfMC是由U?00家成员参加的l织Q基于参考模型定义了一pd的标准。参考模型用用例Quse caseQ的形式描述了工作流pȝ和其他相关部分之间的关系。XPDL是WfMC制定的描qC务流E控制流Qcontrol flow Q的XML格式规范?
ebXMLs BPSS - ebXML是协同流E的相关标准集,主要x不同公司程之间的通讯。可以看作EDI的承者?ebXML是由O(jin)ASIS和UN/CEFACT联合发v?BPSS 是ebXML的规范,其中的概念和本文阐述的很接近?
BPMIs BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定义了一个规?(BPMN) Q描q如何将“可执行”业务流E可视化的表现?
BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL׃pdZ消息交换的规范( XLANG, WSFL, BPMLQ生。还有一个将此规范引入到Java的提? BPELJ。此规范描述如何处理输入的消息,而不是对程状态进行徏模。就像本文提到的Q它不是一个关于业务流E规格化定义的规范。简单的_(d)可以它看作XML形式的编E语aQ提供将WSDL-Servicesl合成控制流的能力。顾名思义Q此规范重点在(也不只限于)Web Service?
OMGs Workflow management facility - ZWfMC规范Q定义如何向CORBA转换?
UML - UML定义了徏模和设计软gpȝ?cd。每cd包括可视化的表示和语义。其中活动图的目的就是要可视化的表现业务程。注意到在一个流E定义包含四个层ơ的内容Q我x出的是:(x)一个流E定义包含的内容q远多于它的可视化部分。UML只涉及了可视化部分?
RosettaNet - RosettaNet主要定义了一l?Partner Interface Processes (PIP). 一?PIP 描述了一个有两个交易参与者、包括消息格式的程?
UBL - The Universal Business Language (UBL)定义了用于不同组l间通讯的XML文档标准库。可以看作是对ebXML的补充,因ؓ(f)ebXML只定义了建立l织间流E的基础。此规范的竞争对手是 RosettaNet标准中的一个子集?
l论
我在本文中指出工作流市场q属于年轻而又混ؕQyoung and wildQ的阶段Q但已经有可靠的工具存在?
到目前,像J2EE?NETq样成熟的集成^台才可用。在q样一个^Cq行工作管理系l才能真正发挥工作流pȝ的附加h(hun)倹{这也是Z么只有在今天Q工作流pȝ才被重新发现?
?The case for workflow一节,我们介绍了引入工作流理pȝQ是如何同时在技术和业务上带来投资回报的?
工作在技术发展曲U的位置表明QBPM和工作流中用的概念q需要明?
“开放源代码目”和“商业Y件提供商”列表中的工P可以让你获得工作和业务程理的益处?
从以上所有这些中能得到的l论是:(x)
规范q没有成熟,没有标准被大范围采用
对于现在惛_用BPM的公司来Ԍ比较工作系l是一个极其困隄挑战
管标准化工作慢了一拍,可好的工作流理pȝq是有的。这对于已经在挑选工作流pȝ的组l来说是一个好消息?
我希望本文能够激发你对工作流的兴ƈ且能够ؓ(f)你进行有效的Ҏ(gu)提供正确的背景知识?/p>