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引擎就可以做这一切，偶尔需要相关的人员点击一下鼠标。