技术开发 频道

过程组件模型

【IT168 技术文章】

    这准确道出了BPM行业中或许并不明显的巨大分歧。“BPM族人”是指那些专注过程建模的人。他们的出发点在于分析那些描述组织内人和系统协作方式的过程。在建模者眼中,最初的焦点并非技术,而是描述人和系统协作方式的非技术业务分析。过程自动化在许多这类BPM项目中甚至根本未被考虑。这些项目的最终目标实际是要通过记录核心业务过程来更深入地了解组织是如何运作的。由这个背景所产生的纯BPM产品旨在通过软件自动化来简化对这类业务过程的描述。这个阵营我称之为BPM建模者。

    “WS族人”是指那些专注创建可执行过程的人。可执行过程是作为业务过程管理系统(BPMS)输入的软件部件。它通常由图形化的图表表示。目前,只有一种可执行过程语言被大型提供商采用,它就是BPEL。BPEL是基于WS-*标准的,这也是那些专注自动化的人被称为“WS族人”的原因。随着BPEL逐渐得到认可,服务编制最近也受到了吹捧。这个阵营我称之为编制开发者。

    两个流派的共同之处在于都关注图形化的图表且都包括了等待状态。对BPM建模者和编制开发者来说,图表是一个很重要的工具。图表能为某个过程提供一个快速概览。尽管这是个强大的工具,但对于这种可察觉的简单性要保持警惕。因为,看起来相似的图表会由于所使用的符号或底层可执行过程语言的不同,其含义会有巨大区别。另外,图表的用途也是一个非常重要的考虑因素。对于业务分析师来说,过程图表的目的是为了帮助向另一个人解释业务过程。这些图表提供了一个整体概览,一定程度的模糊性是允许的。对于可执行过程语言,图表是定义计算机系统必须遵循的行为方式的过程的一部分。因此,这种过程必须含义明确且能被准确地解释。

    本质上,等待状态的包含是个更技术性的话题,但在两个流派中也都找到它的踪迹。当业务分析师绘制业务过程时,不同的活动可能会关联到不同资源。一些活动会翻译成人工任务,而另一些则会翻译成可在计算机系统中执行的一段软件代码。假如这一过程是自动完成的,过程引擎会驱动过程的执行。这意味着引擎内部会自动地执行一些活动。否则,如果活动在过程引擎外执行,那么引擎就需要跟踪当前状态并在接收到外部实体发来的信号前保持等待。例如,这个外部触发器可能是用户对Web应用中表示任务完成按钮的一次点击。类似的还有,ERP系统可能通知过程引擎某个发票已经处理完毕。等待状态的概念或许显得有些抽象,你或许会问这和工作流或过程语言的讨论有什么关联性。一个重要原因就是象Java这样的传统编程语言不支持可持久化的等待状态。

    这篇文章认为业务过程的分析和实现间的差距远比当前工作流工具市场所显现出的还要大。同时,本文还提出了解决这种状况更现实的办法。文中对当前标准和项目进行了足够深入地探讨,以便让你可以理解它们与这些流派的关联方式及其原因。在讨论中,我会指出每一个被提及技术的优缺点,以及正确使用它们的方式。

    文末,我会介绍一种名为过程组件模型的工作流新技术。这种框架可以处理多种过程语言,为那些能将分析过程图更好地转换成可执行过程的过程语言提供了支持。

    WS-BPEL

    什么是BPEL

    WS-BPEL是一个用于服务编制的OASIS标准。服务编制就是将一组现有服务组合成一个新服务。

    这是对BPEL过程的简单地剖析:部署一个BPEL过程会导致为该过程发布一个服务。这个BPEL过程会指定必须发布的服务,以及这些服务操作的实现。

    

 
    接下来以图1显示的过程为例,我们会通过解释一些最典型的BPEL活动来向您展示一幅关于BPEL基础的优秀画卷。在BPEL过程中,每一个接收(receive)活动都对应一个过程部署时要发布的服务操作。最上面的接收活动receiveOrder是一次新的过程执行的起点。因此,每当客户调用左边的订购(order)操作,就会通过离开初始接收活动来启动一次新的过程执行。

    下一步是调用(invoke)活动。调用活动会调用另一个WSDL服务并将响应消息收集到一个过程变量里。在我们的例子里,getQuote在供应商上被调用。

    来自输入消息的信息可以被存储在过程变量中。整个消息都可以被存储,包括XML片断或XSD基本类型。象extractProductName这样的赋值(assign)活动可以从一个变量中(一般是基于XML的内容)提取部分信息,然后将之保存到另一个变量中。这样,变量就可被用来为其他调用或当前请求的响应合成消息。

    接收活动receiveQuote将使过程实例处于等待状态,直到提供商调用submitQuote服务操作。拥有submitQuote 操作的服务也会在BPEL过程部署时发布。当供应商传入了与这个订单有关的报价后,过程将继续执行并离开receiveQuote活动。

    应答(reply)活动用来为未完成的服务请求组织一条响应消息。因此,应答活动只有在这种情况下才有意义:在进入一个具有IN-OUT消息交换的服务操作前,接收操作接收到了一条消息。

    注意,在供应商调用submitQuote操作时,输入消息必须通过离开这个接收活动来触发过程继续执行。这是BPEL的另一特性,它被称为关联(correlation)。在BPEL过程中,关联是指输入服务请求消息和当前正在等待此消息的过程实例间的匹配。假如一个接收节点被标记为开始,该操作上的输入消息将会创建一个新的过程实例。一般说来,输入文档中的某些数据项这时会被标记为一个唯一的关联ID,如订单ID。根据输入消息文档中包含的订单ID,过程中接收节点的输入消息稍后会关联到对应的过程实例上。在现实中,关联集可以由多个属性的多个个体集合组成,但为了简单起见,那些额外的复杂性略去不谈。

    伙伴链接(partner links)用来标识那些参与BPEL过程通信的外部团体。从BPEL过程到伙伴的服务调用和伙伴对BPEL过程的调用都关联到伙伴链接。这两个方向都被称为角色(roles),每一个角色对应一个端口类型(port type)。端口类型指定了伙伴链接中该方向的通信接口。因此一个伙伴链接可以声明两个角色,需要指出这两个角色中的哪一个代表了BPEL过程端。与伙伴链接中BPEL过程角色相对应的服务会在部署过程的时候发布。另外一个则会在服务调用时使用。

    这里总结了BPEL的大部分基本内容。另外一些是BPEL的更高级特性,如补偿处理(compensation handling)、事件处理(event handling)、并发执行路径和定时器。因它们与以后的讨论没有太大的关系,所以没有在这里介绍。

0
相关文章