BPEL与XPDL的定位区别

日期: 2008-06-02 作者:hongsoft 来源:TechTarget中国

  根据最近对几个BPEL产品的研究,根据以前对XPDL的了解,分析了BPEL与XPDL在业务目标方面的主要区别。


  定义、缩略语:


  XPDL:The XML Process Definition Language。


  BPEL:Business Process &#101xecution Language


  背景描述:


  公司最近交给我的任务之一,是通过分析BPEL的业务目标定位,来帮助我们分析在EOS产品中怎么利用BPEL(BPEL4People,HumanTask),实现产品的“帮助用户快速构建稳定,易用,灵活,易管控的SOA应用”的目标。


  最近两周研究的产品主要有下面几个:


  1)ActiveBPEL(包括Designer和ActiveVOS和ActiveBPEL Server)
  2)Apache ODE


  前期的工作学习中,已经学习过或者使用过的产品有:


  1) IBM Websphere Process Server
  2) JBoss jBPM-BPEL
  3) BEA Aqualogic BPM Suite


  研究的技术和规范内容主要是:


  1)BPEL2.0
  2)BPEL4People 和HumanTask
  3)下载了最新的XPDL2.1规范,重新看了一遍
  4)重新看了一遍BPMN(没有作为重点)


  下面主要讨论的是BPEL和XPDL的业务目标方面的区别,对于技术方面的区别,会根据工作情况,在后面再另外写文档说明。


  1 业务分析人员的视角


  1.1   业务分析人员从用户的视角来做过程建模


  业务分析人员没有能力从系统的视角来对过程做建模,他们建模的结果可以告诉我们的是:用户执行什么样的操作来完成整个过程;他们建模的结果不可以告诉我们的是:系统怎么样对用户的操作做出反应。[请参见jBPM的leader的博客:http://blogs.jboss.com/blog/tbaeyens/2006/07/05/About_BPM_miracles_and_what_you_can_expect_in_real_life.txt]


  我们举个例子来说明上面这段话的意思:对于普元今年做的招聘活动,会有一个流程来对应。对于HR的xiaofang(严格说来,她是一个用户,不是一个业务分析人员;但是业务分析人员的需求也是从她这里获取的)来说,下面这个图她是能够看明白的:



  上面是招聘活动的状态图,业务人员基本可以看懂;但是xiaofang肯定不能告诉我们技术人员说:是的,这个就是我们的流程。因为这个图其实还没有描述“用户执行什么样的操作来完成整个过程”,我们在状态图上加上部分“用户活动”,对xiaofang可能更容易明白一点:



  在图上加的几个注解,可以帮助用户和业务人员和技术人员更好的理解整个流程。上面这个图是状态图和活动图的结合。


  要特别说明的是:业务人员不会去根据系统边界,消息发送,业务对象等内容来思考问题;上面的图中,不会出现“invoke”一个服务的活动(BPEL),也不会出现“自动活动”(xpdl)。


  1.2 业务人员的工具


  业务人员的工具当然首先是vendor提供的产品,但是他们还应该有另外一个工具:简化的BPMN。


  简化的BPMN的第一层含义:首先应该是BPMN。


  比如对于“招聘流程”,其实可以画出多个 上面的那个“状态活动图”:内部推荐的和普通应聘 的“招聘流程”并不相同,初级人员招聘和高级人员招聘也不相同。


  Xiaofang不可能在图中用if…else来表达不同的情况,她只能对内部推荐的情况,画一个图给我们;对普通应聘的情况,画一个图给我们……


  我们不可能对每个情况定义一个流程的,那样就是硬编码而不是BPM了。所以,业务分析人员需要把xiaofang给的几个情况结合考虑,最后用BPMN画的图大概如下:



  是不是比较复杂?有点看不懂?是的,所以我们需要的是“简化的BPMN”。BPMN是一份超过300页的规范。即使业务分析人员决心去掌握所有这些概念,它也是难以思考的。( Michael)这个调查的结论是日常只使用了大约25个BPMN结构。


  不过我从BPEL4People的TC的member那里问到的情况是:BPEL4People定稿后,还将去调整BPMN,应对BPEL领域的新的变化。


  1.3  分析模型与实现模型的鸿沟


  根据上面的图,我们已经得到了分析模型,但是还没有实现模型。


  Alast这些以前专攻XPDL领域的学院派,现在也在做BPMN-BPEL的转换等方面的工作;但是需要说明的是,我们不能要求业务分析人员根据BPMN图,直接得到实现模型。这个已经是业界的共识(请参考bpmn-xpdl-and-bpel  和  BPEL implement等等很多文章)。


  实现模型还是要靠BPEL。



  2  的业务定位BPEL


  前面的招聘流程的例子中,BPEL的图可能是如下:(请参考BPEL)


  我们为图取的名称是“Application Service”,它本质上只实现了一个服务,而不是一个流程。流程在哪里呢?流程已经被业务分析人员用BPMN给画出来了,流程图涉及到多个人多个系统多个活动多个状态;而我们的BPEL服务实现,只是实现了一个或者多个服务,它只管理这些服务的生命周期。


  3  的业务定位XPDL


  实际上,WFMC也认为XPDL与BPEL是不同业务定位的两个标准,它的说明如下:


  How Does XPDL Compare to BPEL?
  BPEL and XPDL are entirely different yet complimentary standards.  BPEL is an “&#101xecution language” designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-a-vis application integration.
  The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to “run” the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is not an &#101xecutable programming language like BPEL, but rather a process design format that literally represents the “drawing” of the process definition. Specifically, it has ‘XY” or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPMN process diagram. For this reason, XPDL is effectively the file format or “serialization” of BPMN, as well as any non-BPMN design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 70 tools which use XPDL for storing process models.)


  WFMC用了些什么名词来形容XPDL呢?design format,process diagram,BPMN,DRAWING….等等。


  WFMC认为BPEL才是“执行语言”,而认为XPDL主要用来“建模”。实际上通过前面的分析我们也很容易就明白:XPDL领域主要还是利用了活动图,状态图和FSM等元素;这些元素的结合很容易用来表达一个流程的建模模型;但是——–我们的平常的做法,就是直接拿这个建模模型来作为了执行语言。


  我们这样做有什么缺点呢?


  首先,我们用XPDL表达了流程的建模模型,但是我们为了让它可执行,加入了太多的业务人员不能理解的元素,导致业务人员不能直接使用它;


  其次,我们用XPDL表达了可执行的元素,为了容易“建模”,加入了很多“活动”等“建模”元素,这些元素一般会需要去配置很多的属性,而这些属性是干扰和影响“执行”的。


  XPDL就是一个建模和执行的混合体,是一个分析和实现的混合体。


  4  总结


  就算我们前面的分析是正确的,但是我们已经用XPDL很久了,我们是否要用BPEL呢?


  这个还是需要我们另外花很多的时间去研究和证明的,下面是目前的看法,具体怎么做需要大家一起来判断分析:


  1) 个人认为XPDL其实不算是个标准(支持它的vendor都非常小,而且支持得到底怎么样,说不清楚)
  2) 用BPEL当然也是“遵徇了WFMC模型”的 (就如很多国内厂商的宣传一样)
  3) 的支持vendor就比较多,而且都是比较大的公司和组织BPEL
  4) 其实IBM以前也支持XPDL的(教材里面的FileNet,非常的XPDL);但是,现在基本很少听到有人提到它了;从IBM的态度我们也应该能够找到我们的方向(从另外说明了一点:IBM大力做BPEL不是因为纯商业原因,因为它做XPDL也比我们强)
  5) 集成应该是BPM的一大主力方向,集成是BPEL的最大优势。(具体为什么,需要再做具体的分析比较)


  原文出处:http://gocom.primeton.com/blog10263_2403.htm

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者

hongsoft
hongsoft

相关推荐

  • 在iBPM和BPM间做选择 不一定非此即彼

    大多数系统都有一样的能力,在很多人看来,除了BPM或者iBPM这两个标签以外,实际上它们之间并没有任何区别。

  • 用BPM策略对遗留应用现代化

    一些人提议把业务流程管理作为应用现代化的手段之一,但也有人对此提出质疑,但采用BPM策略可以成为现代化遗留应用的明智方式。Tom Nolle对此进行了解释。

  • RESTful API设计给开发人员带来怎样的未来?

    在模块化应用世界里,最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。

  • 云BPM新常态解析

    云端业务流程管理已经不再是什么新鲜事,更不再是什么可怕的方法来管理重要的业务流程。现在,它已经普遍被认为是一种新常态。组织已经从这一技术中获益,使它来更有效地访问和管理企业信息。