For its advocates, Business Process Execution Language promises to be the capstone in the Web services standards stack that makes Web-based commerce work. 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.
More
Computerworld
QuickStudies
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.