精彩的人生

本文意譯自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流程的示意圖：