转：BPEL和Java

转：BPEL和Java

本文意译自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 Link

BPEL示例

BPEL vs Java

BPEL服务器和开发工具

PPEL + Java

总结

资源

关于作者

待续......


原文地址： http://starrynight.blogdriver.com/starrynight/637103.html