Explainer: BPEL

Jan Matlis (Computerworld)
30 June, 2005 16:07
Comments

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.

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 (some of which may be time-based offers) 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.

Several major companies have been involved in defining BPEL, and many of them participated in previous efforts to create standards for business process execution for Web services. They include Adobe Systems, Avaya, BEA Systems, Booz Allen Hamilton, Electronic Data Systems, Hewlett-Packard, NEC, Novell, Oracle, Panacea, SAP and SeeBeyond Technology. However, IBM and Microsoft have had the most impact on defining how execution works in BPEL. IBM's Web Services Flow Language, which uses a directed graph approach, and Microsoft's Xlang, which uses a block-structured approach, were brought together in August 2002 under the aegis of the Organization for the Advancement of Structured Information Standards to create the first draft of the BPEL standard.

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.

The consensus among analysts appears to be that 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, or even lonely consumers trying to synchronize airline, hotel and car reservations, BPEL engines may be doing it all with little more than the occasional mouse click from the humans involved.