本文意译自TSS的“BPEL and Java”,为的是更深入地理解这篇好文章,也算是我的一篇学习笔记。
简介
在企业应用开发领域,每一种新技术和平台背后的动力和思想,无一例外的是提供一个能够更有效的开发企业商务应用的环境-商务应用和业务过程更为紧密地保持一致,不能太复杂,而且能做到随着业务过程的变化而轻松地改变。
Java提供了一个极好的企业应用开发平台,但仍然不能做到分离业务过程。在一个公司内部,业务过程需要相互协作和集成,公司之间也一样。因为存在着不同的技术和功能,集成不同的应用总是一项艰难的任务。
应用集成方面的最新进展,来自Service Oriented Architecture(SOA)和Web服务技术。从SOA的观点来看,不同的应用系统以Web服务的形式来发布它们的业务功能。因此,我们使用统一的标准方式(通过Web服务)来访问遗留系统和新开发应用的功能。这种标准方式很重要,因为通常大多数公司存在着很多需要集成的应用。
如果仅仅是开发Web服务并把这些功能发布出来还不够。我们也需要一种把这些功能按正确的顺序组合起来的方法-定义使用这些Web服务的业务过程。我们显然需要一个简单直接的方式来定义这些业务过程,尤其是我们都知道业务过程通常易于变化,因此我们需要很容易地修改这些业务过程。
这正是BPEL(Business Process Execution Language for Web Service,也称作WS-BPEL或BPEL4WS)如此重要的原因。BPEL用于组合这些Web服务,因此可以算是SOA的一种实现方式。
我们将在本文讨论BPEL的作用及其与Java的关系,尤其集中在如何扩展BPEL,使它不但可以组合Web服务,也可以组合其他资源(如EJB,JMS等)。BPEL和Java结合的可能性,打开了一个有趣的新视野。
BPEL的作用
面向业务过程的SOA需要使用一个相对简单的方式来描述如何把Web服务组合成业务过程。当然,如果描述的方式最好能够执行,这样我们不但可以定义一个抽象的业务过程,而且完成了一个可执行的业务过程规范。BPEL正是这样的语言。实际上,它是第一个拥有以下特征的语言:
1、允许我们同时定义抽象的业务过程和可执行的业务过程
2、受到大多数公司的支持
3、存在可执行这些业务过程语言的软件(BPEL服务器)和开发工具(BPEL设计工具)
在深入了解BPEL之前,让我们讨论一下如何组合Web服务。有两种方式:Orchestration和Choreography。使用Orchestration,需要一个总控过程来控制涉及到的Web服务,并协调Web服务不同操作的执行。所涉及到的Web服务并不知道(也不必知道)它们是组合过程的一部分。只有中央的总控过程知道它们如何组合和协调。
相比之下,Choreography并不依赖中央的总控协调过程。相反,每个涉及其中的Web服务都知道何时执行自己的操作,和谁交互。Choreography方式集中在消息的交换。所有的Choreography参与者都需要知道业务流程,要执行的操作,要交互的消息,和交换消息的时机。
从组合Web服务来执行业务流程的角度来看,Orchestration比Choreography更灵活:
1、我们知道谁负责执行整个业务流程。
2、及时Web服务并不知道它们是业务流程的一部分,我们仍然可以把它们组合起来。
3、当错误发生时,我们可以提供一个备选的Scenario。
BPEL遵循Orchestration范式。其他的标准则使用Choreography范式,如 WSCI(Web Services Choreography Interface)和WS-CDL(Web Services Choreography Description Language)。和BPEL相比,Choreography没有获得业界的支持。
2002年8月,BEA,IBM和微软公司开发出BPEL的第一个版本。2003年4月,BPEL提交给OASIS标准化。
BPEL既可以在公司内部使用,也可以在公司之间使用。在公司内部,BPEL用于标准化企业应用集成,并集成遗留的孤立系统。在公司之间,BPEL使业务伙伴之间的集成更加容易和高效。BPEL定义的业务流程并不会影响已有的系统。在功能已经存在或要发布成Web服务的环境,BPEL是关键的技术。随着Web服务技术应用的日益广泛,BPEL的重要性也在上升。
BPEL语言
BPEL语言被设计来描述业务流程。它支持两种不同类型的业务流程:
1、可执行的流程-允许我们定义一个业务流程的确切细节。它可以在Choreography引擎种执行。多数情况下,BPEL都用于可执行的流程。
2、抽象的业务协议-允许我们定义参与方之间的公开消息交换协议。它不包括业务流程的内部细节,也不能执行。
BPEL构建在XML和Web服务的基础上。它是一个以XML为基础的语言,支持Web服务技术的协议群,包括SOAP,WSDL,UDDI,WS-Reliable Message,WS-Addressing,WS-Coordination和WS-Transaction。BPEL是早期两个工作流语言(WSFL和XLANG)的综合。WSFL由IBM设计,基于有向图的概念。XLANG有微软设计,是一种块结构语言。BPEL综合了两者的特点,为描述业务流程提供了丰富的语义词汇。
BPEL流程定义了参与流程的Web服务执行的确切次序。它可以按顺序执行,也可以并行执行。使用BPEL,我们可以表达条件行为,例如,是否执行一个Web服务取决于前一个执行结果;也可以创建循环,声明变量,复制和为变量赋值,定义错误处理Handler等等。综合使用这些结构,我们可以用算法的方式定义复杂的业务流程。
因此,BPEL可以和通用的编程语言,比如Java相比较,但它没有Java强大。另一方面,它更简单,更适合业务流程的定义。因此,BPEL并不是现代语言(如Java)的替代,而是它们的补充。
让我们更仔细地看看典型的BPEL流程。首先,BPEL业务流程收到一个请求。为相应请求,BPEL执行相关的Web服务,最后相应请求者。因为BPEL流程需要和其他的Web服务协作,它依赖于被调用的Web服务的WSDL描述。
BPEL流程包含几个步骤。每个步骤称为活动。BPEL支持简单的和结构化的活动。简单的活动代表基本的结构,用于普通的任务,如下列表所示:
1、调用其他Web服务,使用
2、等待客户端通过发送一个消息调用业务过程,使用
3、为同步操作创建一个响应,使用
4、为一个数据变量赋值,使用
5、指出错误和例外发生,使用
6、等待若干时间,使用
7、终止整个流程,使用,等等
我们可以组合这些基本的简单活动来定义复杂的算法,用于定义业务流程的执行步骤。为组合这些基本活动,BPEL支持几个结构化的活动。最重要的是:
,用于定义按次序执行的一系列活动
,用于定义并行执行活动的集合
,用于创建条件分支
,用于定义循环
,用于从多个可选的路径中选择其一
每个BPEL流程都可以使用声明变量,使用定义partner link。我们将在后面的小节讨论。
BPEL流程可以是同步也可以是异步的。同步的BPEL流程阻塞客户端(使用该流程的客户端)直到流程结束并返回结果。异步的BPEL流程并不阻塞客户端。它使用一个回调来返回结果(如果有)。通常,我们在耗时较长的流程使用异步流程,把同步流程用于处理在短时间内返回结果的流程。假如一个BPEL流程使用异步的Web服务,通常情况下它自己也是异步的(虽然不是必要的)。
对于客户端来说,一个BPEL流程看起来就像其他的Web服务。当我们定义一个BPEL流程时,我们实际上定义了一个组合现存Web服务的新Web服务。这个新的BPELWeb服务使用一系列portType,通过这些portType,它提供了类似于其他Web服务的操作。为调用一个在BPEL定义的业务流程,我们必须调用这些Web服务的组合。下图是一个BPEL流程的示意图:
Partner LinkBPEL示例BPEL vs JavaBPEL服务器和开发工具PPEL + Java总结资源关于作者待续......
原文地址:
http://starrynight.blogdriver.com/starrynight/637103.html