Business Process Execution Language (BPEL)

DEFINITION: Business Process Execution Language is an XML-based language that’s designed to run a series of Web-based transactions and/or characterize interfaces that are needed to complete Web-based transactions.

Business Process Execution Language promises to be the capstone in the Web services standards stack. It was designed to integrate a variety of applications that are run to achieve a particular business objective—and to do it in a way that’s platform- and code-independent, not to mention one that’s scalable and flexible.

It would be possible to hammer out Java code or a set of Unix scripts that could manage a series of processes—such as the steps taken by an insurance broker running a series of Web-based applications to match the needs of a customer—but the task would be laborious, and the finished code would likely be cumbersome. Writing a BPEL application, on the other hand, provides a layer of abstraction through which all the steps can be connected and managed.

Sitting in front of a BPEL designer graphical user interface, a business manager such as our insurance broker could define a business process in BPEL that would be independent of the underlying applications. If those applications were to change, the insurance broker’s arrangement of them in the BPEL designer GUI could stay the same. Or if the insurance broker’s business plan changed, he could rearrange the processes, as well as add new ones or subtract others, within the GUI.

To run BPEL code that has been generated, either through a GUI or by an intrepid XML programmer, the code is parsed by a BPEL engine, which does the same kind of parsing job as other XML interpreters. Each process that’s run is characterized by a Web Services Description Language (WSDL) document, and its messages are transmitted across the Web by the Simple Object Access Protocol (SOAP). Processes that look up available Web services can use the Universal Description, Discovery and Integration (UDDI) directory.

In order to define business processes, BPEL has been endowed with a variety of XML constructs, including “partners”,which are definitions of the actors in a business transaction; “containers”,which are definitions of the messages that need to be transmitted; “operations”, which are definitions of the type of Web services that are required; and “port types”, which are definitions of the kinds of Web services connections that are required for operations.

BPEL’s capacity goes beyond the range of traditional, definitional XML types. By defining processes, it blurs the distinction between XML—a definition language—and executable languages like Java and Unix shell scripts; hence the “execution” in its name.

To define how processes should be executed, BPEL has XML definitions or commands that specify the order of operations, the looping of operations, and synchronous and asynchronous requirements for operations. (Synchronous operations block requesters until a request is either fulfilled or denied. Asynchronous operations allow requesters to continue without waiting for a response.) BPEL also has commands to take care of fault conditions and commands to undo or reverse operations.

An insurance-broker BPEL program, for example, might request financial information from a customer first, loop through insurance company offerings that it discovers from a UDDI search and finally present a package to the customer. If an error occurs or if the customer rejects the offers, even after tentatively accepting one, the BPEL program will make the proper adjustments.

Directed graphs specify the choices that must be made to get from one transactional state to another. For example, customer financial information must be received before insurance quotes are solicited. Block-structured languages offer the kind of programming flexibility familiar to Java, C and C++ programmers.

BPEL will “orchestrate” business processes, meaning that centralized control of Web services will reside in a BPEL engine. However, the protocol seems to leave open the possibility for “choreographing” Web services at a future date. Choreographed Web services interact without being directed by a central, controlling program. The ability in BPEL to publish the execution requirements of a Web service would seem to be what’s needed for the more decentralized vision of choreography.

Someday, instead of harried office administrators talking into three phones at once, or stock brokers monitoring banks of terminals while bidding in the seeming anarchy of the exchange floor, BPEL engines may be doing it all with little more than the occasional mouse click from the humans involved.

業務過程執行語言(BPEL)

定義：業務過程執行語言是一種基于XML的語言，設計旨在完成一系列基于Web的事務處理和(或)表征完成基于Web事務處理所需的界面。

業務過程執行語言(BPEL)承諾成為Web服務標準堆棧的頂層。它旨在將各種實現特定商業目標的應用程序集成在一起，并以獨立于平臺和程序代碼的方式工作，更不用提它具有可擴性和靈活性。

用Java或Unix腳本也能設計出能管理一系列過程的應用程序，如保險代理為了與客戶的需求匹配而采取的運行一系列基于Web的應用程序的步驟，但是這個任務是很費力的，最終的程序代碼也可能非常麻煩。相反，編寫BPEL應用程序能提供一層抽象層，所有的步驟能通過抽象層加以連接和管理。

業務經理，如保險代理，利用 BPEL設計師圖形用戶界面(GUI)，可以用BPEL定義獨立于基礎應用程序的業務過程。即使應用程序進行了更改，保險代理用BPEL設計師圖形用戶界面安排的業務過程也保持不變。或者如果保險代理的業務計劃改變了，他能在GUI中重新安排這些過程，比如增加新的過程或刪除其他的過程。

要運行已經生成的BPEL程序，可以通過GUI或者能力超強的XML程序員自己編程實現，代碼由BPEL引擎解析，如同其他的XML解釋器所做的解析工作一樣。運行的每個過程是用Web服務描述語言(WSDL)文檔表示，它的消息由簡單對象訪問協議(SOAP)在網上傳送。要查找可用Web服務的過程可以使用通用描述、發現和集成(UDDI)目錄。

為了定義業務過程，BPEL已賦予了各種XML結構，其中包括“伙伴”，即業務處理中參與者的定義; “容器”，即需要傳送的消息的定義、“操作”，即需要的Web服務類型的定義，以及“端口類型”，即操作所需的Web服務連接種類的定義。

BPEL的能力超過了傳統的、定義好的XML類型的范疇。通過定義這些過程，模糊了XML(一種定義語言)與執行語言(如Java和Unix Shell腳本)之間的界限，因此獲得了“執行”這個名字。

為定義過程是如何執行的，BPEL擁有規定操作次序、操作循環和操作的同步與異步要求的XML定義或命令(同步操作在一個請求完成或拒絕之前阻斷其他的請求者，而異步操作允許請求者不必等待響應就能繼續工作)。BPEL也有負責處理故障情況的命令和取消或逆轉操作的命令。

例如，保險代理的BPEL程序可能首先要求客戶的財務信息，通過保險公司提供的信息(這是從UDDI搜索中發現的)，最終打包提供給客戶。如果出現錯誤或者客戶拒絕(甚至在暫時接受之后)，BPEL程序將做出適當的調整。

受控的圖形指定從一種處理狀態進入另一種狀態而必須做出的選擇。例如，客戶的財務信息必須在(客戶)征求保險報價之前收到。塊結構語言提供了類似于Java、C和C++程序員的編程靈活性。

BPEL像演奏交響樂那樣協調業務過程，這意味著Web服務的中央控制保留在BPEL引擎中。然而，協議看來將來有可能開放分散式Web服務。分散式Web服務將不用受控的中央控制程序進行交互。BPEL發布對Web服務的執行要求的能力，看來是更分散的Web服務所需要的。

將來，辦公室管理員不用同時打三個電話、或者股票代理不必在亂哄哄的交易大廳邊做報價邊盯著顯示終端，BPEL引擎就可以做這一切，偶爾需要相關的人員點擊一下鼠標。