XPDL及BPEL工作流比较.docx

BPEL 及其发展历程BPEL 及其发展历程作为SOA 的关键技术，SDO 和SCA 分别为SOA 提供了数据模型和服务组件模型的定义标准。那么到目前为止，SOA 是否能解决用户所面临的所有业务问题呢？让我们先来看看下面的例子。 一个企业将提供一个订单处理服务。这个订单处理服务在接收到订单后，调用其内部的订单审核服务，而后调用银行提供的支付服务以支付货款，最后调用物流公司，提供的送货服务将货物送给客户。这里用户所要做的就是调用订单处理服务下订单，而后他就可以坐等货物的到来了。他不需知道这个订单处理服务的内部都干了些 什么。图14-1 描述了这一场景。图14-1 订单处理场景目前有三个现存的服务：企业内部的订单审核服务，银行提供的支付服务，以及物流公司提供的送货服务。在SOA中，我们可以将它们封装成三个SCA 组件，而用户输入的订单数据可以用SDO 来建模。现在我们需要解决的问题是，如何将这三个SCA组件以想要的顺序进行调用，而这一调用过程对用户来说又是透明的呢？SCA不能解决的问题通过前面SCA 的相关章节，我们知道SCA 规范定义了SCA 组件的封装标准以及如何将多个SCA 组件进行连接（wire）。SCA组件之间的连接表明了这两个SCA组件之间有服务的调用的关系，即一个SCA组件的实现调用了另外一个SCA组件的服务。我们这个场景中的三个SCA组件是相互独立的，它们之间并没有服务的调用关系。我们无法用SCA组件的连接来达到目的。看来我们还需要提供另外一个SCA组件，这个SCA组件的实现将分别调用订单审核、支付服务以及送货服务这三个SCA组件。实际上，这个SCA组件的实现就是一个业务流程逻辑，它将按照业务需求，以一定的顺序调用现存的服务。也就是说，这个SCA组件实现了对其他SCA组件的编排。而用户只需要调用这个SCA组件就可以获得所需的流程服务。图14-2说明了这一场景。图14-2 SCA组件化的订单处理场景可以看到，订单处理SCA将按照顺序调用订单审核SCA，支付SCA以及送货SCA。我们该如何实现这个订单处理SCA呢？ 订单处理SCA是按照预定的业务逻辑调用现有的SCA组件，从而形成了一个业务流程，但它本身并不涉及任何具体服务的实现。我们可以选择C++，Java等编程语言来实现这样的调用逻辑，但这将面临以下问题：无法以图形化的方式将业务流程逻辑展现给用户。在流程的设计上，我们将不得不借助于图形工具来直观地表现流程逻辑，而后再由编程人员根据这个流程逻辑进行编程实现。业务流程设计人员与IT的设计人员将使用不同的表达方式进行各自的设计，他们之间将存在沟壑并带来理解上的差异。表达方式的不一致最终可 能导致系统的实现与最初的业务需求不能吻合，同时这也与SOA的业务与IT对齐的思想相违背。维护上的困难。企业经常会根据实际需求不断调整流程逻辑。一旦流程出现任何改变，我们将不得不相应修改代码，重新编译部署。这样必将付出较大代价。无法抽象出组件化的流程语义。纷繁复杂的业务流程也蕴涵着某些共性的逻辑，我们可以把它们抽取出来以便重用。比如刚才的订单处理流程以串行的方式调用了一系列的服务，因此我们可以抽象出串行组件来为流程的建模使用。同样，实际的流程还可能有并行处理的组件，循环调用的组件等。代码实现的流程逻辑很难 进行这种流程级别的粗粒度的抽象。即使能够将相应的实现封装成类库来重用实现逻辑，这也只能是企业内部或局部范围的代码级别的重用，而无法形成统一的标准 和语义。看来我们还需要一种标准，它能按照业务需求完成多个SCA组件的调用与编排，从而形成业务流程服务。具体来说，这个标准应具备以下特点：完全支持SCA组件的调用；只是定义服务的调用逻辑与规则，不应涉及具体的服务实现；能够支持将SDO定义的业务对象定义为流程的接收参数，服务的调用参数以及流程的中间变量；这个标准定义的业务流程本身也能够被封装为SCA服务组件对外提供服务。BPEL应运而生我们知道，SCA的服务调用以及接口描述都基于Web服务，而SDO的建模则基于XML Schema。对这两者都能进行很好支持的WS-BPEL标准自然成为合适的选择。BPEL（Business Process Execution Language） 即业务流程执行语言，是业界在以XML、Web服务为基础的诸多规范之上提出的一种新型的业务流程定义语言。它以业务流程及其参与者的交互为基础定义了业务流程的描述语法，用于业务流程建模。其中，业务流程及其参与者的交互用Web服务接口标准加以描述。因此BPEL流程可直接调用符合Web服务规范的服务。BPEL用来描述多个服务交互的协作与协调，从而对外提供流程服务，以达到某种商业价值。BPEL标准的早期版本称为BPEL4WS（Business Process Execution Lan